Two data points from the past year tell very different stories, and most engineering organizations are only looking at one of them. Tool adoption has gone nearly universal. Confidence in what those tools produce has gone the other direction. Read separately, each number supports a comfortable conclusion. Read together, they describe an organization generating far more code than it can responsibly evaluate, which is where a surprising share of engineering budget is quietly going.
Temporal's 2026 State of Development Report, drawn from 554 engineers and engineering leaders in the US and UK, puts daily agent usage at roughly 80%, up from about 47% a year earlier, with a median of five agents deployed per respondent. Over the same stretch, Stack Overflow's developer survey recorded trust in AI accuracy falling from 40% to 29%. Adoption is climbing. Belief in the output is not. The distance between those two lines is the subject of this piece.
The Constraint Moved And The Process Did Not
For three decades, the scarce resource in software was the capacity to write code. Sprint planning, story points, headcount models, hiring plans, vendor contracts: every one of those artifacts assumes that producing code is the hard part. In a growing number of organizations that assumption is simply no longer true. The hard part is now deciding whether the code that already exists is correct, architecturally appropriate, and safe to release.
Generation capacity expanded overnight. Review capacity did not. It is still the same senior engineer, reading at roughly the same speed as in 2019, now facing several times the volume. The Stack Overflow data names the resulting failure mode precisely: the single biggest frustration developers reported, cited by 45%, was output that is almost right but not quite, and 66% said they spend more time correcting that near-miss code. The work was never eliminated. It changed shape, moved downstream, and stopped appearing on anyone's dashboard.
| Delivery Stage | Before Agents | After Agents | Capacity Response |
|---|---|---|---|
| Code Generation | Human paced | Multiplied | Funded and staffed |
| Code Review | Human paced | Same throughput | Unchanged |
| Testing And Evaluation | Human paced | Backlogged | Rarely funded |
| Rework And Correction | Visible in sprint | Absorbed silently | Not measured |
| Release Accountability | Implicit | Frequently ownerless | No named owner |
"45% of developers named 'almost right but not quite' as their leading AI frustration, and 66% report spending more time fixing that code."
— Stack Overflow Developer Survey
The Measurement Problem Is Bigger Than The Capacity Problem
Anyone who reports engineering performance to a board should sit with the METR study for a few minutes. Researchers ran a randomized controlled trial with 16 experienced open source developers working 246 real issues in repositories they already knew well. Before starting, the developers expected AI assistance to make them about 24% faster. Measured against control, they were 19% slower. Asked afterward, having personally lived through the slowdown, they still believed the tools had made them roughly 20% faster.
What Teams Believe
- Forecast a 24% speed gain before the work
- Reported a 20% gain after the work
- 85.5% express at least some trust in agent output
- Velocity charts look healthier than before
What Measurement Shows
- 19% slower completion under controlled conditions
- A roughly 40 point perception to reality swing
- 41.1% hit agent related issues daily or more often
- Rework and instability rarely instrumented at all
The sample is small and the researchers say so. The direction is what matters: a gap of roughly 40 points between how skilled practitioners felt and how they actually performed, on code they understood deeply. That is not a competence story. It is what a broken feedback loop looks like from the inside. The Temporal data captures the same split within one population, where 85.5% report at least some trust in agent output while 41.1% run into agent related problems daily or more often.
We call this the AI validation gap: the missing evaluation, measurement, and trustworthy feedback loops around AI initiatives. It is usually framed as a product risk, the hallucination that reaches a customer or the model drift nobody catches. The same gap has now opened inside the delivery system itself, where it is considerably harder to spot, because the output looks like perfectly ordinary code.
These Are Old Failure Modes Arriving Faster
In our Software Delivery Failure Index 2026, we analyzed 195 long form interviews with software leaders and identified 48 that met our criteria for a documented delivery failure. Every one of those 48 traced back to the same five recurring root causes, and the largest single overspend in the set reached $42 million. None of those causes required AI to exist.
Step One: Generation Capacity Expands
Agents roll out across teams. Output volume increases within a quarter.
Step Two: Review Capacity Holds Flat
The same senior engineers read the same number of pull requests per week.
Step Three: Correction Work Moves Downstream
Near miss code is absorbed as rework, defects, and time to restore, not as planned effort.
Step Four: The Scoreboard Reports A Win
Throughput metrics rise while instability metrics go unmeasured. Nobody can prove the loss.
AI did not invent a new way for software projects to fail. It removed the friction that used to slow the familiar failures down, and it did so faster than most organizations updated their instrumentation.
Four Moves Worth Making Before The Next Planning Cycle
None of these require a new platform purchase. They require deciding that verification is a funded function rather than an assumption.
Validation Readiness Checklist
Instrument instability, not only velocity. If your dashboard tracks pull request throughput, deployment frequency, and merged volume without change failure rate, rework rate, and time to restore, you have built a scoreboard that is structurally incapable of reporting a loss. Add the other half.
Treat review as a capacity constraint with a number attached. Most engineering leaders can state their headcount to the person. Ask the same leader how many pull requests a senior engineer can meaningfully review in a week and you usually get a shrug. That number exists whether or not anyone records it, and it is the real ceiling on delivery.
Stop treating self reported gains as evidence. The METR result makes this non negotiable. Ask what moved in the delivery data, not how the team feels about the tooling. If the only support for a 30% improvement is that people report a 30% improvement, that is sentiment, not evidence.
Name an owner for verification. Generation almost always has an owner, usually whoever drove the tool rollout. Verification frequently has none. It gets folded into everyone's job, which in practice means nobody's. Assign it, budget it, and give that person the standing to hold a release.
Volume Is Not Velocity
The organizations pulling real leverage out of AI tooling are not the cautious ones. They are the ones that expanded review, testing, and evaluation capacity at the same moment they expanded generation capacity, and who can therefore answer the only question that matters with data rather than conviction: did it work?
"An unmeasured delivery system running at higher volume is not acceleration. It is the same problem arriving faster."
Everyone else is running an unmeasured system at a higher throughput and calling the difference progress. The uncomfortable part is that the fix is not technical. It is an accountability decision about who owns proof, how much capacity that person gets, and whether they are allowed to say no.
Adapted from the author's column originally published by Forbes Technology Council.