I spent part of last week reading through GitHub’s Octoverse report, released at GitHub Universe on 28 October, and one number jumped off the page: in September, agents started about 110 million pull requests on GitHub, which is more than 40% of all the pull requests opened that month. Back in March that figure was 17%. More than double in 6 months. Quite a jump, to put it mildly 🙂

Bear in mind GitHub says this is a floor: it only counts the agents it can detect, and this year’s data includes private repositories, so comparing it with older reports needs a bit of care. Still, even with all the caveats, the direction is pretty obvious. And it’s not the only number worth a look: merged pull requests tripled in less than a year, to around 220 million a month, and 90% of agent-started pull requests were merged within two weeks, compared with 86% of the traditional ones.

Most of the commentary I’ve seen so far reads this as “agents are now as good as humans at writing code”. I’d argue that’s the least interesting conclusion you can draw from it.

The Bottleneck Moved

Here’s the thing: if the volume of pull requests triples and the number of humans looking at them doesn’t, then something has to give. Either review times go up, or review depth goes down. And a 90% merge rate within two weeks, on three times the volume, makes me suspect the latter more than the former.

Don’t get me wrong, I’m not saying the agents are writing rubbish. I use them every day, and a good chunk of the code I write nowadays starts as an agent’s first draft. But I’ve also been a CTO long enough to know what happens when a team gets a flood of pull requests: people start skimming. They look at the diff, see that the tests are green, see that it “looks reasonable”, and click approve. Nobody decides to lower the bar; it just quietly slides, one tired Friday afternoon at a time.

Can you see the problem here? The bottleneck in software delivery used to be writing the code. Now it’s reading it. And most engineering organisations are still measured, staffed and rewarded as if the bottleneck were writing it.

What I’d Do on Monday Morning

If I were running an engineering team today and saw these numbers, I wouldn’t ban agents (good luck with that anyway) and I wouldn’t throw more reviewers at the queue either. I’d change what the humans are reviewing.

First of all, I’d stop treating the diff as the main artefact. When an agent writes 400 lines in two minutes, line-by-line review by a human is the slowest and least reliable check in the whole pipeline. The things worth a human’s attention are the spec (did we ask for the right thing?) and the tests (do they actually prove it?). If those two are right, the code in between becomes far less scary.

Secondly, I’d push as much of the checking as possible into machines: type checks, contract tests, property tests, static analysis, architecture rules that fail the build. Every rule you can encode is one less thing a tired human has to spot at 5pm. This is the boring, unglamorous bit, and it’s the bit that makes the difference.

Last but not least, I’d measure the right thing. Pull requests merged per week is a vanity metric now (the agents will happily inflate it for you). Time to review, defects found after merge and how often a change gets reverted tell you far more about whether your process is holding up.

Where This Is Going

Now you can argue that this is just the transition pain of a new tool, and that it’ll sort itself out. I don’t think so. I think it’s an early glimpse of where software engineering is heading: a “lights out” setup, where engineers “code” through specs, and agents write, test and ship the code. In that world, reviewing a diff line by line makes about as much sense as proofreading the output of a compiler.

We’re not there yet, and that’s exactly why the next couple of years are dangerous. The agents already produce code faster than humans can read it, but most teams haven’t yet built the specs, the tests and the guard rails that would let them stop reading it. The teams that close that gap first will ship faster and break less. The ones that don’t will end up with a huge pile of code that technically passed review and that nobody really understands.

As such, my advice to engineering leaders is fairly simple: stop asking how much code your agents are writing, and start asking who checked it, and how. Bottom line: the agents have already taken over the typing. Make sure your team has taken over the thinking 😉