A team adopts AI, points it straight at the code, and tells leadership to expect something like a 4× speed-up. Months later they’ve got maybe 1.5×, and nobody can quite say where the other half went. I’ve spent the last year re-mapping our own pipeline one stage at a time, and the missing speed was never lost. It’s locked in the parts they never touch.
- 01 The speed you’re missing isn’t gone — it’s trapped in the stages you never pointed AI at.
- 02 If implementation is half your cycle, making it twice as fast leaves you only a third quicker overall.
- 03 That’s Amdahl’s law, applied to how your team ships instead of how your code runs.
- 04 Closing the gap means re-mapping the whole pipeline, not bolting a coding tool onto it.
Amdahl’s law, applied to your team
Amdahl’s law is an old rule from computing: speeding up one part of a process only helps in proportion to how big that part was. Make a stage that’s half the work infinitely fast, and you’ve still only halved the total. The rest sets a hard ceiling.
Think of a road trip where you could teleport through one city instantly. Nice — but you still have to drive everything either side of it. The drive decides when you arrive, not the teleport.
Implementation is that one city. Here’s the maths when it’s half your cycle:
Implementation = 50% of your delivery cycle.
Make it 2× faster: 0.50 + 0.50/2 = 0.75 of the time → 1.33× overallMake it 10× faster: 0.50 + 0.50/10 = 0.55 of the time → 1.82× overallMake it infinitely fast: 0.50 of the time → 2× overall, ever
The half you didn’t touch is the ceiling. You can’t beat 2×.The parts you left alone
The PRD — the product spec — still takes a week. The ADR, the written record of an architecture decision, still gets scheduled three days out. QA is still a queue. Designs still need iterations and sign-off. Make one stage fast and leave the rest where it was, and the cycle barely moves.
What I actually did, in order
I re-mapped our pipeline one stage at a time, and the order turned out to matter.
Code review went first, before we leaned on AI anywhere else, because it was the clearest bottleneck. A single automated pass now clears the low-level noise on every PR and leaves the humans for the high-level design calls. Average review time dropped from two days to a few hours. We more than doubled the PRs we merged in a week — and that number has kept climbing, to roughly three to four times what it was at launch. That rollout became a story in itself: how the AI reviewer went from ignored to mandatory, earned rather than ordered.
Implementation came next. Different work gets different practices, but across implementation and review combined we’re now seeing a two-to-four-times speed-up. It landed harder for us than it does for most, precisely because review was already re-mapped to absorb the extra volume.
Post-release investigation is the newest piece, and the one surprising me most. It leans on monitoring we’d already wired up with predefined traces. A workflow investigation that used to take me ten to fifteen minutes — pull the metric, cross-reference the logs, find the thread — an AI now does in under three, and hands back a summary. Identifying issues is easily three times faster.
Then the honest part. QA has a few working patterns but still needs a human in the loop on nearly everything. The pre-development phase is barely touched: exploratory work, design, the PRD, framing the problem and getting sign-off all still sit with people outside engineering, and that stage now sets our ceiling. Amdahl’s law, playing out on my own team: I compressed the stages I controlled, and the one I don’t is the cap.
“We use AI” was the easy part. Redesigning the system so the boost actually lands is the real work — and the last stages are the hardest, because they ask for new discipline from people who never signed up for it. That is exactly why the gap stays open.
A faster keyboard doesn’t fix a slow pipeline. The boost only shows up when you redesign everything you didn’t point the AI at.