Why AI Hasn't Sped Up Your Software
( Originally posted at discontinuityai.substack.com - it’s my other blog )
The fastest team I ever worked with failed.
An early-stage startup, small engineering team, all-in on AI coding tools. By every measure you’d normally reach for, it worked. Pull requests shot up. Test coverage climbed. The pipeline hummed. Every activity metric on the board was green and rising.
Delivery slipped by months anyway.
For a while I thought this was a one-off — a team that got unlucky. Then the research started coming in, and it turns out the pattern is everywhere. A rigorous 2025 study by METR took sixteen experienced open-source developers and measured them on real tasks in their own large codebases. With AI assistance they were 19% slower — while estimating, even afterwards, that AI had made them about 20% faster. Google’s DORA research finds the same shape at the organisation level: nearly everyone now uses AI, most people report feeling more productive, and yet delivery stability keeps getting worse as AI use goes up. Their line for it is blunt: AI doesn’t fix a team; it amplifies what’s already there. And usage data from Faros AI across thousands of teams shows where the time goes — heavy-AI teams merged almost twice as many pull requests per developer, review time roughly doubled, and measured delivery velocity didn’t improve at all.
AI doesn’t fix a team; it amplifies what’s already there
AI genuinely is fast at coding. I use it and it’s a step-change faster. The best controlled study of that — GitHub’s own — found developers finishing a self-contained task over 50% faster with Copilot (and Copilot too, imagine if they used a good tool). That result is real. But notice what it measured: one scoped task, no architecture, no integration, no six-months-later maintenance. That’s the trick of the whole debate. AI is fast at the part of the job it touches. The job is bigger than that part.
So why doesn’t fast coding produce fast software? Watching that startup fail, and several teams since, I think there are three reasons — and they stack.
1. You didn’t remove the bottleneck. You moved it.
Writing code is one step in a chain: decide what’s worth building, design it, build it, review it, test it, release it, run it. Coding is maybe a sixth of that chain. When you make one link dramatically faster, the work doesn’t ship faster — it piles up in front of the next-slowest link.
That’s exactly what happened at the startup. Coding started outrunning everything around it; faster than product management, faster than QA, faster than the sober thinking about what needs to be built. Features got built that weren’t needed, or weren’t thought all the way through before the code existed. When every feature is nearly instant, it becomes too easy to just include them all, which overwhelmed every release. The odd truth we only saw afterwards: the old slowness of coding had been doing quiet work. It forced the team to consider what was actually worth building before the code existed.
When every feature is nearly instant, it becomes too easy to just include them all
The bottleneck had moved — to planning and review. But all the tooling, and all the attention, were still aimed squarely at coding. You don’t remove the bottleneck. You move it — and often you build a new one out of all the extra output.
2. Fast code can cost you the understanding of it
There’s a second cost, and it’s understanding. When AI writes the code, the person who merges it often can’t fully explain it. Each individual shortcut feels harmless — the code works, the tests pass. But understanding is how you debug, extend, and judge a system. Give it up a little at a time and you’re fine, until the day something breaks in a way the model can’t untangle, and you discover nobody on the team can either.
That’s when problems stop being linear. A team that understands its system fixes a bug in an hour. A team that doesn’t spends a day reconstructing what the code was even trying to do — and then, often, decides it’s easier to rewrite the module than to repair it. Rework and rewrites start to dominate the effort, and the speed you gained on the way in, you pay back with interest on the way out. The typing got faster; the knowing got slower.
I’ve started calling what’s lost here cognitive sovereignty — a team’s ability to reason about its own system without asking the model. It deserves its own article, and it will get one. For now the short version: trading a person who understands the system for a tool that produces answers about it isn’t a trade you notice until you need to reverse it.
3. Without guardrails, AI can’t see the big picture
The third reason is about what AI optimises for. Ask it to solve a problem and it solves that problem — capably, locally, now. What it doesn’t hold is your system’s long-term intent: why the last ten decisions were made, which conventions are deliberate, what next quarter needs the architecture to allow. ( Although coding “frameworks” like github spec kit, seek to resolve that )
So every AI-assisted change is a well-made patch, and a system maintained as a series of well-made patches drifts. Each fix is locally sensible; the whole stops being coherent. Three subsystems solve the same problem three different ways. Nobody decided that — it accumulated. You end up with an architecture that was never designed, only patched together, and every future change gets a little more expensive because of it.
None of this is the tool misbehaving. It’s the tool doing exactly what it was asked, in the absence of anyone holding the bigger picture and enforcing it.
What I’d do differently — the start of an answer
I wrestle with this every day and working it out properly is what I’m building towards, and it’s a framework, not a tip. But four guidelines fall straight out of the three problems, and teams I’ve seen apply them get the speed without the bill.
Use AI as a tutor, not an oracle — “explain three options and their trade-offs,” not “give me the answer” — so the understanding lands in a person’s head, not just the code in the repo. Require a plain explanation before anything merges: if the developer can’t explain why an AI-generated change works, it isn’t ready to merge, because a review is a way to pass knowledge across the team, not just a quality check. Treat review and testing as the new bottleneck and invest there deliberately, since that’s where the slow part actually went. And put more effort into planning and architecture, not less — when building is cheap, deciding what to build and how it fits together is where the biggest wins are now.
You’ll notice what these have in common: none of them is a tool. They’re all structure — the process around the tool. Which is the point.
Speeding up the code doesn’t speed up the software. Every part of building software has to move together, in a direction — and AI, for all its power, only ever pushes on one part. The teams that win with it won’t be the ones that generate the most code. They’ll be the ones that redesigned the whole process around what the tools changed.
That redesign is what I’m working on. More soon.
If this matched something you’re seeing on your own team, subscribe — the framework I’m building towards is what the next pieces work out, one part of the process at a time. And I read every reply: tell me your own “yes, but.”
Sources: METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” (2025) — note the authors’ caveat that the result is specific to experts on large, familiar codebases; Google Cloud, 2025 DORA Report; Faros AI engineering telemetry; Peng et al., GitHub Copilot RCT (2023).