English | EN 
Part 1 of a 3-part series on the shift of the bottleneck from “writing code” to “trusting code” in agentic development.
Agentic development moved the bottleneck from writing code to trusting it. Generating more tests makes it worse. Here is what actually shortens the distance between working code and a release someone is willing to sign off on.
Try a small thought experiment. The numbers are made up, but the pattern will probably sound familiar.
A feature that used to take three weeks now takes two days. Everyone is happy, and they should be. Then the work just sits there. It isn’t blocked, and the build stays green the whole time. It waits for code review, then a shared test environment, then a regression run, and finally the one person who understands the payment flow well enough to approve it.
Nine days later, it ships.
Nobody records those nine days as a delay, because no single stage owns them. What was missing was never the code. What was missing was confidence in it.
Matt Taylor described this shift from the inside in Six Months of Enterprise Agentic AI. His planning question stopped being “how long will this take to build” and became “how long will this take to verify.” I think that’s one of the most important observations written about agentic development this year, so I want to build on it.
When generation gets cheap, the bottleneck doesn’t disappear. It moves to whatever part of the system is least automated, and for most organisations, that’s verification.
The math nobody does
Delivery speed is set by the slowest stage in the pipeline, not the fastest. That has nothing to do with AI; it’s basic queueing theory, true long before anyone had a coding agent.
What agentic development changed is the ratio between the stages. Code output went up by a factor that’s hard to ignore. Verification capacity barely moved at all: same regression runtime, same shared environment, same one person who can sign off on the payment flow.
So the backlog builds up in front of verification, faster than before.
Here’s the uncomfortable part: a large share of the speed gained from agentic development is currently turning into work in progress, not delivered value. Code that ships faster but waits longer isn’t faster delivery. It’s just a bigger pile, further down the pipeline.
Why the obvious fix backfires
The instinctive response is to point the same agent at the new problem. If it can write code, why not let it write the tests too?
That works, for about three sprints.
The issue is what a generated test actually checks. A test written from the implementation confirms that the implementation does what it does. If the implementation is wrong, the test inherits the same mistake and still turns green.
There’s also a carrying cost most teams underestimate. Test code behaves like inventory, not a finished asset: every generated test has to be read when it fails, updated during refactors, and debugged when it turns flaky. A suite that grows by four hundred cases a month isn’t four hundred cases better off; it’s heavier, and the signal-to-noise ratio drops with every one of them.
I’ve seen suites where real coverage of intent went down while the line-coverage number kept climbing.
What actually closes the gap
Two changes address this directly, and neither of them is new. The economics now just make them hard to postpone.
Check contracts, not screens
The most expensive kind of verification, per bit of information it gives you, is a browser test. It’s slow, it breaks for reasons unrelated to what you were checking, and it tells you almost nothing about which component is actually at fault.
Move the checks closer to the interfaces instead. Validate schemas on every API response. Run consumer-driven contract tests between services. Check invariants on the data model directly. At the UI layer, keep a handful of true end-to-end journeys and stop there.
The suite gets smaller, and what it tells you gets more useful. A contract test gives you an answer. A UI test usually just raises another question.
Let production answer some of the questions
Some things can’t be verified cheaply before every (small) release, and can be checked almost for free right after it. Does the system hold up under real traffic? Does it behave for the account configurations nobody could enumerate in advance?
Feature flags, canary releases, synthetic monitors, and solid observability turn those into cheap experiments instead of expensive simulations. Colleagues of mine have written about this under the heading of shifting quality right, and I’d add one thing: in an agentic context, this isn’t optional anymore. It’s how you keep the pre-release queue short enough to still matter.
The metric I would add tomorrow
DORA tracks lead time for change: commit to production. That number hides the exact problem here, because everything above happens inside it.
I now track verification lead time separately: the time between working code existing and a named human being willing to release it.
It’s a slightly awkward metric, since the finish line is a human judgment call, not a clean automated event. That’s exactly why it works. It measures what’s genuinely scarce now: not compute, and not typing speed either. Warranted confidence.
Track it for a month and you’ll know quickly whether your agentic pilot bought you speed, or just moved the queue somewhere less visible.
The part that no tool will fix
I want to be honest about where all of this stops working.
You cannot verify your way out of an architecture that was never built to be tested. If a system has no clean seams, if state is shared globally, if the only way to observe behaviour is through the browser, no amount of agent help will make verification cheap. It will just produce more expensive tests, faster than before.
Testability is an architectural decision, made long before anyone writes a single test. Which means the verification bottleneck is, underneath everything, an architecture conversation. That’s not a comfortable conclusion for a quality organisation that has spent a decade inheriting systems after the fact, rather than shaping them. It’s also the strongest argument for having quality engineering in the room during design, not downstream of it.
In the next part of this series, I want to go a level deeper: into the failures that make agentic output hard to trust in the first place, and why our existing defect categories don’t really capture them.
What does verification lead time look like on your team right now? Does anyone actually track it?