AI productivity gains went up on every dashboard I’ve seen. I’ve watched teams double the code they produce. I’ve watched those same teams ship on the old schedule, to the week.
Both facts hold at once. Nobody is lying about the gains, which is what makes this worth taking apart.
The Faster Motor
Picture your delivery process as a shop floor. An idea comes in one door. Something a customer can use goes out the other.
Between those two doors sit a dozen stations. Last year we bolted a much faster motor onto one of them.
The motor isn’t a trick. A component that took a day takes two hours. Tests that never got written now get written. Documentation nobody had time for now exists.
Every dashboard measured that one station. Lines produced, time to a first working draft, tickets closed. All of it went up, and the numbers are honest.
Then the quarter closes. The release notes run the same length as last year’s.
Take the Cover Off
Writing code was never the constraint. It looked like the constraint because it’s the visible station. It has a keyboard attached, and you can point at it when somebody asks what engineering is doing.
Most shops have never timed the whole run. They have timed the part with a number already attached to it.
So take the cover off and time one feature end to end. Not the coding. The whole run.
Here is the run sheet. Deciding what to build. Waiting for the decision. The design review. The second design review, after somebody senior asks a question. Waiting on another team’s API. Code review. The database review, because the release carries a migration. QA. The release window. The change board. The security review. The freeze, because it’s quarter end.
On the teams I have timed, coding is about a fifth of that run. We made a fifth of it faster.
This is the oldest rule on any shop floor. Speed up a station that wasn’t the constraint and the line doesn’t move. You get a taller pile in front of the station that is.
The Valve Marked Review
The pile has a name. It’s code review.
Every team I sit with tells the same story with different numbers. The pull requests are bigger, there are more of them, and they arrive faster.
The number of people who can review them properly has not moved at all.
The review itself got harder too. Hand written code carries the shape of a person thinking, so you can follow the reasoning. Generated code is uniformly plausible.
It all reads like somebody competent and confident wrote it. So you have to check it instead of skimming it.
The reviewer got slower per line in the same quarter the lines doubled. Your senior engineers are not enjoying this era. They are also being told daily how much more productive everyone is.
The Second Valve
The other pile is deciding what to build, and nobody bought a tool for that one.
When building took a quarter, the decision got a quarter’s worth of thought. There was time for the argument. There was time for somebody to talk to customers. There was time for a wrong idea to die quietly.
When building takes a week, the decision becomes the constraint. The product manager did not get a faster motor. The committee still meets on Thursdays.
So a team that can build in a week sits for three weeks, waiting to be told what.
What the Fast Shops Did
A few teams have gone faster end to end. None of them did it by generating more code.
They cut approval steps. One team removed a change board that hadn’t rejected anything in two years. That isn’t an AI project, and it moved their delivery time more than every tool they bought.
They shrank the unit of work. Smaller pull requests, merged constantly. A review queue responds to batch size far better than it responds to effort.
They spent the gains on quality instead of quantity. Same shipping, fewer incidents, tests that exist. The velocity chart looks flat, and the on call rotation stopped being miserable.
And they aimed the tool at the constraint instead of at the keyboard. If review is your bottleneck, the best use of AI on your team is helping reviewers. Almost nobody sets it up that way, because the writing demo is the one that sells.
Output Is Not Throughput
Some of these gains aren’t gains, and it’s worth saying plainly.
Code that gets written and never merged is not output. Code merged now and rewritten in eight months, because nobody understood it, is negative output on a delay.
A team producing three times the code with the same review capacity is not three times as productive. It’s as productive as it was, with a growing stack nobody has looked at properly. That stack presents its bill about eighteen months later.
Bench Test: Time Your Own Line
You can measure this yourself in an afternoon. Do it on paper. A sheet with ten rows and two dates beats any tool you could buy for this.
Take your last ten features. Mark the date somebody first asked for each one, and the date it reached production. Then mark every stretch where it sat waiting for a person instead of being worked on.
Add the waits. That’s your line. The coding is one slice, and the slice is smaller than anybody on your team expects.
Then point everything at the longest wait. If it’s review, invest in reviewers and shrink your batches. If it’s decisions, fix the meeting and leave the IDE alone. If it’s the release process, nothing you do to code generation will ever touch it.
And decide which gain you want. Shipping the same amount with far fewer defects is a legitimate answer. It makes the chart look flat and the work sustainable, and no dashboard is counting it.
Sometimes the line is slow and nobody can say which station is holding it. That’s what I get called in to measure. You can see how I work with teams on my consulting page.
I wrote the longer version of the review pile in Verification Is the New Bottleneck. It is one of thirty essays in my book AI: Nobody’s in There. But we’re still in here. All of them are free to read online, and the paperback is on Amazon.
Productivity is not how fast the machine runs, it is how fast the line moves.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
Discover more from SQL Authority with Pinal Dave
Subscribe to get the latest posts sent to your email.
