Thirty Thousand a Day: When AI Outruns the Systems Around It

Anthropic went from merging around 2,500 code changes a day in May to more than 30,000 by September, and the thing that buckled was Git, the version-control system nearly every software team relies on. Days earlier, PostgreSQL pulled up to ten features from its next release after AI reviewers surfaced problems faster than people could fix them. Both stories point at the same place: the limit on AI in your business now sits in everything its output has to pass through afterwards.

Picture your accounts team on an ordinary Monday. They approve around a hundred supplier invoices a day, and the process works because it was built for a hundred. There is a shared inbox, a spreadsheet that tracks what has been paid, and one finance manager who signs off anything over £5,000.

Now picture the same team a quarter after an AI agent goes live on the inbound side. The agent reads, matches and codes invoices beautifully. Twelve hundred a day are now landing in the queue, every one of them ready for approval. Nobody has been hired, the spreadsheet hasn't changed, and the finance manager still has the same eight hours in the day.

The agent did exactly what it was asked to do. The process still ground to a halt, and none of the post-mortem meetings will be about the model.

That scenario is invented. The pattern underneath it is very real, and this week two of the most closely watched engineering teams in the world published accounts of running straight into it.

What actually broke at Anthropic?

On 13 October, Anthropic's engineering team published a post explaining why it had stopped using Git for its main codebase.

In case you're new here, allow us to explain. Git is version control: the system that keeps track of every change made to a piece of software, who made it and when, so that teams can work on the same code without overwriting each other. Practically every software company on the planet uses it, and it has done the job well for about two decades.

By Anthropic's own figures, the company averaged around 2,500 code changes merged per day in May 2026. By September it was merging more than 30,000 a day, and the post attributes the surge largely to Claude writing the code. The history of its main branch alone runs to almost 100 GB. Its automated testing systems check out the code roughly 25 million times a day, which the team estimates would mean over 600 petabytes of Git traffic daily if fetched naively. At its peak, the company was running several hundred internal Git mirrors just to keep up.

So a team of seven built a replacement, called Scion, and migrated the whole codebase onto it in five months, alongside a new code review tool and a handful of related systems. Anthropic says the new setup needs 200 times less computing power and memory than the mirrors it replaced, and that checkouts for testing and research jobs now take seconds where they used to take minutes.

All of those numbers are self-reported, and Anthropic is a very unusual company to be measuring this at, which it acknowledges itself. The useful part for everyone else is the diagnosis. The post opens by saying that writing code has stopped being the constraint, and that the bottleneck has moved to the infrastructure built for human-paced work: source control, builds and testing. The model got faster, and everything downstream stayed the size it was.

The checking problem: PostgreSQL's long tail

If Anthropic's story is about volume, the second story this week is about scrutiny.

PostgreSQL is one of the most widely used databases in the world, the kind of open source software quietly running underneath thousands of businesses. Its next major version, PostgreSQL 19, was expected in late September or early October. According to The Register, it is now pencilled in for around 19 November, and somewhere between eight and ten significant features have been pulled from it and pushed back to next year's release.

Peter Eisentraut, a long-standing PostgreSQL committer and vice president at EDB, set out what happened in a blog post on 9 October. Some of the reverted features had serious design flaws. Alongside those sat a long tail of minor edge-case bugs that, in previous years, would have surfaced gradually over half a decade of real-world use. LLM-assisted code review found them all at once, during the beta. Each might need only a small fix, but as Eisentraut put it, "there is a fixed overhead to dealing with each of these," and the team simply ran out of time.

He is careful to say AI review isn't the whole explanation. Senior developers had spent months tied up on security fixes, which squeezed the usual review period, and he openly allows that some of the code may not have been good enough. He also says that, as far as he can tell, vibe coding (where AI writes code with little human understanding behind it) was largely not a factor, because most of the reverted work was written before the practice existed.

Look at the shape of the problem, though. The AI reviewer did its job extremely well. It raised the quality bar after the code had already been written, and the limiting factor became the hours human maintainers had to work through everything it found. Detection scaled overnight. Fixing didn't.

GitHub saw this coming in April

None of this should surprise anyone who read GitHub's update on its own reliability earlier in the year.

In a post on 28 April, GitHub's chief technology officer Vlad Fedorov explained that the platform had started a plan in October 2025 to increase its capacity tenfold. By February 2026 it had become clear it needed to design for thirty times its then-current scale. The driver, he wrote, was the sharp acceleration of agentic development workflows since late December 2025, with pull requests, commits, API usage and automation all climbing quickly.

His explanation of why that hurts is worth reading twice. A single pull request touches storage, permission checks, automated testing, search, notifications and databases, and at high scale "small inefficiencies compound." Queues deepen and retries pile on extra traffic, until one slow dependency starts dragging down several others.

The same post described an incident on 23 April in which GitHub's merge queue (the tool that lines up approved changes and folds them into the main codebase in order) produced incorrect results under certain conditions. Across 658 repositories, 2,092 pull requests were affected, with earlier changes quietly undone by later ones. No data was lost, but GitHub said it could not safely repair every affected repository automatically.

That is what volume does to a process designed for less of it. Nothing dramatic explodes. Things start going subtly wrong in the plumbing, and you find out later.

Why this matters well beyond software

It would be easy to file all of this under developer problems and move on. Code just happens to be the first place AI output arrived at serious volume, and every other part of the business is next in line.

Every operational process carries a throughput assumption, usually unwritten. A purchase approval chain assumes a certain number of requests a week. A compliance sign-off assumes a reviewer can read what lands on their desk. A customer service escalation path assumes most queries get resolved before they escalate. A quality inspection rota assumes the line produces at a known rate. Those assumptions were set by the speed of people, and almost nobody revisits them when a tool arrives that works at the speed of software.

When AI starts generating drafts, quotes, listings, orders, contract summaries or support replies at machine pace, the first thing to break is usually the queue sitting behind it.

Anthropic expects this class of problem to become commonplace across software within six to twelve months. I'd argue the clock outside software is already running, just less visibly, because an overloaded approval inbox doesn't publish an engineering blog post about itself.

What the humans did instead

The most useful part of Anthropic's write-up has very little to do with version control. It's the section on what its engineers now spend their days doing.

According to the post, every engineer on the project would now rate Claude as better than them at writing code. Their value moved to understanding how the systems fit together and which trade-offs actually mattered. The post says that, very often, the engineers' role was "to tell Claude 'no'," because agents would sometimes break core system rules to satisfy a pattern that should never have been allowed in the first place.

They also changed what review means. People still look at every change to that system, but they now examine its intent rather than reading every line. The approval tooling can tell a comment-only edit apart from a sensitive change to the logic, so human attention lands on the changes that carry real consequences. On top of that, the team runs dedicated AI monitors, which it calls superfans, each one obsessively watching the health of a single component.

Strip away the engineering and what's left is a governance design. Human judgement is concentrated where it matters most, automated checks absorb the routine volume, and the rules about which is which are written down in advance instead of being improvised under pressure. It's the same principle we put at the centre of every agentic governance conversation: human approval where it counts, and a clear, auditable record of everything else.

What this means in your industry

Manufacturing

AI quality inspection can flag defects far faster than a line supervisor can investigate them. If every flagged part lands in the same rework queue, you will build a backlog that looks like a quality crisis even when the line is perfectly healthy. Decide in advance which defect classes the system can quarantine automatically, which need a human eye, and what happens once the human queue passes a set length.

Logistics

Route and load optimisation can generate replanning suggestions all day long, and dispatchers can only act on so many before the plan they're executing goes stale. Cap how often the system can propose changes to a live route, and send only the exceptions with genuine cost or safety impact to a person.

Retail

AI can produce product listings, price adjustments and promotional copy by the thousand. The bottleneck is usually brand, legal or merchandising sign-off, which was sized for a few dozen changes a week. Tier the approvals: low-risk edits such as typo fixes and image swaps can go through with logging, while pricing and product claims always stop for a named reviewer.

Real Estate

Document review tools can summarise leases and surface clauses at a pace no conveyancing team can match, which becomes the problem the moment every surfaced clause turns into a task. Agree with your team which findings are informational and which require action, or the AI will turn a forty-page lease into a forty-item to-do list.

The case for not panicking

Some counterweights, because the headline numbers deserve a harder look than they've been getting.

Anthropic's situation is extreme by design. The company openly says its ability to spend on AI for internal use far exceeds what any other business would realistically want to, and that Scion is by no means a suitable replacement for Git for general use. Rather than offer it to other organisations, it is sharing the thinking behind it. Most businesses are nowhere near thirty thousand of anything a day, and won't be for a while.

The PostgreSQL delay has several causes, and Eisentraut expects the situation to sort itself out in future development cycles, once AI review is part of how features are built from day one. Arguably it's a good-news story: a widely used database will ship a few weeks late and considerably more robust.

And the Anthropic figures, once more, come from Anthropic. They are detailed and credible, but nobody outside the company has audited them.

None of that changes the direction of travel. Read these stories as an early view of where the pressure lands next, rather than a picture of your business today.

What to do on Monday

The preparation that matters here is mostly unglamorous, which is good news, because none of it depends on which model you use.

• Map the queue behind every AI workflow. For each process where AI produces output, write down what happens next, who touches it, and how many items that person can realistically handle in a day. If nobody can answer the last part, that's your first job.
• Tier your approvals before the volume arrives. Sort outputs by consequence and decide which can pass automatically with a log, which need a quick human check, and which always need a named decision-maker. Anthropic's split between comment-only changes and logic changes is a good template to borrow.
• Set a ceiling and a fallback. Every human queue needs a maximum length and an agreed response when it's breached, whether that means slowing the AI down, batching items or escalating. A queue without a ceiling becomes a backlog without an owner.
• Measure throughput end to end. Track the time from AI output to finished outcome alongside how quickly the AI produced the work. The first number is the one your customers actually feel.

Then put one question to any vendor selling you an agent: when your system produces ten times more work than it does today, which part of my operation absorbs it, and how will I know before it overflows?

Where this leaves you

For two years, the business conversation about AI has been about capability: which model writes better, reasons further or scores higher. That conversation isn't over, but this week showed where it's heading next.

Anthropic has some of the most capable AI in the world on its own desks, and it still had to rebuild its plumbing in five months to stop that AI drowning its own systems. PostgreSQL gained an exceptionally sharp reviewer and discovered that the scarce resource was the people who had to act on its findings.

The organisations that get the most out of AI from here will be the ones whose approvals, queues and handoffs were designed to absorb what the model produces, with human judgement placed exactly where it counts. That design work is slow and unglamorous, and it sits entirely within your control, which makes it the best place to start.

At U4RIA, we believe AI is a tool to help humans, not replace them. Like what we're about? See what your business is truly capable of. Experience U4RIA.