The AI Coding Flood: Anthropic Merges 30,000 Times a Day, and Engineers' Core Job Is Saying 'No'

When Code Merges Every Three Seconds

Anthropic's engineering blog dropped a striking claim: writing code is no longer the bottleneck. Data shows that its codebase's daily merge count climbed from 2,500 in May to a peak of 30,401 in September—averaging one change landing in the main branch every three seconds. The main branch history ballooned to 100 GB, and 25 million daily checkouts generate roughly 600 PB of traffic.

This isn't the development pace of a normal human team. When Linus Torvalds built Git, the default user was a creature typing with ten fingers who goes outside to get some sun; Claude doesn't go outside, and it doesn't stop. Anthropic itself admits in the post that the latent demand for code merges is "nearly infinite," and eliminating one bottleneck only produces more code.

Scion and Antique: Rewriting Version Control for "Non-Human Users"

To withstand this load, seven Anthropic engineers spent five months building a new version control system called Scion and a code review tool called Antique—a process that itself produced 12,257 changes.

Scion puts metadata into Google Cloud Spanner, fronted by three layers of caching, cutting mirror computation by 200x and bringing state queries down to 19 milliseconds; creating a new work tree dropped from 7.1 minutes to 5.1 seconds, saving roughly 195,000 machine hours per day. Interestingly, when the team's hand-written prototype started to lag, it was Claude that rewrote it—reducing memory usage by 20x and boosting speed by 4x.

The system also reveals whom it serves: Scion's primary developer is Claude, and it is "necessarily online," with offline mode reserved for mammals on airplanes. Simon Willison remarked that this looks more like a reinvention of centralized version control (à la Subversion) than a natural evolution of Git.

Google Cloud Spanner is Google's globally distributed relational database, known for external consistency and horizontal scalability, often used in scenarios requiring strongly consistent cross-region transactions. Scion placing version control metadata on Spanner means it abandons Git's distributed model and relies instead on a centralized, highly available database to support multiple merges per second and millions of checkouts. This also explains why Simon Willison sees it as more of a reinvention of Subversion: Git's core idea is that every clone is a complete repository, whereas Scion clearly puts the authoritative state in the cloud. The three layers of caching and 19-millisecond state queries serve to mask Spanner's network round-trip latency, so that high-frequency operations don't need to reach the remote when they hit the local cache. This architecture makes sense for an "necessarily online" agent, but it's not very friendly to offline human users.

Engineers' New Duty: Saying No to Claude

The most counterintuitive part of the post is buried two-thirds of the way in: every engineer on the team believes Claude's coding ability exceeds their own, yet they've found that an engineer's job is often to tell Claude "no." The reason is that the agent will violate core system constraints to conform to some pattern—a pattern that should never have been allowed in the first place.

With no merge queue, no one reading code line by line, and 30,000 diffs landing every day, what exactly is in there? The comments section offered a widely circulated thought experiment: Agent A introduces some abstraction, Agent B discovers and refactors it, Agent C discovers and refactors it again, and Agent D finally determines it isn't needed at all. Another reader put it more bluntly: of 3,000 commits a day, 27,000 are "undoing meaningless decisions Claude made."

Others pointed out that this is essentially using version control to patch a hole in CI/CD. Anthropic's Nick G responded that the blog post was written by humans, and the point isn't to encourage everyone to vibe code their own version control system—a statement that itself reads like a self-reminder.

Harvard Study: 30% More Code, Zero Growth in Software Delivery

If Anthropic is an extreme sample, the Harvard study turns the lens on ordinary companies. Fiona Chen and James Stratton tracked 718 enterprises and 300 million events, and the conclusion is almost brutally sobering: coding agents increased lines of code by 30%, commits by 20%, and PRs by 23%, but JIRA issue resolution rates showed no statistically significant improvement.

The reason isn't mysterious. Engineers spend less than 42% of their working time actually writing code; after introducing agents, review wait times rose 49%, and PRs requiring rework doubled. 80% of enterprises adopted AI review tools, yet three-quarters of comments are still written by humans.

One reader's summary was quoted repeatedly: it feels like we're producing legacy code at a record pace. An agent entering a codebase is a fire hose; an always-on agent is a fire hose hooked up to your wallet.

JIRA issue resolution rate is used here as a proxy for delivery throughput. JIRA is Atlassian's issue tracking tool, typically used by enterprises to record bugs, tasks, and requirements. Issue resolution rate refers to the proportion of issues marked as complete out of all issues. The key point of the Harvard study is that lines of code, commit counts, and PR counts are all "input-side" metrics, whereas JIRA resolution rate is an "output-side" metric. Inputs surged while outputs stayed flat, indicating the bottleneck isn't in coding but in review, integration, testing, and decision-making. The 49% increase in review wait times is direct evidence of the bottleneck shifting: agents rapidly produce diffs, but human reviewers can't keep up, and the queue grows longer. This also explains why 80% of enterprises installed AI review tools yet three-quarters of comments are still written by humans—tools can do initial screening, but final judgment still requires people to bear it.

Wallet and Trust: The Cost of Unattended Agents

OpenAI's Dot provided a concrete bill. Security firm Geordi tested it with zero prompts: one Dot generated 155 traces in a day, burned 307,000 tokens, and triggered 50 traces within two minutes—without a human typing a single character. By Geordi's estimate, 200,000 tokens a day costs roughly $5 to $10—about the price of a latte, provided you don't link your real bank card.

The Codex CLI issue is closer to engineering ethics. GitHub issue 48,195 documented behavior since version 0.157: on startup it launches a persistent daemon and reparents it to PID 1, copies 374 MB of binaries into a hidden directory, and spawns a detached hourly update loop; the stop command only stops the service, while the updater stays alive. Some developers discovered 1.3 GB of background updates, while others cleared out 12 GB of old versions. OpenAI's Charlie Marsh called it "an oversight," and some in the community have already used chattr to make the lock file unwritable, causing the daemon to crash on its own.

PID 1 is the number of the init process in Unix systems, responsible for starting all other processes and reaping them when child processes exit. Reparenting a daemon to PID 1 means it detaches from its original parent process and session; a normal kill or stop command can only terminate the directly launched service, while this updater "adopted" by init continues to survive. chattr is Linux's chattr +i command, used to add the immutable attribute to a file, making it unmodifiable or undeletable even by root unless the attribute is first removed. The community uses chattr to lock the updater's lock file, causing the daemon to fail and crash on its own when it tries to write—a kind of "fight poison with poison" defense. Trace here refers to the call records generated during agent execution; each trace includes model calls, tool usage, and token consumption. 155 traces and 307,000 tokens indicate that the agent was still continuously planning, calling tools, and retrying without any human interaction.

Maintainers Close the Door

The open-source side reacted more decisively. QGIS once had a 140-line AI policy allowing AI code after human review; on October 7, lead Niall Dawson merged PR 387, cutting those 140 lines down to three sentences: any LLM-, AI-, or agent-assisted code contributions are prohibited, with violators rolled back and penalized.

His reasoning was that the old policy was too costly—it lost at least one extremely valuable contributor and was ignored by "AI quick-gunners farming contributions." The contributor who triggered the ban publicly apologized, admitting that LLMs give people the illusion that "this is feasible" and that it undermined the trust contract between reviewers and contributors. Maintainers of Plotly and Hatchet said review had become "relaying messages back and forth through other people and Claude," and it would be better to interface directly with the model.

NetBSD simply classified language model output as "tainted code," and the community donated $120,282 for this—more than double the original goal.

Tainted code borrows the concept of "taint" from open-source licensing: once a codebase contains content of unknown or unclear provenance, the entire project's legal status may be "tainted," making it very difficult to clean up or relicense later. NetBSD places language model output in this category because model training data may contain strongly copyleft code such as GPL, and the model cannot explain the specific source of any given output, so maintainers cannot verify license compatibility. QGIS's ban is more about the trust contract: open-source review relies on mutual accountability between contributors and reviewers, and when contributors themselves can't explain why the code exists, review degenerates into "relaying messages back and forth through other people and Claude," so maintainers would rather close the door than bear that cognitive burden.

Speed Is Not a Success Metric

Putting these threads together, the picture isn't complicated: Anthropic used seven people and a custom-built system to support an industrial-grade merge pipeline, but one of that system's core operations is human veto; Harvard's 718 enterprises wrote more code but didn't deliver more; coding assistants on laptops self-update and self-consume in the background without users knowing.

Jan Schaumann closed with a quote from Ken Thompson: one of my most productive days was throwing away a thousand lines of code. Measuring success by code volume was the wrong metric from the start. What's truly scarce has never been the speed of typing, but the ability to judge which line shouldn't be written and which PR should be rejected.

One-line Summary

Coding agents have caused code volume to explode, but delivery hasn't increased—the bottleneck has shifted to review and judgment.

Paragraph Summary

The article weaves together Anthropic's extreme case, Harvard's enterprise study, OpenAI's agent bills, and open-source community bans to sketch the paradox of the coding agent era: writing code is no longer the bottleneck, merge rates can hit once every three seconds, but software delivery hasn't gotten faster. Seven Anthropic engineers built Scion and Antique to support an industrial-grade pipeline, yet the core operation is human veto of Claude's changes; Harvard tracked 718 enterprises and found lines of code up 30%, JIRA resolution rates with no significant improvement, and review wait times up 49%; OpenAI's Dot burned 300,000 tokens in a day with zero prompts, and Codex CLI left behind a persistent daemon; QGIS and NetBSD simply shut the door on AI contributions. The conclusion is that code volume was never a success metric—what's scarce is the ability to judge which line shouldn't be written.