In short: as coding agents absorb implementation, human effort in R&D moves to the two ends of the cycle. One end is specifying intent precisely enough for an agent to execute. The other is verifying, at the system level, that the result is right. Teams that invest in both ends get the gains; teams that do not get the same bottleneck with more code flowing through it.
The middle of the cycle is emptying
Ask where a typical R&D group puts its people and the answer is the middle. Most headcount sits in implementation: writing, integrating, and debugging the code. Requirements on one side and QA or validation on the other are thin. In startups they are often nobody's job.
That shape is changing. Coding agents now take on large, well-bounded pieces of implementation, and each model generation takes a bigger piece. The work they absorb comes from the middle. The work they create lands at the ends.
My working hypothesis, for the next one to two years: human effort in R&D moves from building to specifying and verifying. The distribution goes from one peak in the middle to two peaks at the ends. Pure-software teams start to look like chip design teams do today.
One honest correction before going further. Measured coding time was never that large. At Microsoft, developers spent about 11% of their week coding (Kumar, Zimmermann et al., 2025), and IDC puts application development near 16%. The middle peak is about how teams are staffed and organized, not how many hours go into typing. That is the thing that changes.
Chip design already has two peaks
Hardware teams got here first, for a different reason. A bug found after tape-out costs a re-spin, so verification grew until it matched design. In the 2022 Wilson Research Group study, design engineers spent 49% of their own time on verification, verification and design headcount was roughly one to one, and verification headcount grew 6.2% a year against 2.7% for design (Siemens, 2022).
Software never needed that shape, because rebuilding was cheap and engineers were the constraint. Agents remove the second reason. When implementation is no longer the scarce resource, what is left scarce is knowing what to build and proving it was built right.
The left peak: specs an agent can run with
Today, specs and code grow together. A half-baked requirement goes to engineering, implementation pushes back, the spec changes, and the loop repeats until the product converges. That loop worked because the people writing code were also filling the gaps in the spec.
An agent fills gaps too, but silently and confidently. So the left peak is the work of stating intent completely enough that an agent can take it most of the way without a human pulling it back: acceptance criteria, constraints, interfaces, and the behaviors you would otherwise discover in review. For what that looks like in algorithm, vision, and embedded work, see Spec-driven development for algorithm, CV and embedded teams.
This is not a return to waterfall. The spec still changes. What changes is who notices the gap. Better that it is the spec author on day one than a reviewer on day ten.
The right peak: system verification, not code review
The right peak is easy to misread. It is not more people reading pull requests. Code review sits in the middle of the cycle, and it is already shrinking: across 22,000 developers, pull requests merged with no review rose 76% (Faros AI, 2026). That gate is going away, with or without anyone's permission.
What has to grow is verification at the level of the system: test architecture, full-system tests, hardware-in-the-loop, and the instrumentation that makes a product observable to both humans and agents. The core job is defining the oracle. What counts as correct, and what evidence proves it?
Passing tests is not that oracle. When METR asked maintainers to review AI patches that already passed the tests, they would merge only about a third to a half of them, against about 68% of human patches (METR, 2026). Andrej Karpathy frames the same point from the other side: AI automates what can be verified (Verifiability). Make more of your product verifiable and more of it can be handed off.
Approval gates can disappear. Accountability does not. As Simon Willison puts it (2025), the job is now delivering code with proof that it works.
Why front-load, if building is cheap?
Silicon front-loads because iteration is expensive. Agents make software iteration cheaper, which seems to argue the other way: skip the planning, build, and see.
The catch is that every loop still needs a human to judge whether the result is right. Build cost fell. Judgment cost did not. Front-loading now saves human verification cycles, not compute or engineering hours. That is a different reason to do the homework first, and a stronger one.
Prototype where the evidence is
There is a counterweight, and it matters most in physical systems. Before agents, production-grade code was expensive, especially in a large C++ codebase that is hard to step through. So we worked the algorithm out first in MATLAB or simulation, made sure the math held, and only then ported it.
That made sense when the simulation told you something. Often it did not. On autonomous driving programs I worked on, the only reliable way to know whether a planner was any good was to put it in the car. CARLA and the digital twins did not come close.
The research backs that up at the edges. A detector trained in CARLA scored 4.26 mAP on real data against 15.69 when trained mostly on real data (Tan et al., 2025). At the limits of grip, simplified vehicle models were off by more than 40% (Sagmeister et al., TU Munich, 2026).
With agents, you can implement three candidate planners in the code that actually ships to the target, and take all three to a safe test ground in the time one used to take. So the rule I would use: prototype in the cheapest environment whose evidence is good enough for the decision. Sometimes that is a notebook. Increasingly it is production-grade code on real hardware.
Two limits keep this honest. First, real testing does not scale to proof. Showing an autonomous vehicle is safe from road miles alone would take hundreds of millions to billions of miles (RAND, 2016), which is why leaders such as Waymo still run most development in simulation and use the road to calibrate it. Second, agents are weaker on embedded code than on web code: on 126 embedded tasks the best model passed 29.4% first time on ESP-IDF (Xu, Cao et al., ICSE 2026).
So measure where your simulation is wrong, per dimension: perception, actuation, behavior. Spend real test time only where the gap is large. And notice where the effort went: into the safety envelope on the left and the test ground on the right. The two peaks again.
What could make this wrong
Three things argue against the two-peaked picture.
Nobody funds the right peak. Today, most organizations answer the review bottleneck with less verification, not more. Faros found work sent back from review or QA up 67% in the same data. If that continues, the right peak never forms. The cost shows up as rework and instability instead.
Specs stay hard to write. Practitioners report that spec-heavy workflows create a pile of markdown to review, and that agents ignore parts of it (Birgitta Böckeler, 2025). LLMs also write weak formal properties (Hillel Wayne, 2026). The left peak only pays off if specs are checkable, not just longer.
The gains are smaller than they look. In METR's 2025 trial, experienced developers on mature codebases were 19% slower with AI while believing they were faster (METR, 2025). If the middle does not actually empty, nothing moves.
That makes the hypothesis conditional. Teams get two peaks if they build them. Otherwise they get the same middle, with more code flowing through it. That is the case for investing in the method, not just the tools. The broader version of that argument is in Why AI made your developers faster but not your team.
Where to start
Move your best judgment to the ends. Put senior engineers on writing acceptance criteria and test architecture, not on reading diffs.
Make the product verifiable. Golden outputs, system-level tests, and observability that an agent can read as easily as a person.
Build a safe test ground. A hardware-in-the-loop rig, an instrumented track, or shadow mode in the field. Then make it score runs automatically, because test time becomes the scarce resource.
Measure the shift. Track where your people's time goes by stage, review and test effort per merged change, and the share of merges with no meaningful check. If the middle is not shrinking, the method has not caught up.
Talk it through
If your team already uses AI coding tools and the effort still piles up in the middle, the useful conversation is about where to move it.
Book a call and we will look at how your group specifies and verifies work today, and where the two peaks would sit for your stack. Work starts with a short diagnostic, then implementation with the team. Fit first.