AI software development: review is the new bottleneck

Anthropic went from 2,500 to over 30,000 merges a day in four months. Three numbers from your own repo that show whether verification fell behind.

The review queue is the first thing to jam when code writing speeds up

If AI multiplied the amount of change landing in your system, the question in your weekly meeting has to change. Stop asking how much the team shipped. Start asking how much of what landed was actually verified before it landed. Three numbers answer that, and all three come out of your own repository: how many changes reached production in the last month, how many had a human read them before the merge, and the median time between opening and approving. If the first number went up and the third went down, your review queue became a rubber stamp.

This is not a thought experiment for frontier labs. On 13 October, Simon Willison wrote up Anthropic's account of why they redesigned source control internally: in May 2026 the company averaged around 2,500 code changes merged per day, and by September it was merging over 30,000 per day. Twelve times more in four months. Git was designed for the pace of humans writing code, and it stopped keeping up with the pace of agents writing code, so they built something else. The GitHub Blog has announced work in the same direction, rebuilding Git infrastructure for agent scale. Same fact, two pieces of it.

2,500 in May, more than 30,000 in September

On a steel structure you sample welds by criticality, and code review should work the same way

Thirty thousand is the headline number. The number that matters to whoever signs the invoice was not published: how many of those 30,000 changes did a person read before they went in.

When throughput multiplies by twelve, none of your other capacities multiply with it. The review bench stays the same size. The number of staging environments stays the same. Your tolerance for an incident at 2pm on a Tuesday stays the same. So verification becomes sampling by accident. Nobody decides to review less. The queue simply moves faster than anyone can read, and what slips through slips through because CI went green.

The bill does not arrive the following month. It arrives when someone has to change that part of the system and nobody can explain why it works the way it does.

What the public conversation about version control is still arguing about

The contrast is worth looking at, because it tells you where most of the market actually sits.

While one company rewrites Git because of agent volume, the most-read questions about source control on the Software Engineering Stack Exchange are from another era. One of them, about keeping API keys out of source control, has 228 points and close to 71,000 views. Another, with 150 points and roughly 28,000 views, asks whether it is unusual for a 15-developer company not to use managed version control. Thirty-one answers on that one.

I am not laughing at anybody. I am saying the distance between the frontier and the shop floor is enormous, and reading the Anthropic story as a recipe is the expensive mistake here. If your team is still dealing with a credential committed to history, your priority is not the merge tool. It is the discipline of what gets in.

Nobody inspects 100% of the welds on a steel structure

The rule for which changes require a human read fits on one page, and almost nobody writes it down

Before software I signed off on steel structures for a motorsport circuit and worked through the mechanical assembly of cement plants. On a steel structure you do not test every weld. It would be unviable in both schedule and cost, and the code does not ask for it. What you do is classify the joints by criticality and set an inspection percentage per class. A joint carrying people overhead gets inspected to the hilt. A cladding joint that drops a panel if it cracks gets sampled.

Code review at high volume works the same way, and almost nobody writes the rule down. What I see instead is one of two failures: the team tries to review everything with the same rigour and the queue jams, or it gives up and approves everything with the rigour of nothing.

The rule that works is boring and fits on one page. Anything touching pricing, permissions, money movement, personal data or a database migration gets a senior human read, every time, no schedule exemption. Text, layout, tests, dev-only dependencies: automation decides, and a human spot-checks maybe one in five. What you buy is predictability about where failure will hurt, and that is worth more than the feeling that everything was reviewed. Senior review time is expensive. Spending it on a CSS tweak is waste. Spending none of it on the billing job is something else.

"My team merges 40 times a week, this is not my problem"

Right objection, half wrong.

Half right because 40 merges a week fit in one person's head. You can read all of it, talk about all of it, remember all of it. Half wrong because today's number is not next year's number. Anthropic took four months to multiply by twelve, and nobody in this market is planning to use fewer agents in 2027.

There is also a quiet version of this problem already sitting in your company at low volume. The symptom is not an incident. It is schedule. When writing accelerates and verification does not, the time that used to show up as development migrates into rework, and rework never gets a card on the board. You keep hearing the sprint closed, and you keep feeling that delivery takes longer than it should.

Three numbers you can pull this week

None of them need a new tool, and all three fit in one afternoon:

1. Volume and slope: merges into the main branch over the last 30 days, against the same window six months ago. The slope matters, not the absolute figure.
2. Human read coverage: of last month's merges, how many carry at least one review comment that is not an automated approval. Zero-comment approval on 90% of merges is a data point, not a compliment to the team.
3. Open-to-approve time: the median, never the mean. A median of a few minutes on changes that touch money means nobody read them, and you will find out the expensive way.

If number one went up, number two went down and number three got shorter, you have your answer without hiring anyone to tell you. Your capacity to verify fell behind your capacity to produce. You can see how we think about this kind of work on our about page.

Swapping the tool is the last decision, not the first

The lazy reading of the Anthropic story is "Git is obsolete". It is not. They switched because they hit a real ceiling, with a team able to maintain an alternative forever, at a volume that pays for it. You almost certainly have none of those three things, and writing your own source control would be the worst architecture decision of your year.

What the case actually teaches comes before the tool: when throughput changes by an order of magnitude, the process designed for the previous order stops working, and insisting on it is what gets expensive. That holds for merges, for deploys, for onboarding a new hire.

One thing I cannot tell you, and will not pretend to: where exactly the ceiling sits. I have no merges-per-day figure at which Git starts to hurt a team of ten. My suspicion is that the review problem blows up long before the tooling one does.

Month 14 belongs to whoever signed

When you hire engineering, the conversation is about speed. Output per sprint, screens per month, how much AI accelerates it. Not one commercial proposal in this market has a line about who answers for what the agent wrote, and a vendor shipping volume with no verification rule is doing exactly what the contract model asks of them. Who we are is partly a reaction to that.

Month 14 is yours to pay. So take one question into your next meeting with whoever builds your system, and ask for the number, not the opinion: of the changes that reached production last month, how many did a human read first, and which classes of change make that non-optional. If nobody can answer on the spot, fix that before you touch any tool.