--- title: "AI Didn't Remove the Bottleneck — It Moved It" description: "Cheap code production doesn't raise throughput if review and integration can't keep up. The bottleneck moves downstream — that's where the work is" url: https://sade.dev/en/journal/ai-didnt-remove-the-bottleneck/ lang: en author: "Muhammet Şafak" published: 2026-06-17 updated: 2026-09-06 section: Journal tags: ["ai-workflow","productivity","opinion"] summary: "Making code production three times faster does not triple throughput; it moves the constraint one station downstream and grows a pile of work in progress in front of it. That pile is where the review queue, the flaky suite and the integration bugs come from. The durable investment is the unglamorous downstream: deterministic verification, idempotent integration, and the obvious failure caught at the commit boundary." --- # AI Didn't Remove the Bottleneck — It Moved It > Making code production three times faster does not triple throughput; it moves the constraint one station downstream and grows a pile of work in progress in front of it. That pile is where the review queue, the flaky suite and the integration bugs come from. The durable investment is the unglamorous downstream: deterministic verification, idempotent integration, and the obvious failure caught at the commit boundary. A team I watched started shipping roughly twice the code once they leaned on agents. Six weeks later they were shipping *slower*. The pull-request queue had tripled, CI was red more often than green, and two incidents traced back to changes nobody had really read. Output went up; throughput went down. Nothing about that is mysterious. They sped up one station on the line and called it a win. ## You can't speed up one station and call it throughput A delivery pipeline is a line of stations: write → review → integrate → verify → release. Its throughput is set by the **slowest** station, not the fastest. Make writing 3× faster and, if review and verification stay where they were, you haven't tripled throughput — you've just moved the constraint one station downstream and grown a pile of work-in-progress in front of it. That pile isn't free. It's unreviewed PRs aging into merge conflicts, half-integrated branches, a test suite that grew faster than anyone can keep green. The bottleneck didn't disappear when code got cheap. It relocated — and got harder to see, because it stopped looking like "typing code" and started looking like "waiting." ## DORA already has the word for this: amplifier Data from the [2024](https://dora.dev/research/2024/dora-report/) and [2025](https://dora.dev/dora-report-2025/) DORA (DevOps Research and Assessment) reports lands on the same point from the other side: AI is an **amplifier, not a shortcut**. Teams with strong delivery practices get more out of it; teams without them ship their dysfunction faster. Both reports saw AI adoption *correlate with lower stability* — because the process, not the typing, was always the real constraint. An amplifier turns up whatever you feed it. Feed it a clean signal and it's louder and clearer; feed it noise and it's just louder noise. AI doesn't decide which one you've got. Your downstream does. ## Where the bottleneck actually went It moved to the parts that were always the expensive ones, and are now drowning: - **Review.** Generation produces PRs faster than humans can give them real attention — so review degrades into rubber-stamping, which is how unread changes reach production. - **Verification.** Tests are now nearly free to write, which is exactly why suites fill with [flaky, timing-dependent ones](/en/journal/flaky-tests-and-determinism) that erode trust faster than they build it. - **Integration.** More code, written faster by more hands, means more coupling and more ways for [the same message or request to arrive twice](/en/notes/idempotency-duplicate-delivery) and corrupt state. None of these is a typing problem. All of them are the bill for typing faster. ## The durable investment is the boring downstream So the engineering edge in this era isn't "the AI wrote it." It's keeping **the cost of trusting what was written** low enough that the new bottleneck doesn't choke. That work is unglamorous and it's where I'd spend the time AI gives back: - Make verification **deterministic**, so a green check means something and review can lean on it. - Make integration **idempotent and resilient**, so faster, messier change doesn't turn redelivery into a double-charge. - Make review about architecture, not commas — hand the mechanical parts to tools so the human attention you can't scale goes to the decisions that matter. - Catch the obvious failure at the **commit boundary**, not three stations later in CI where it costs a hundred times more. This is the same lesson as ["vibe coding lowers the cost of a first version, not the cost of being wrong"](/en/journal/can-you-ship-vibe-coded-to-production) — read at the level of the whole pipeline instead of a single change. ## When does this not apply? If your real constraint genuinely *is* code production — a true greenfield, a solo prototype, a spike where there's nothing downstream to protect yet — then go fast and don't build process for a system that doesn't exist. The shift only bites once there's something to keep honest: a team, a queue of reviews, a production others depend on. Knowing which world you're in is the actual judgment call. Most teams shipping twice the code are no longer in the first one. --- AI didn't make engineering cheaper; it made *one part* of it cheaper. The discipline is to spend the time you saved on the part that just became the bottleneck — not to pour the saved time back into producing even more of what's already piling up. ## Frequently asked **Does writing code faster increase delivery throughput?** No. A delivery pipeline is a line of stations — write, review, integrate, verify, release — and its throughput is set by the slowest one, not the fastest. Speeding up writing alone moves the constraint one station downstream and leaves unreviewed PRs aging into merge conflicts in front of it. **Where did the bottleneck actually move?** To review, verification and integration. Review degrades into rubber-stamping because PRs arrive faster than humans can give them real attention. Test suites fill with flaky, timing-dependent cases because tests became nearly free to write. And more code written faster by more hands means more coupling and more ways for the same message to arrive twice. **When does this shift not apply?** When code production genuinely is the constraint: a true greenfield, a solo prototype, a spike with nothing downstream to protect yet. The shift only bites once there is something to keep honest — a team, a queue of reviews, a production other people depend on. ## Sources - [Accelerate State of DevOps Report 2024](https://dora.dev/research/2024/dora-report/) — DORA - [State of AI-assisted Software Development 2025](https://dora.dev/dora-report-2025/) — DORA