Here's a number that should stop every engineering manager cold: teams using AI coding assistants report writing code up to 55% faster, according to GitHub's own Copilot research. Yet a growing pile of DORA metrics data shows that deployment frequency and lead time for changes have barely budged at most of those same companies. The code comes out faster. The software does not.
I've spent the last eighteen months embedded in this contradiction, both as someone who ships production code and as a reviewer who has watched a dozen teams adopt Copilot, Cursor, and Claude Code. The pattern repeats everywhere. Velocity on the keyboard goes up. Velocity to the customer stays flat, or occasionally gets worse. The bottleneck simply moved, and most teams did not notice it move.
This article breaks down exactly why AI coding tools accelerate code but stall software delivery, with real numbers, a worked example from a team I audited, and a comparison of where the time actually goes. If you're paying for AI assistants and wondering why your release cadence looks the same, this is for you.
Key Takeaways
- Writing code is rarely the bottleneck. On most teams it's under 25% of the delivery cycle. Speeding it up 2x moves the needle less than you think.
- AI shifts work downstream. More code means more review, more testing, more integration friction, and more surface area for security bugs.
- AI-generated code carries measurably more defects, which inflates the exact stages that already dominate your lead time.
- Delivery speed is a systems problem. CI/CD, review capacity, test reliability, and deploy safety determine throughput, not typing speed.
- The fix is to measure your real cycle time and invest in the slow stages, not the fast one.
- Treat AI output like any untrusted dependency: review, test, and verify before it reaches production.
The core mistake: confusing code output with software delivery
Software delivery is the whole pipeline from idea to running feature in front of a user. Code authoring is one station on that assembly line. When you speed up a single station, total throughput only improves if that station was the constraint.
In lean manufacturing this is textbook. The Theory of Constraints says a system's output is limited by its slowest step. Optimizing anything other than the bottleneck produces local improvement and zero global improvement. AI coding tools optimize the authoring station beautifully. But for most teams the authoring station was never the slow one.
Think about your last non-trivial feature. How much of the calendar time was spent literally typing code versus waiting on review, fixing failing tests, resolving merge conflicts, waiting for a staging environment, chasing a flaky pipeline, or writing the migration nobody wanted to touch? For the teams I've measured, keyboard time is the smallest slice.
Where delivery time actually goes
Across a handful of mid-size teams I've reviewed, a rough breakdown of a feature's lead time looked like this:
- Understanding the problem and design: 20–30%
- Writing the code: 15–25%
- Code review and rework: 15–25%
- Testing, QA, and bug fixing: 20–30%
- Integration, deploy, and release coordination: 10–20%
AI accelerates the second bucket and, if you're lucky, part of the first. It does nothing for the rest by default. Worse, by producing more code faster, it feeds larger and more frequent changes into review and testing, which are already among your slowest stages.
A worked example: the 3-week feature that stayed 3 weeks
Let me make this concrete. I audited a 6-engineer product team that adopted Cursor and Copilot company-wide in Q1. Before adoption, a representative feature took about 15 working days from ticket to production. Here's the before and after, measured across 20 comparable features.
Before AI:
- Design and spec: 3 days
- Coding: 4 days
- Review and rework: 3 days
- Testing and bug fixing: 3.5 days
- Integration and deploy: 1.5 days
- Total: 15 days
After AI:
- Design and spec: 3 days (unchanged)
- Coding: 2 days (halved, real win)
- Review and rework: 4.5 days (up, because pull requests got 40% larger)
- Testing and bug fixing: 4 days (up, more defects to catch)
- Integration and deploy: 1.5 days (unchanged)
- Total: 15 days
Read that again. They cut coding time by 50% and shipped at exactly the same pace. The two days saved on authoring were eaten by an extra day and a half of review and half a day of testing. The AI generated more code, more confidently, and reviewers had to work harder to trust it.
This is not a fluke. It's the predictable result of optimizing a non-bottleneck. The team felt more productive because typing felt effortless. The delivery data said otherwise.
Why AI makes the downstream stages heavier
The uncomfortable truth is that AI does not just fail to help downstream. It actively loads those stages up. Three mechanisms drive this.
1. Bigger, more frequent changes
When writing code is cheap, people write more of it. Pull requests balloon. A reviewer who could carefully read a 120-line diff now faces 400 lines of plausible-looking code they didn't author and don't fully trust. Review quality drops or review time climbs. Usually both.
2. More defects per line
AI-generated code carries a higher bug density than carefully hand-written code. I dug into the mechanics of this in a separate piece on why AI-generated code has more bugs and how to fix it, and the short version is that models produce code that compiles and looks right but hides subtle logic errors, race conditions, and missing edge cases. Every extra bug is caught in testing or, worse, in production. Both stages are already slow.
3. Security surface area grows quietly
AI assistants happily suggest insecure patterns: string-concatenated SQL, missing input validation, hardcoded secrets, outdated crypto. If you haven't set up a process to vet AI coding assistants for security flaws before you trust them, you are shipping those patterns into your codebase at machine speed. Security review, threat modeling, and remediation are among the most expensive stages of all.
So the model is generous with code and stingy with everything code requires afterward. The net delivery effect is a wash, or negative, unless you deliberately reinforce the downstream stages.
AI coding tools vs the real delivery bottlenecks
Here's a comparison of the major stages of delivery, how much AI helps each one today, and what actually moves the needle instead.
| Delivery stage | Typical share of lead time | AI impact | What actually speeds it up |
|---|---|---|---|
| Design and specification | 20–30% | Small positive | Clear requirements, small scope, good docs |
| Writing code | 15–25% | Large positive | AI assistants, good scaffolding |
| Code review | 15–25% | Negative (bigger diffs) | Smaller PRs, fast reviewer turnaround, automation |
| Testing and QA | 20–30% | Negative (more defects) | Reliable test suites, good coverage, tested backups |
| Integration and deploy | 10–20% | Neutral | Solid CI/CD, feature flags, rollback safety |
The lesson jumps off the table. AI wins one column and hurts two. If you want faster software, you invest in the columns AI doesn't touch or actively harms.
How to actually speed up software delivery with AI in the mix
None of this means you should ditch AI assistants. It means you should stop treating typing speed as the goal and start engineering your whole pipeline. Here's the walkthrough I give teams.
- Measure your real cycle time first. Instrument your pipeline to record time-in-stage for the last 20 features. You cannot fix a bottleneck you haven't located. Most teams discover review or testing is their constraint, not coding.
- Cap pull request size. Set a soft limit, say 400 lines of diff, and enforce it in your workflow. Smaller PRs get reviewed faster, merged sooner, and produce fewer conflicts. AI makes large PRs tempting. Resist.
- Add an AI-output review gate. Treat AI code like a third-party contribution. Require the author to state which parts were AI-generated so reviewers apply extra scrutiny where it's warranted. If your org handles regulated data, formalize this. My guide on how to audit employee AI tool use before it creates legal risk covers the policy side.
- Harden your test suite before you scale AI usage. More generated code means more chances for regressions. Flaky tests will destroy your throughput. Invest in fast, reliable, well-covered tests so the testing stage stays a fast filter rather than a slow one.
- Verify your rollback and restore paths. More frequent changes mean more chances something ships broken. If you can't recover quickly, every incident becomes a multi-day delivery stall. It is worth taking the time to test that your backup actually restores before disaster hits, not after.
- Automate the boring gates. Static analysis, linting, dependency scanning, and secret detection should run automatically on every PR so humans spend review time on logic, not style. A solid set of webmaster and diagnostic tools can catch surface-level issues before a human ever opens the diff.
- Consider running models locally for sensitive code. If your concern is data leakage or reproducibility, a local setup gives you control. I walk through this in the guide on how to run a local LLM with Ollama for private, offline AICover image: The Torch Graduate circuit board (bottom) by Chris Whytehead, licensed under BY-SA 3.0 via Openverse.
