Coding agents are getting better at an exponential rate, this can be seen evidently, with benchmarks getting saturated, models being able to complete longer and longer tasks asynchronously.

As verification and simulation become the bottleneck, the way product development is done will be completely rewritten.

The way product development has been done up until now is a largely sequential process, where there are multiple stakeholders involved across the stack. For your average software project it would look something like the following.

Idea -> Product -> Design -> Engineering -> QA -> Production

Under this model the vast majority of the time was spent on the implementation phase of the loop. The tail ends of the loop Idea <> QA took the least amount of time by an order of magnitude. So since the implementation was the dominating cost in this process it follows that the loop was made in a way to reconcile with this.

We are now reaching an inflection point in large language models in which the pareto frontier of cost/performance has gotten to a point where for a non-trivial portion of tasks it really feels as though longer asynchronous tasks and cloud agents are starting to make sense in production cases.

With this abundance and ease of generation of code there is a strong yearning for understanding of the story of the code, and the true change that is being enacted upon in the codebase. With the utility of the codebase repository really diminishing for a lot of use cases.

An interesting consequence of the following is a strong coalescing of multiple job roles, particularly Design, Engineering and Product. Many companies we work with have seen this organizations become one, with the job role being almost the same on a day to day basis, albeit different specializations.

The new unit of work we see many teams adopt as we see a compression of the old sequential product development loop is a loop in which the unit of work can be described as a Verified change in product behaviour with the loop being as follows.

Intent -> Implementation -> Observed Result

With the observed result here being a combination of the runtime evidence, the change to product flows, and the effect on relevant user journeys. It is very empirical in nature where the actual substrate is what is actually changing.

For this new loop the most important thing to save is not really the code, rather the runtime signals are actually running the app. Think, how your software runs on a device, what it looks like, the performance of the payment flow with these new changes, and what the backend distributed services look like.

The codebase is of course still important, but it no longer captures the story and utility of the code in a complete way. If an agent changes a checkout flow, the repository can tell us which files changed. It cannot tell us whether the keyboard covered the payment button, whether returning users were sent down the wrong path, whether latency increased, or whether the resulting experience still matched the original intent.

All of this being saved and aggregated in a platform across all of your work and creating historical data holds immense value beyond just the code.

We are working on building missing pieces at Revyl for this new development loop starting with mobile.

We believe we can work between your existing tooling like figma, codex, claude code, cursor and many more and provide immense value in making that tooling work better together.

The missing part is a behavioural record attached to every product change,

Over the next year I imagine, that we will see many standards adopted in software development some of these will include:

• pull requests include behavioral evidence as a standard

• runtime signals become a first class development context

• Product, design, engineering will increasingly converge around developing with outcomes in mind.

Product development is clearly not dead, it is more alive than ever, just being fundamentally rewritten.