Over the past few weeks this blog got a new theme, a new home on Kubernetes, and a brand new editorial calendar plugin.
Most of that code was written by AI agents while I was busy doing something else.
The plugin was the most intriguing part. The agents built it out fast. But then it sat there, finished, while I sorted out how to deploy it, read through what had been written, and debated whether I trusted it enough to run on a site I’ve kept alive for nineteen years.
The build took almost no (attended) time. Everything after the build took more time than I anticipated.
That’s a tiny, one-person version of a problem I keep hearing from engineering leaders. Their teams are shipping more code than ever. The business doesn’t feel any faster.
Build spikes
Call it a build spike: a burst of generated code, pull requests, and CI runs that lands far faster than the team around it is used to absorbing. One engineer with a couple of agents can open more pull requests before lunch than their whole team used to open in a week.
It’s real output. Just a different flavor.
What the business cares about is velocity: the time between a customer having a problem and that customer using the thing that solves it. Lines of code, GitHub contributions, PRs deployed – these are vanity metrics that don’t appear anywhere in that definition.
A spike always moves the vanity metrics. It only sometimes moves the actual measurement.
Where the speed is real
Credit where it’s due: a prototype that used to take a sprint now takes an afternoon. You can put a working thing in front of a customer instead of a slide deck, and find out you were wrong while before a misdirection is costly. Experiments that never would have survived a prioritization meeting just get built.
I’ve benefited from all of this. I’ve also argued that companies should pay for it.
Shorter feedback loops are worth real money. If that’s where your spike lands, enjoy it.
Where it piles up
The trouble starts when the spike hits everything that didn’t speed up.
Faros AI looked at telemetry from more than 10,000 developers. On teams with heavy AI adoption, engineers merged 98% more pull requests. Review time on those pull requests went up 91%, and the pull requests themselves got a lot bigger.
Editor’s note
Faros sells engineering analytics. Take the numbers with appropriate skepticism.
But they aren’t alone. Google’s 2025 DORA report surveyed nearly 5,000 people and found AI adoption now goes hand in hand with higher delivery throughput. It also goes hand in hand with higher instability.
Teams ship more and break more.
Then there’s the METR trial. Sixteen experienced open-source maintainers, working in their own repositories, took 19% longer on tasks when they used AI tools. Afterward they estimated the tools had made them about 20% faster.
That last finding bothers me. It should bother you, too. A team that feels more productive when they are actually less so is a red flag.
On the ground it looks like this. The review queue doubles and the same three senior engineers are still the ones working through it. Pipelines that were flaky once a day are now flaky once an hour, because they run ten times as often. The CI bill shows up in a budget meeting. The test suite was written for a codebase that grew at human speed, and it can’t keep pace.
The constraint moved
Eliyahu Goldratt wrote a whole novel about this in 1984.1The Goal is required reading in most business programs. If you haven’t read it yet stop now and find a copy. They’re everywhere. Understanding the Theory of Constraints will change how you view any kind of pipeline, software adjacent or otherwise. Every system has a constraint. Speed up any step that isn’t the constraint and all you get is a bigger pile of inventory in front of the step that is.
Typing code was rarely the constraint. AI tools have just made it nearly free anyway.
The work now waits in the same places it always did, only longer: code review, QA, security checks, product decisions, release approvals. None of those got an agent. Most of them are people, and nobody hired more of them when the code started arriving faster.
I spent years as the security sign-off at the end of that pipeline. Security teams do not scale with pull request volume. Every generated line is surface area somebody has to answer for when it breaks or gets broken into. More code, more surface, same number of reviewers.
Take a guess at how that math works out.
Product decisions are the quiet one. No model generates the decision about what’s worth building. A team that can build anything in a week still needs someone to say which things are worth building.
Measure what matters
If your dashboard celebrates pull requests merged, it’s going to look fantastic this year. It’ll tell you nothing.
Look at these instead:
- Lead time from commit to production
- Change failure rate, meaning how often a deploy needs a fix or a rollback
- Cycle time to customer value, from the request coming in to the customer using the answer
If pull request volume doubled and lead time didn’t move, all that money just bought you a queue.
What I’d do about it
Limit work in review. Decide how many open pull requests your reviewers can handle well and stop opening new ones past that number. It feels like slowing down but it’s the only way the work that’s already written ever reaches a customer.
Spend on automated testing. Tests are the one reviewer that scales with volume. If agents are writing your features, a good share of your human attention belongs on the suite that checks them.
Budget for compute. More builds cost more money. Plan now so no one is surprised in the third quarter.
Prioritize by outcome. When building is cheap, the temptation is to build everything. Pick the work by what it does for a customer, then point the agents at that.
For the leaders in the room: AI multiplies input. Whatever your organization was already good or bad at downstream of the keyboard, you now have more of. Find the constraint and fix that.
Buying more seats for the step that’s already fast won’t help.
- 1The Goal is required reading in most business programs. If you haven’t read it yet stop now and find a copy. They’re everywhere. Understanding the Theory of Constraints will change how you view any kind of pipeline, software adjacent or otherwise. ↩︎
Discussion