Ask any CTO who rolled out AI coding assistants last year and you'll hear the same story: pull requests are up, code volume is up, individual task completion is dramatically faster. Then ask a harder question — has your release cadence improved? Are customers getting more value, sooner? — and the room gets quieter.
This is not a failure of the technology. It's a failure of the mental model. Most leadership teams adopted AI in the build workflow expecting a throughput upgrade: same pipeline, faster flow. What they actually got was a structural change in where the pipeline constrains.
The research emerging this year makes the pattern hard to ignore. Controlled studies show developers completing representative coding tasks roughly 55% faster with AI assistance — while a widely discussed METR study of experienced open-source developers found they were actually 19% slower on complex work in familiar codebases, largely because reviewing and correcting AI output consumed the gains.
Both findings are true, and the tension between them is the whole story: AI accelerates the typing, not the thinking. CloudBees' 2026 "State of Code Abundance" report names the resulting condition precisely — AI-driven development velocity is now outpacing enterprise operational maturity.
The illusion of progress
In our work with client companies, we see the same failure pattern over and over, and it is not unique to the AI coding phenomenon because it predates AI: teams skip the upfront work — the design, the requirements definition, the validation of product-market fit — and move straight into coding. And leadership applauds, because moving to development feels like progress. It's the next step on the plan. There's something to demo.
But much of that code ends up wasted, rewritten, or fundamentally restructured — not because the engineering was poor, but because the team never did the most important work: understanding the market need before building for it. The demo was progress toward something; it just wasn't progress toward a product anyone had validated demand for.
AI doesn't fix this pattern. It supercharges it. When a team can stand up a working prototype in days instead of months, the temptation to skip discovery and "just build it" becomes almost irresistible — and the pile of confidently-built, never-validated code grows three times as fast. Anyone who has managed a factory will recognize the dynamic: speed up one workstation and you don't get a faster line — you get inventory piling up in front of the next constraint. In software, that inventory is unreviewed pull requests, untested features, and — most expensively — well-built products nobody needed.
The constraint has moved to judgement
Follow the bottleneck upstream and downstream from code generation and you find the same scarce resource at both ends: human judgement.
Downstream, it's review and validation. When engineers produce three times the code, someone still has to determine whether it's correct, secure, and maintainable. Code review was designed for a world where code was expensive and scarce. In a world where code is abundant, review becomes the choke point — and industry data showing code churn rates nearly doubling since 2021 suggests a lot of that abundance is being written, merged, and rewritten without ever creating durable value.
Upstream, the constraint is deciding what to build at all. For two decades, the implicit economics of product development were: deciding is cheap, building is expensive. So companies invested heavily in engineering capacity and treated product decisions as overhead. AI inverts this. When building is fast and cheap, the expensive mistake is no longer building slowly — it's building the wrong thing quickly. A misjudged quarter of roadmap used to waste engineering time; now it wastes engineering time at 3x the output. This is where our Pragmatic Innovation framework really shines.
This explains a finding in Deloitte's 2026 State of AI in the Enterprise study that should give every leadership team pause: while 66% of organizations report tangible gains from AI, only about a third are using it to genuinely transform how they create products and reinvent core processes. The majority bolted AI onto existing workflows and harvested local efficiencies. The minority redesigned the workflow around the new constraint. That minority is where the compounding returns are accruing.
What redesigning around the new constraint looks like
Three moves distinguish the companies getting delivery-level results from those getting demo-level results.
First, they measure the system, not the station. Retire "AI adoption rate" and "lines of code generated" as headline metrics. Track lead time from validated idea to production, defect escape rate, and the percentage of shipped features that hit their success criteria. If those numbers haven't moved, your AI investment is producing inventory, not outcomes.
Second, they reinvest engineering capacity into validation, not just volume. The most disciplined teams treat AI-generated speed as a budget and spend a deliberate share of it on the new bottleneck: stronger automated testing, faster review workflows (including AI-assisted review — the same technology that created the abundance can help govern it), and tighter production feedback loops.
Third — and this is where the leverage is greatest — they restore the discipline of the front end. If skipping discovery was expensive before AI, it's ruinous now. The remedy isn't a return to waterfall; it's a hard gate: no significant build begins without a defined market need, articulated requirements, and evidence of demand. Give product managers the same AI leverage engineers got — for synthesizing customer evidence, pressure-testing assumptions, and killing weak ideas before they consume a sprint — and hold them to a higher standard of proof before anything enters the build queue. Development used to be slow enough to act as a natural filter for half-baked ideas. That filter is gone. You have to build it back deliberately, upstream.
The takeaway
The uncomfortable truth of this phase of AI adoption is that the technology has outrun most organizations' operating models — and it has made an old vice newly dangerous. Rushing to code always felt like progress and rarely was. Now that code is nearly free, the only progress that counts is validated progress: proof of market need, clarity of design, evidence that what you're about to build three times faster is worth building at all.
Here's a concrete way to start: this quarter, ask your product and engineering leaders two questions. Where does work wait the longest between idea and customer? And what percentage of what we shipped last quarter would we build again, knowing what we know now? The first tells you where your bottleneck moved. The second tells you what skipping the front end is costing you. The leaders are acting on both answers while the laggards are still counting lines of code.
