Right now we’ve made coding faster and software delivery slower. Probably every dev team that started using AI at a larger scale has seen some version of this shift.
A dev happily opens a pull request with 1,500 lines of changes. Claude wrote this.
But wait, now somebody has to actually understand the whole thing!
Idea? Quite easy solution. Let's split it into 5-6 smaller pull requests.
Great. Now the problem isn't understanding a huge amount of changes within one PR, but mentally connecting several somewhat independent changes, understanding their dependencies and keeping the bigger picture in your head.
The „work in progress” moved.
We used to have a queue of tasks waiting to be implemented, because producing the code itself took much longer.
And now... now producing code is cheap.
So those tasks move through implementation quickly...
...and start piling up in review and QA instead.
We optimized one part of the system. We didn't necessarily improve the system.
And yes, we can add more AI there too.
AI code review. AI-generated tests. AI-assisted QA.
Your agent can happily generate 200 tests for the 1,500 lines it just wrote. And they all light up green. But does that actually mean the software works?
Not necessarily.
And I think this is where AI adoption in engineering teams gets much more interesting than:
“How can we make developers code faster?”
The question should be:
“How can we increase throughput?”
Once you make one part of the SDLC dramatically faster, the constraint moves somewhere else.
reqs → coding → review → QA → deployment...
And if you keep optimizing individual steps without looking at the whole system, you can end up with developers producing more code than your organization can actually understand, validate and ship.