- AI software delivery speeds up coding but leaves review, testing, and deployment just as slow as before.
- Anthropic’s Cat Wu says AI software delivery improved mainly through process changes, not faster models.
- When code generation gets cheap, the bottleneck shifts to judgment — what to build and when to ship.
- Teams drowning in PR queues and merge backlogs are experiencing faster code output, not faster delivery.
- AI software delivery speeds up coding but leaves review, testing, and deployment just as slow as before.
- Anthropic’s Cat Wu says AI software delivery improved mainly through process changes, not faster models.
- When code generation gets cheap, the bottleneck shifts to judgment — what to build and when to ship.
- Teams drowning in PR queues and merge backlogs are experiencing faster code output, not faster delivery.
The Bottleneck Didn’t Disappear — It Moved
AI software delivery has a dirty secret: the pipeline didn’t get faster, it just got congested somewhere new. Teams are celebrating 10x or even 50x speed improvements with AI coding tools — GitHub Copilot, Cursor, Claude Code, take your pick — but if you look closely at actual release cadences, the numbers rarely hold up. What got faster was typing. Everything else? Still stubbornly slow.
Think about what actually happens after an AI agent drafts a patch in ten minutes. Someone still has to review it. CI still has to run. QA still has to validate. A human still has to decide whether it’s safe to merge. And if something breaks in production, the rollback process is exactly as painful as it ever was. The code arrived faster. The rest of the system didn’t get the memo.
This is the core tension that most breathless AI productivity coverage refuses to engage with. Faster code generation is not the same thing as faster AI software delivery. Conflating the two is how you end up with impressive demo stats and unimpressed engineering managers staring at a backlog that somehow got longer.
What Anthropic Actually Did Differently
Anthropic is one of the most-cited examples of a team that genuinely accelerated its shipping cadence — going from features every few months to features every few weeks, sometimes days. Product manager Cat Wu has spoken publicly about what drove that shift, and her answer is more interesting than the standard AI hype narrative.
It wasn’t primarily the models. Wu has said outright that internal model improvements raised AI software delivery speed only “a little bit,” with the bulk of the acceleration coming from process and team expectations. That’s a remarkable admission from someone at an AI company. The real work was operational: how goals get set, how documentation gets written, how cross-functional teams coordinate, who actually has the authority to put something in front of users without waiting for three rounds of approval.
Mike Krieger, Instagram co-founder and now Anthropic’s Chief Product Officer, has echoed similar thinking — describing how bottlenecks shifted away from writing code toward deciding what to build, managing merge queues, and navigating CI pipelines. When coding stops being the slow part, you suddenly notice how slow everything else is. You were just too distracted by the keyboard to see it.
AI Software Delivery Requires Fixing the Whole Pipe
CircleCI put it bluntly in a recent piece on engineering in the AI era: success is “no longer determined by how fast code can be written” — the decisive factor is whether teams can “validate, integrate, and recover at scale.” That’s a sharper frame than asking whether your AI tool can generate a React component. Almost all of them can. The question is whether your organisation can absorb that output without grinding to a halt.
Qovery, writing about the state of AI and DevOps heading into 2026, made the same point from the platform side: when AI coding tools explode code throughput, the constraint flips. Less time typing, more time waiting on builds, environment provisioning, and deployment pipelines. The bottleneck hasn’t been eliminated — it’s migrated downstream, hiding in CI queues and preview environments instead of editors.
For teams running database-heavy applications, this is doubly painful. Application CI backs up, and then migrations, backup validation, and failover testing back up right alongside it. The more code that arrives at the gate, the longer each of those queues gets. Faster AI software delivery isn’t something you can bolt onto a pipeline that wasn’t designed for it.
When Code Gets Cheap, Judgment Gets Expensive
Here’s where the conversation gets genuinely interesting. If AI brings the cost of writing code close to zero, what becomes the scarce resource? The answer, increasingly, is judgment. Judgment about what’s actually worth building. Judgment about how good is good enough to ship. Judgment about where a human has to make the call versus where an agent can run to completion unsupervised. These are the questions that determine whether AI software delivery actually moves the needle on release cadence.
This is a meaningful shift. For most of software’s history, engineering time was the binding constraint. Product managers learned to front-load decisions into long, detailed PRDs — fifteen pages of background, scope, edge cases, competitor analysis — because once engineers started building, changing direction was expensive. That calculus is breaking down.
Cat Wu has said that in Anthropic’s current workflow, most routine features don’t need a novel-length requirements document. One page — goal, principles, how you’ll know it worked — and then people with the right context make local calls. Large infrastructure bets still deserve serious upfront thinking. But the default shifted. Lengthy docs don’t signal rigour anymore; they often just disguise decisions as description, which means nobody actually made a decision at all.
The teams that are genuinely accelerating AI software delivery have figured out two things simultaneously: less idle motion in the process, and more explicit rules. Less idle motion means cutting the documents, handoffs, and approvals that only exist because “that’s how we’ve always done it.” More explicit rules means goals, verification criteria, permissions, and rollback procedures are written down — not reconstructed in every meeting from scratch.
The PR Queue Problem Nobody Talks About
If you give a developer AI coding tools without changing anything else, here’s what you actually get: more PRs waiting for review, more features waiting for validation, more half-finished branches, more production risk, and — perhaps worst of all — more arguments about whether something is even ready to ship. The congestion didn’t disappear. It moved from “time to write the code” to “time to do everything else.” That’s not progress in AI software delivery — it’s just a different kind of waiting.
A feature that used to take two days to reach a first draft now takes thirty minutes. Great. But CI still runs for twenty minutes. Review still takes half a day, because the reviewer’s calendar didn’t change. QA is still queued. And now there are five times as many items in the queue because five developers are all using AI tools and all shipping first drafts simultaneously.
This is the local illusion problem. One part of the pipe got dramatically faster. The organisation measures that part, celebrates the improvement, and misses that total cycle time barely moved. The metric that matters — time from idea to production — is stubbornly resistant to improvements in any single stage unless the stages around it scale too.
What an Actual AI-Native Process Looks Like
The teams pulling ahead aren’t the ones where every engineer has a copilot subscription. They’re the ones that treated AI’s arrival as an opportunity to ask hard questions about why their release process works the way it does. Why does this approval gate exist? Why does this document have to be this long? Why does this decision require that meeting? Answering those questions honestly is what separates genuine AI software delivery transformation from a productivity theatre upgrade.
Shipping once a day — something Anthropic has demonstrated is achievable for small, scoped work — stops being a gamble only when the organisation has done both: cut the unnecessary motion and hardened the rules around what ships and when. That’s not a technology problem. It’s an organisational one. The AI just made it impossible to ignore any longer.
The teams that treat AI software delivery as purely a tooling upgrade — swap in a better code assistant, watch the velocity numbers climb — will hit a ceiling fast. The teams that use it as a forcing function to redesign how they ship software entirely are the ones that will look back in three years and not recognise their old process. The question for most engineering leaders right now isn’t which AI coding tool to adopt. It’s whether they’re willing to do the harder work that makes the tool’s speed count for anything.
Source: https://dev.to/seekdb/ai-writes-code-faster-why-hasnt-delivery-3fgj
