// HACKER NEWS — CYBERSECURITY
Product Development is being Rewritten
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.
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.