AI Writes Code Faster. Why Aren't We Shipping Faster?

The Bottleneck Has Shifted — Most Teams Haven't Noticed

As coding agents become more widespread, more and more developers are sold on the value AI brings to the coding phase. But a sharp question is emerging: if AI has made writing code faster, why hasn't software delivery speed kept pace?

This is exactly the core argument a Reddit user put forward in a community discussion. His take: the bottleneck has shifted from "writing code" to "the entire software delivery process." In the pre-AI era, coding itself was the most time-consuming step. Now that this step has been dramatically compressed, faster coding won't automatically translate into more features shipped or more frequent releases — not unless you also optimize the downstream steps: testing, review, and deployment.

This observation points to a classic constraint theory problem in software engineering — a system's overall throughput is determined by its slowest stage. When AI turns the "faucet" of the coding stage wide open, the flow gets backed up in the downstream pipes of testing and review.

The Theory of Constraints (TOC) was systematically laid out by Israeli management theorist Eliyahu Goldratt in his 1984 book The Goal. Its core proposition: the overall output rate of any system is always determined by its weakest link (the bottleneck). Optimizing non-bottleneck stages won't increase overall throughput — it may even pile up more "work-in-progress inventory" in front of the bottleneck, creating waste. In software engineering, the DevOps world has evolved a similar idea into Value Stream Mapping — visualizing the full flow from code commit to production to identify what's truly limiting delivery speed. The proliferation of AI coding tools has effectively expanded the capacity of the "write code" workstation in the value stream. If the capacity of downstream workstations — testing, review, deployment — doesn't expand in tandem, the upstream gains are not just wasted; they make the backlog at the bottleneck even worse.

Use CI and Automation to Absorb the Surge in Code Output

The author's first recommendation is to aggressively use CI and automate review and verification steps — including functional tests, end-to-end tests, performance tests, and more.

The logic is straightforward: if AI can produce several times more code per day than before, but validating that code still relies on humans, manual verification becomes the new chokepoint. The only way to let accelerated coding actually flow to production is to hand off as many verification steps as possible to an automated pipeline.

In other words, AI isn't just changing how individual developers work — it's forcing the entire delivery system to level up. In the past, "slow to write, slow to review" was a rough match. Today, the mismatch of "fast to write, slow to review" gets dramatically amplified. Test coverage, CI stability, and CI speed have gone from "nice-to-haves" to hard constraints that determine a team's throughput.

CI (Continuous Integration) is built on the idea that developers frequently merge code changes into the main branch, and each merge automatically triggers a build and test pipeline, catching integration issues early. Closely related concepts include CD (Continuous Delivery/Deployment) — the former means code is always in a releasable state; the latter means every change that passes tests is automatically pushed to production. A mature CI/CD system typically includes: unit tests, integration tests, end-to-end tests (full-chain tests simulating real user behavior), static code analysis, security scanning, performance benchmarks, and more. In a world where AI is generating code at scale, CI/CD pipelines evolve from "a quality assurance aid" into "the infrastructure for processing large volumes of AI-generated code." The coverage and run speed of your test suite directly determines how much AI output automation can absorb — without requiring humans to review it line by line.

Trusting AI-Generated Code Is a Mindset Shift

The second point is more contentious — and cuts deeper into team culture: teams need to help colleagues trust AI-generated code more.

The author argues there's still a mindset that needs to change. Many engineers manually verify things that have already been verified, or that could be automatically verified. This redundant review adds friction without necessarily delivering a proportional quality benefit.

He goes further with a nuanced tiered approach: calibrate the rigor and cost of review based on how critical the component or system being developed actually is. A simple reporting task doesn't need the same scrutiny as a real-time transaction system. He advocates removing any checks deemed inefficient — and has even started to wonder whether code review itself sometimes falls into that category.

This is the boldest claim in the piece. Code review has long been considered a cornerstone of engineering quality, yet the author suggests that in certain low-risk scenarios it may be an inefficient friction point. This will likely provoke polarized reactions in the professional community: supporters will appreciate the pragmatism of "investing review effort proportional to risk," while critics will warn about the technical debt and security risks of over-trusting AI-generated code.

Without Metrics, You Can't Tell If You're Actually Shipping Faster

The third recommendation returns to the essence of engineering management: you need a solid set of metrics to tell whether delivery is genuinely improving.

The author lays out the KPIs he tracks:

• PR throughput (weighted by change complexity) — not just counting PRs, but accounting for how complex the changes are
• Merge to Production deploy time — measuring how long it takes for code, once written, to actually go live
• Incidents and reworks — used to balance speed against quality

The design philosophy behind this set of metrics is admirably restrained: measure speed (throughput, deploy time), but constrain it with incidents and reworks to prevent trading quality for velocity. In particular, using complexity-weighted PR throughput rather than a simple count avoids the hollow optics of "gaming PR numbers."

This metrics framework closely echoes the DORA metrics (DevOps Research and Assessment), which have become highly influential in software engineering in recent years. DORA was developed by a Google research team based on large-scale industry surveys, and defines four core indicators of software delivery performance: Deployment Frequency, Lead Time for Changes (time from code commit to production), Change Failure Rate, and Mean Time to Restore. The author's "merge to production time" maps to Lead Time for Changes; "incidents and reworks" maps to Change Failure Rate — the alignment is striking. Notably, DORA research finds that high-performing teams don't face a tradeoff between speed and stability — they achieve both faster delivery and lower failure rates. This aligns with the author's design of using incident metrics to "constrain" speed metrics: chasing throughput while ignoring quality will ultimately eat up speed gains through constant rework.

The Real Value of This Discussion

At its core, this post is an open professional conversation. The author isn't presenting a definitive answer — he's sharing his own thinking from practice and inviting other practitioners to share how they're adapting in the LLM era.

Its value lies in surfacing a question that's easy to overlook: productivity gains from AI don't automatically translate into business value. Faster coding is only the first step. The entire delivery chain — testing, review, deployment, measurement — all need to be revisited and optimized. Otherwise, teams are just helping developers pile code up faster in front of a downstream bottleneck.

For teams currently adopting AI coding tools, three takeaways stand out: automate verification steps wherever possible; invest in review proportional to risk rather than applying a one-size-fits-all standard; and use a balanced set of metrics that account for both speed and quality to continuously recalibrate. As for the more contentious question of whether code review should be scaled back — there's no universal answer. It has to be weighed against the criticality of the specific system involved.