AI Made Starting Work Free. Finishing It Didn’t Get Cheaper.
By Steve Schroeder • EliteFlow Consulting
The engineering director pulled up a chart he was proud of and, I think, a little afraid of. Pull requests opened per week had roughly tripled since the team adopted AI assistants across its squads. He read that as throughput, and for a moment so did I. Then I asked him to put a second line on the same chart: pull requests merged per week. That line had barely moved. The gap between the two lines was the whole story, and it was widening every week like a mouth opening.
What lived in that gap was work that had been started and not finished. Branches that existed but had not landed. Code that had been generated, opened for review, and then set down while its author moved on to generate the next thing, because generating the next thing had become nearly free. Every one of those open pull requests was real effort already spent, sitting still, waiting. The team had not gotten more done. It had gotten better at beginning.
The Draft Was Never the Expensive Part
Here is the mechanism, stated plainly. AI dropped the cost of producing a first draft of almost anything close to zero. A function, a test suite, a migration script, a config change, the starting version now arrives in minutes instead of hours. But producing a draft was never the expensive part of software delivery. The expensive part is everything that turns a draft into something safe to release: reading it closely enough to trust it, reconciling it with everything else in flight, deciding whether it should exist at all. Those steps still run at human speed, because they are acts of judgment, and judgment did not get cheaper when generation did. So you now have a stage that produces work at machine speed feeding a stage that absorbs it at human speed. Work piles up exactly at that seam. It could not do anything else.
This is the uncomfortable truth, and it is easy to miss because the thing that exploded looks like productivity. Those open pull requests feel like progress. They are the opposite. A pull request that sits open for two weeks is not two weeks of value in transit. It is two weeks of decay. It gets reopened, re-read, merged against a codebase that has moved underneath it, re-reviewed because the reviewer forgot the context, and sometimes abandoned entirely after all that effort, which is the purest waste of all. The team mistook a rising pile of unfinished work for a rising rate of finished work, and the tool encouraged the mistake by making the pile so easy to grow.
Waste Is Delay, Not Effort
The AI added enormous effort to the front of the stream, and almost none of it converted to delivered value, because the constraint was never the writing. Nobody on that team was short of code. They were short of the human attention required to finish it, and no amount of faster starting relieves a shortage of finishing. It makes it worse, the way opening more lanes onto a bridge that has not gotten any wider does not speed up traffic. It just moves the jam closer to the water.
A pull request that sits open for two weeks is not two weeks of value in transit. It is two weeks of decay.
Stop Measuring the Wrong Line
So the reframe is not to slow the generation down, and it is certainly not to abandon the tool. It is to stop measuring the wrong line. Starting work is now abundant and nearly free, which means it has stopped being a useful signal of anything. The number that matters is not how much work you can begin. It is how fast work can cross the finishing stage, the review-and-integrate seam where machine output meets human judgment. That stage is your constraint now, whether or not you have named it, and until you measure the wait in front of it you are flying on a throughput number that measures your capacity to accumulate unfinished things.
The good news hiding in the bad chart is that this constraint is unusually visible once you look for it. The gap between opened and merged is sitting right there in tools you already run. You do not need a new platform to see it. You need to plot the second line, watch how long items sit in the gap, and treat that waiting time as the real cost it is rather than the progress it impersonates.
The Question the Director Hadn’t Asked
Then the honest question is the one the director had not yet asked himself. His team could now start nearly unlimited work. So what governs how much of it actually reaches a customer, and what is that finishing stage waiting on that no amount of faster starting will ever supply?
Find the Seam Where Your Work Piles Up
If your team is starting far more than it finishes, the constraint is hiding in the gap between opened and merged — and it’s already sitting in the tools you run today. EliteFlow Consulting offers complimentary 60-minute Operational Flow Diagnostic sessions for COOs and SVPs of Engineering at $200M+ companies. We’ll plot your second line, quantify what’s decaying in the wait, and map your single highest-impact finishing constraint in financial terms specific to your organization.
Schedule a Flow Diagnostic#ValueStreamMapping #DigitalTransformation #OperationalExcellence #FlowIntelligence #AIProductivity #SoftwareDelivery