> as of September, we merged over 30,000 per day.
There's going to be an ugly phase where everybody FOMOs into thinking they need to do the same, only to realize that they're not Anthropic/Google/etc.
There's going to be an ugly phase where everybody FOMOs into thinking they need to do the same, only to realize that they're not Anthropic/Google/etc.
This amount of churn feels like a thing only possible with no real profit motives and a lot of money to waste.
Lots of activity is not necessarily synonymous with productivity, and it carries real cost.
So I think the design here is interesting, and the concepts seem applicable to where some agentic development may end up, but I question the underlying principles that drive this being the right solution space at all. At least if the goal is a profitable company.
Yet IMO the admin controls Claude provides just started to be adequate for a small company a few weeks ago (and even so are still ridiculously fragmented and seem fragily designed and not exhaustively documented), so I can't even imagine for a big company.
Do you need that rate of change to make basic controls? I'm not sure. Do we see such dramatic fast evolution in the products? Not really. Are bugs we report actually fixed? I tried once and it just auto closed.
Anthropic should optimise for something more interesting than number of merges per second.
Because tokens have a cost. CI jobs have a cost. Organization objectives and goals have a cost. Features have a cost. Code has a cost.
---
So in a world where agents do all the work... why are they not able to control operating costs AT ALL?
Why is the right operating method the one that happens to blow an absolute shit load of cash on - wait for it - internal tooling that the customers don't give a fuck about?
Customers do not care how the internal business operates. They care about value delivered. I'm absolutely not convinced that this "churn churn churn" method of operating is actually delivering enough extra value for the cost it incurs.
---
Now - that said, I think there are some fair points here that are worth considering, mainly around whether a distributed version control system (git) is really the right call for agents that need to coordinate much more closely than most human developers did.
I think that's a directionally appropriate insight, and worth considering.
What I don't find compelling at all is the idea that many (any, really) companies should expect to be running millions of ci jobs a day, and mergings hundreds of thousands of prs/commits. That reeks of "I have cash to blow and don't care".
In the early/mid 2010s there was a similar hysteria about "deployments per day/week" metric. People were comparing products or teams by saying "My team deploys twice a week", "oh, yeah? we deploy 3 times a day". People viewed the north star of the CD part in CI/CD as pushing to production. The concept was simple, you push your code to main. CIs start churning, deploying it to test environments, then promoting it to staging, the pre-prod, then into blue/green prod deployment, then into prod. All automated, all touchless, happening on every merge, 5-10 times a day. That's engineering efficiency.
Many tried to follow that. It works great if your project is a Jekyll blog of course.
They are doing something wrong.