AI coding assistants can speed up individual coding, but delivery stays slow when review, testing, and release cannot absorb the extra pull requests. The bottleneck simply moves downstream: reviewers wait longer, test queues grow, and release processes stay unchanged. Fixing throughput means changing the workflow around those stages, not switching tools.
Plenty of engineering leaders are living some version of this right now. The team rolled out GitHub Copilot, Cursor, Claude Code, or a mix of all three. Developers say they write code faster. The pull request count is up. And yet the roadmap is not moving any faster, release dates still slip, and the people closest to production look more tired, not less.
That is not a sign the tools failed. It is a sign the delivery system around the tools never changed. This post explains why that happens, where the bottlenecks usually show up, what actually fixes review, testing, and release when AI is in the loop, and what a team can do in the next four weeks.
If coding got faster, why didn't delivery get faster?
Because coding was rarely the slowest part of delivery. When AI assistants make writing code faster, the work reaches review, testing, and release sooner, and those stages, unchanged, become the constraint that sets your pace.
Individual coding speed is not system throughput
It helps to separate two ideas that often get blended together:
Individual coding speed is how quickly one engineer turns an idea into a working diff.
System throughput is how much finished, working change reaches production and users over a given period.
AI coding assistants mostly improve the first. Delivery outcomes depend on the second. More diffs per engineer is not the same as more value reaching production. A change that sits in a review queue for days, waits on a flaky test suite, and then rides a monthly release train has not been delivered any sooner just because it was written in an afternoon.
This is basic flow thinking, the same idea behind lean manufacturing and the theory of constraints: a system moves only as fast as its slowest stage. Speed up a stage that was not the constraint, and you mostly create a bigger pile of work in front of the stage that is.
The typical failure mode
Here is the pattern we see most often. AI adoption goes well at the keyboard. Engineers generate more code, and they generate it in bigger chunks, because the assistant makes a large change feel cheap to write. Then a larger volume of pull requests, often with larger diffs, arrives in a review and release system that was designed for a smaller, human-paced flow of changes.
The results are predictable:
Pull requests wait longer for a first review.
Reviewers skim large diffs or push back on them, which creates rework.
Test pipelines run more often and take longer, and flaky tests block more merges.
Releases still go out on the same cadence, in the same batches, through the same approvals.
The team feels busier. Delivery metrics barely move. Sometimes quality slips, because more change is passing through the same safety checks with less attention per change.
Adoption is not value
License counts, acceptance rates, and lines of generated code tell you the tools are being used. They do not tell you whether more working software is reaching customers.
The answer is not a different assistant
It is tempting to conclude that the tool is the problem and to start a new evaluation. In most cases that is the wrong move. If coding is already faster and work is stalling later in the path, a different assistant will not clear the review queue or shorten the release cycle.
To be clear about where Liatrio stands: we do not help teams choose among GitHub Copilot, Cursor, Claude Code, or any other coding assistant. Our work is on the delivery system around those tools, meaning the workflow, review practices, test feedback, and release path that decide whether faster coding turns into faster delivery. You can succeed with any of these modern harnesses if you understand the system behind them.
Where do the bottlenecks usually show up?
Bottlenecks usually show up in three places after the code is written: review, testing, and release. The bottlenecks are now upstream and downstream of building software. Most teams have one dominant constraint among the three, and the fastest way to find it is to measure where work waits, not where it is being worked on.
Review
Code review is the most common bottleneck after AI adoption, for a few reasons:
Waiting for reviewers. Review capacity did not grow when coding speed did. Often a small number of senior engineers review most changes, and their queue grows first.
Unclear intent on AI-generated diffs. When an engineer writes every line, they can usually explain why each part exists. When an assistant generates a large share of a change, the intent behind it can be harder to see, and the reviewer has to reconstruct it.
Review standards built for smaller changes. Many teams' review habits assume small, human-paced changes where a reviewer can hold the whole diff in their head. Larger AI-assisted diffs break that assumption.
Testing
Testing becomes the constraint when the extra change volume exposes gaps that were tolerable before:
Slow or incomplete automated tests. A test suite that takes a long time to run, or that does not cover the paths being changed, turns every merge into a wait or a gamble.
Environments that cannot keep up. Shared test or staging environments become contended when more changes need validation at once.
Quality issues that escape. Large, under-specified changes are harder to test well. When nobody wrote down what the change was supposed to do, nobody can be sure the tests prove it.
Release
Even with fast review and solid tests, the release process can cap how often faster coding actually ships:
Batching. Changes accumulate and ship together, so each one waits for the slowest item in the batch.
Manual approvals. Change advisory boards, sign-offs, and manual checklists add fixed wait time to every release, no matter how quickly the code was written.
Change windows. If production changes are only allowed at certain times, that schedule, not coding speed, sets your maximum delivery pace.
A short diagnostic to find your constraint
You do not need a large measurement program to locate the bottleneck. Pull a sample of recently shipped changes and look at three numbers for each:
Time in review: from pull request opened to approved and merged.
Test wait time: time spent waiting on pipelines, environments, or manual QA.
Time to release: from merge to running in production.
Compare those to time to first commit, the part AI assistants mostly speed up. If coding takes hours and the other stages take days, you have found where your effort should go. The stage with the longest wait is your constraint.
What actually fixes review, testing, and release when AI is in the loop?
Changes to the workflow around each stage fix it, not changes to the coding tool. That means giving reviewers a clear contract for each change, investing in automated test feedback, shrinking release batches and manual gates, and adopting a shared, spec-driven workflow across the whole path.
Fixing review
Require a written spec or acceptance criteria with the change. A short description of what the change should do, and how you will know it works, gives reviewers a contract to review against. Instead of reverse-engineering intent from a large diff, they check the diff against the spec.
Keep diffs reviewable. AI makes big changes cheap to write, but not cheap to review. Set a norm that changes are as small and focused as the work allows. If a change cannot be reviewed with confidence, split it or send it back before merge.
Spread review capacity. If every change routes to one senior engineer, that person is your bottleneck. Broaden who can review which areas, pair less experienced reviewers with experienced ones, and make review an expected part of everyone's day rather than an interruption.
Fixing testing
Invest in the automated tests the extra volume now requires. If more change is flowing through, the safety net has to scale with it. Prioritize fast, reliable tests on the paths that change most often, and fix or remove flaky tests that block merges.
Improve environment feedback. Engineers need to know quickly whether a change works in a realistic environment. Reduce contention for shared environments and shorten the time from push to a trustworthy result.
Reject "looks right" as a substitute for checks. AI-generated code can read cleanly and still be wrong. Plausible-looking code is not evidence. The spec and the tests are the evidence.
Fixing release
Reduce batch size. Smaller, more frequent releases mean each change waits less and each release carries less risk.
Reduce the manual gates that now dominate lead time. Where a manual approval exists to manage risk, ask whether automated checks, progressive rollouts, or feature flags can manage that risk with less waiting.
Ship through the normal production path. AI-assisted work should go through the same pipeline, the same checks, and the same release process as everything else. A side process for "AI work" hides the real bottlenecks instead of fixing them.
Workflow over tools
The biggest lever is not inside any one stage. It is a shared way of working that helps the whole path, not only the editor:
A spec-driven workflow. Spec-driven development means writing a short, structured description of the intended change, including scope and acceptance criteria, before generating code. The same spec guides the assistant, gives the reviewer a contract, and tells the tester what to prove. Read more in our guide, What Is Spec-Driven Development? A Practical Guide for AI-Assisted Engineering Teams.
Repo context files. Files in the repository that describe architecture, conventions, and constraints help assistants produce changes that fit the codebase, which means less rework in review.
Shared conventions. Agreed norms for change size, spec format, test expectations, and review turnaround make the whole team's output easier to review, test, and release.
How do we know the fix is working?
You know it is working when lead time falls with the wait stages visible, and quality holds or improves at the same time. Measure the time work spends waiting in review, test, and release separately, and compare against a pre-change baseline for the same teams and the same kinds of work.
Measure lead time with the wait stages visible
A single blended lead time or cycle time number can hide what is happening. Break it into stages so you can see where work spends its time:
In review: pull request opened to merged.
In test: waiting on pipelines, environments, or manual validation.
In release: merged to running in production.
When you fix the real constraint, the wait time for that stage should shrink. Expect the next constraint to appear somewhere else. That is normal and a sign of progress.
Watch quality at the same time
Faster delivery that breaks production is not an improvement. Track quality alongside speed:
Change failure rate: the share of deployments that cause a failure in production.
Escaped defects: bugs found after release that tests and review should have caught.
Rework after merge: follow-up fixes, reverts, and patches to recently merged changes.
If lead time drops while these hold steady or improve, the fix is real. If lead time drops and quality slips, you have traded one problem for another.
Compare against a baseline
Measure the same teams and the same work types before and after the change. Comparing an AI-assisted team on greenfield work to a different team on legacy maintenance tells you very little.
What should a team do in the next four weeks?
Spend the next four weeks finding where work waits, then practicing a shared spec-driven workflow on real backlog items that must pass your normal review and release process. If coding is no longer the constraint, more prompt training alone will not move delivery.
Week by week, in practice
Map where work waits today. Use the diagnostic above on a sample of recent changes. Identify the stage with the longest wait. If coding is no longer the constraint, do not spend the next month on prompt training alone.
Agree on a shared workflow. Pick a lightweight spec format, a norm for change size, and clear review expectations. Add or improve repo context files so the assistant has what it needs.
Apply it to real backlog work. Run actual backlog items, not toy exercises, through the new workflow. Every change must pass your ordinary review, testing, and release path, with no shortcuts.
Measure against your baseline. Compare time in review, test wait time, time to release, and quality signals against where you started. Decide what to keep, what to change, and which constraint to tackle next.
How Liatrio's Forge for Builders fits
Some teams want help running this with structure. That is what Forge is for. It is a four-week cohort for 8 to 12 engineers. The cohort practices a shared spec-driven workflow, then runs a Flashbuild on the team's real backlog work, measures delivery against the team's own baseline, and ends with a demo day for leadership.
Forge is not a tool selection exercise and it is not another license. It is focused practice on the workflow that turns faster coding into faster delivery, done inside your real review and release process.
Where to go next
If your team adopted AI coding assistants and delivery still feels slow, the fix is in the system, not the editor. See how Forge helps teams fix review, testing, and release bottlenecks on real work.
FAQ
Why would pull requests increase but throughput stay the same?
Because throughput is limited by the slowest stage after coding. If review, test, or release cannot absorb the extra work, pull requests simply wait longer. The team feels busier, and delivery metrics barely move.
Should we switch AI coding tools if delivery has not improved?
Usually no. If coding is already faster and work is stalling later in the path, a different assistant will not clear the review or release queue. Stay with the tools you have and fix the workflow around them. Liatrio does not help teams pick a coding assistant.
How do we review larger AI-generated diffs without lowering quality?
Give reviewers a written spec or acceptance criteria, keep changes as focused as the work allows, and check the diff against that contract and the tests. If a change cannot be reviewed with confidence, split it or send it back before merge, just as you would with a large human-written change.
What is the first bottleneck to fix?
Start with the stage where work waits the longest after a change is written. For many teams, that is review. For others, it is test feedback or a release process that only runs on a fixed cadence. Fix the actual constraint; do not assume it is the editor.
