Jon Moshier
Jon Moshier / Notes / AI SDLC Bottleneck budding
Note · From the Notebook

AI SDLC Bottleneck

The software delivery lifecycle read as a Theory-of-Constraints pipeline: what the stages are, how to locate the constraint AI has pushed downstream to review, and the exploit-subordinate-elevate moves that relieve it.

budding Started July 11, 2026 aiagentsplanningcomplexity

AI SDLC Bottleneck

AI writes code fast now. Throughput did not rise to match. Goldratt’s claim explains the gap in one line: a system’s output is set by its single most-constrained stage, and speeding up any other stage just piles inventory in front of the constraint. AI accelerated one stage of software delivery. The constraint moved to the next one down. This note walks the three moves a constraint lens forces: define the pipeline, locate the constraint, relieve it.

The SDLC as a line of dependent stages

Strip the ceremony and software delivery is a chain of dependent steps with statistical fluctuation at each: idea and specification, design, implementation, review, integration and test, release, operate. Dependent because a stage can only work on what the stage before it passed down. Fluctuating because no stage takes a fixed time. That combination is exactly the setup for Goldratt’s dice game: a downstream station that has a good day cannot make up for the one upstream that had a bad one, because it never received the work. A bad day, though, propagates forward immediately. A balanced line still underperforms its average. Output is governed by the slowest necessary step, not the fastest.

Implementation, the stage AI targets, is a minority of the line. Estimates of how much of a developer’s time is spent writing code cluster between 25 and 35 percent; the rest is reading tickets, gathering context, waiting on reviews, debugging, coordinating, releasing. AI dropped a firehose on the narrow part of the pipe.

Measuring the constraint

The constraint is found the same way in a plant and in a repo: it is the stage where work piles up in front and starves the stage behind. Under AI the pile is unmistakable and it sits at review. Faros AI’s June 2025 telemetry across 10,000+ developers on 1,255 teams found teams with high AI adoption completed 21% more tasks and merged 98% more pull requests, while PR review time rose 91%, average PR size grew 154%, and bugs per developer rose 9%. More work entering review, each unit larger, each waiting longer. That is a queue growing in front of a constraint, and it is the amplifying kind, not the settling kind. The same study found no significant correlation between AI adoption and delivery gains at the company level. Local speedups that do not clear the constraint do not aggregate.

Two formal results say the ceiling was predictable. Amdahl’s law bounds the speedup of a system when you accelerate only part of it: if coding is 30% of cycle time and you make it infinitely fast, total improvement caps near 43%, because the other 70% is untouched. Double coding speed and the system gains roughly 18%. Which is why the ceiling is no surprise: six independent studies at ~90% tool adoption converge on about 10% organizational productivity gains. Little’s Law supplies the other half: cycle time equals work-in-progress divided by throughput, so flooding the pipeline with WIP while review throughput stays fixed lengthens cycle time arithmetically. The 100,000-developer NBER study is the same physics measured directly: a 741% rise in lines of code attenuates to a 20% rise in releases, because review and merge stay human-paced.

To locate the constraint in a real system, measure queue time, not touch time. Decompose lead time and watch where work waits. The leading indicator is time to first review: it degrades first when generation outruns review bandwidth. The SDLC Delivery Metrics for AI-Assisted Engineering note is the instrument panel for this: DORA lead time and change failure rate as the end-to-end pair, PR cycle time and code churn as the where-inside-review pair. One caution on the headline numbers. PR-size inflation is reported anywhere from Faros’s 154% to Jellyfish’s 18%; the evidence is directionally consistent and quantitatively noisy, all of it correlational.

Relieving the constraint

Goldratt’s five focusing steps say what to do once the constraint is named. The order matters, and it front-loads the free moves before the expensive ones.

Exploit it. Wring maximum output from review as it exists before spending. The highest-leverage move is shrinking the batch: the Cisco/SmartBear study of 2,500 reviews found defect-detection yield collapsing past 400 lines, so AI enlarging PRs directly degrades the constraint’s output. Stop feeding the constraint work it will only reject. Hand mechanical passes (style, lint, obvious bugs) to an AI reviewer so human attention goes to intent and design, which is the part of review that does not automate: the reviewer’s real cost is reconstructing why the change was made, not reading the diff.

Subordinate everything else. This is the step that breaks intuition. Run the fast stages below their capacity so they do not flood the constraint. In Drum-Buffer-Rope terms, review is the drum and generation must be roped to it: cap the “ready for review” queue and stop opening new work faster than review clears, exactly the single-analyst QA pattern. Work-in-Progress Limits on open PRs often do more for cycle time than any coding-speed gain, and Little’s Law says why. Idle generation capacity looks like waste to a manager measured on local utilization; subordinating means accepting it, because output the constraint cannot absorb is not throughput, it is inventory.

Elevate it. Now spend to raise review capacity. Add reviewers, but the structural move is reducing how much review each change needs. Spec-driven development pushes the specification and acceptance criteria upstream so the reviewer checks against an agreed intent rather than reverse-engineering it, shrinking the understanding cost that dominates review. See Spec-Driven Development and [private link].

Then repeat, because elevation moves the constraint. Clear review and the pile reappears at integration, test, or release. Clear those and it can leave engineering entirely: the NBER marketplace panel found new-app supply rising while total app usage stayed flat, the constraint relocating to product discovery and adoption. Watch that the new constraint is not the metric itself: pair every throughput number with a stability number, the design logic of the DX Core 4, or teams will split PRs to inflate frequency and suppress incidents to protect failure rate.

Where the evidence is thin

The bottleneck-shift story is well-triangulated in direction and soft in magnitude. Note the incentives: the heaviest-cited telemetry comes from vendors selling the exact remedy (Faros and Jellyfish sell delivery metrics, CodeRabbit sells AI review), so the load-bearing magnitude should rest on the disinterested work, the NBER panel, the Cisco/SmartBear reviews, and the METR-style RCT. The Faros and NBER results are observational, so AI adoption is confounded with team, task, and codebase; the 1.7x-more-issues finding on AI PRs partly reflects AI being pointed at larger changes, not proof it writes worse code.

There is also a framing question the before/after numbers cannot settle: whether AI moved the constraint to review or merely made a constraint that was already there louder. Review and integration have been the classic delivery queues for decades. If review was already binding pre-AI, the honest claim is that AI exposed and amplified it, not that it relocated it, which reads the Faros jump as a visibility effect as much as a shift. Either way the relief playbook is the same; the causal story is weaker than “the bottleneck moved” suggests. A 16-developer RCT found experienced contributors on mature codebases slowed by 19% while forecasting a 24% speedup, a reminder the gains concentrate unevenly across the skill and complexity distribution. And Theory of Constraints itself fits cleanly only when the constraint holds still long enough to exploit; in a high-variability system the constraint can move faster than you can subordinate to it, a Cynefin Framework judgment about whether the pipeline is ordered enough to have a locatable constraint at all.

Try it

Find your constraint from your own git history (1-2 hours, GitHub API + a script). Pull merged PRs for one active repo over 90 days (gh pr list --state merged --json createdAt,mergedAt,additions,deletions,reviews). For each, compute time-to-first-review, review-to-merge, and PR size, then take medians. The stage with the longest median wait is your drum. Split the set by AI-assisted vs not: the prediction is AI PRs larger and slower to first review even if total cycle time looks flat. If time-to-first-review is the biggest bucket, generation is roped too loose.

Rope the line and watch cycle time fall (a sprint, any team tool). Set a hard WIP limit on open PRs awaiting review, below your current average. By Little’s Law, capping WIP with fixed throughput must lower cycle time; the interesting question is whether merge rate holds or generation idles visibly. That visible idle is subordination working, not waste. Reverting the cap and watching cycle time climb back is the dice game on your own board.

See also

Sources

← All notes Read recent essays →