Teams that adopted generation tooling report writing code substantially faster. Most of them are not releasing substantially more often, and the gap between those two facts is where the interesting problem lives.
The explanation is unremarkable once stated. Producing code was one stage in a sequence, and speeding up one stage moves the constraint to the next one rather than removing it. What used to be the bottleneck is now comfortably fast, and everything downstream is exactly as slow as it was.
Review became the constraint
The most immediate effect is on code review, and it is worse than a simple volume increase.
If a team produces three times as many pull requests, review capacity has to triple to keep pace, and it cannot, because reviewing is a human activity that did not get faster. Queues grow, and work sits finished but unmerged, which feels like progress and is not.
There is a quality dimension too. Reviewing code a colleague wrote involves a shared context: you know roughly what they were thinking. Reviewing generated code that your colleague accepted has no such context, so the reviewer is doing more work per line rather than less. Larger volume and higher cost per unit is a difficult combination.
Teams handling this well have made the author responsible for the explanation. The pull request describes what the change does and why it is structured that way, and if the author cannot write that, the code is not ready regardless of whether it works.
We see this in the shape of the board rather than in any metric. Work leaves in progress quickly and then accumulates in review, which looks like a people problem and is a throughput problem.
Requirements never sped up at all
The stage before building is untouched by any of this, and on most projects it was always the expensive one.
Working out what to build requires talking to people who have not thought about it clearly, discovering constraints nobody mentioned, and resolving disagreements between departments who both believe their version is obvious. None of that compresses. Generating a feature quickly is not useful if the feature was the wrong one, and building the wrong thing faster is the actual risk of this period.
We have written about the version of this that costs the most, which is committing months before testing an assumption, in building features nobody wanted. Faster generation makes that failure cheaper to commit and no less wasteful.
The teams getting real throughput improvements are usually the ones who used the freed capacity to shorten the loop rather than to build more. Ship something small, watch real usage, decide the next thing with evidence. That was always the better approach and it was previously too slow to run often.
Read More - A Free Command Line Agent Entered the Top Five: When Open Tools Beat the Licence
The parts nobody counts
Between merged and delivered sits a set of activities that rarely appear in anyone's estimate.
Testing environments that drift and need fixing. Deployment steps someone has to watch. Migrations that require a maintenance window. Documentation. The support team learning what changed. Security review. Whatever your organisation does before a change reaches a customer.
These were always there and they were hidden by the length of the build phase. Shorten the build and they become visible, which is uncomfortable and useful, because they are usually more automatable than the work that was consuming attention.
If your deployment involves a person following a checklist, that is now a larger share of your delivery time than it was. It is also the most tractable thing on the list.
When we ask teams to time these directly for a fortnight rather than estimating them, the answer surprises almost everyone. The phases nobody tracks are usually the ones that grew.
Where the time actually went
Before changing anything, measure. Take the last twenty completed pieces of work and record four timestamps: when it was first requested, when someone started building, when it was merged, and when a customer could use it.
Most teams find something that surprises them. Requests sitting for weeks before anyone starts. Merged work waiting a fortnight for a release window. Review queues that are consistently the largest single interval.
Fix the largest gap rather than the one you find most interesting. Engineering organisations have a reliable tendency to optimise the build phase because it is the enjoyable part, which is now precisely the wrong instinct.
What this means for planning
Two practical consequences for anyone scoping software work.
Estimates that treated coding as the dominant cost are now wrong, and wrong in a specific direction: the build looks cheap and the total does not fall proportionally. A project that was six weeks of building plus four weeks of everything else does not become one week plus four. It becomes something like two plus four, because the four never moved.
And smaller batches are now genuinely available. When building took weeks, batching changes into a large release was rational. When building takes days, the release process becomes the reason for batching, and that is a process choice rather than a constraint.
The phase that quietly absorbs the saving is comprehension, which we looked at in what happens when nobody understands the system.
For a SaaS product where release cadence affects how quickly you learn from customers, that is worth more than the raw speed increase. Our SaaS development work increasingly starts with the delivery path rather than the feature list, because that is where the time is.
Frequently Asked Questions
Are we doing something wrong if we are not shipping faster?
Almost certainly not. Speeding up one stage of a sequence moves the constraint rather than removing it. The useful response is to find where the constraint moved to, which is usually review or release, and address that rather than pushing harder on generation.
How do we handle the increase in review load?
Smaller pull requests, and authors who can explain their changes. Requiring that the author describes what the change does and why it is built that way filters out code nobody understood before it reaches a reviewer, which is where most of the extra load comes from.
Should we review generated code more carefully or less?
More carefully, which is the opposite of how it usually gets treated. Code that looks finished attracts less scrutiny than code that looks like a first attempt. Plausible and subtly wrong is harder to catch than obviously incomplete, so the review bar should go up rather than down.
What is the single most common hidden delay?
Merged work waiting for a release window. It is invisible in engineering metrics because the ticket looks done, and it can easily exceed the entire build time. It is also usually the cheapest thing to fix, because the constraint is process rather than capability.
Does this change how we estimate projects?
Yes. Estimate the phases separately rather than as one figure dominated by build time. Requirements, build, review, and release now have very different characteristics, and an estimate that assumes coding is the bulk of the work will be wrong by a wide margin in both directions.
Our team resists smaller releases. What now?
Find out why, because the reason is usually real. Batching is often a rational response to a release process that is risky or laborious. Make releasing boring and small releases follow naturally. Mandating frequency without fixing the process produces the same risk more often.
Where should we spend the capacity we freed up?
On learning rather than on volume. Shorter cycles between shipping and observing real usage compound in a way that building more features does not, particularly if you are not yet certain which features matter.
Talk to our team if your team writes code faster than it did and ships at the same rate.