When agents open the pull request
GitHub says agents now start more than 40% of pull requests, and theirs get merged more often. Merged is not the same as right: measure what happens after the merge.
The 60-second version Open
- GitHub says more than 40% of pull requests in September 2026 started with a coding agent’s first draft, up from 17% in March.
- Agent pull requests were merged within two weeks 90% of the time, against about 86% for the rest.
- A merge rate measures what a reviewer accepted. It doesn’t tell you what held up in production.
- Track what happens after the merge: reverts, follow-up fixes and incidents, split by agent and human.
- Spend review time by risk. A small, well-tested change and a payments migration shouldn’t get the same review.
GitHub published its Octoverse report this week, and one number stands out. By September 2026, more than 40% of pull requests on GitHub started with a first draft from a coding agent. In March it was 17%. That is 110 million pull requests in a single month, and GitHub calls it a floor, because it only counts the agents it can detect.
The second number is the one teams will quote. Agent pull requests are merging more often than the rest: 90% were merged within two weeks in September, against about 86% for pull requests with no detected agent involvement. In February the agent figure was 83%.
Merged is a decision, not a result
It's tempting to read that as "agent code is now better than human code". It doesn't say that. A merge rate measures what a reviewer accepted. It tells you the reviewer said yes, not that the reviewer was right.
This is the same trap as grading an agent by its transcript. A pull request can be tidy, well described and green on every check, and still be the change that pages someone at 3 a.m. If the only thing you measure is acceptance, you are measuring how convincing the draft was.
Score the change by what it did in production, not by whether it got through review.
Measure after the merge
The fix is to look at what happens next. For every merged change, record whether it was reverted, whether it needed a follow-up fix within a few weeks, and whether an incident traced back to it. Split those numbers by who wrote the first draft. Now you have something you can act on: if agent changes in one part of the codebase are reverted twice as often, that part needs closer review, or different instructions for the agent.
Review is the budget
If agents write the first draft of almost half the changes, review time becomes the scarce resource. The answer isn't to review everything harder; it's to spend review where a mistake costs most. A small change with good tests in a low-risk folder can get a light review. A change that touches authentication, payments or a data migration gets a full one, whoever wrote it.
What to do this week
Label pull requests that started with an agent, if your tools don't already. Pull the last 30 days of reverts and hotfixes and split them by that label. Then write down the three folders where a bad change would cost the most, and make sure every change there, agent or human, gets a person who reads it line by line.
A new essay arrives every Sunday.
Discussion