Anthropic published a piece recently on how they are redesigning source control at their company. It starts with this:
“At Anthropic, coding is no longer the bottleneck to building systems or doing research. Claude is able to autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at a speed and scale we haven’t seen before. The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI.
In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day. We don’t expect this rate of growth to slow down anytime soon; the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce.”
The work they’ve done seems impressive. I highly recommend you read the piece. I have reread it a few times, and I jotted down a few thoughts:
- It is impressive that they are able to remove these bottlenecks, but as they say, this approach isn’t for everyone, and it’s not likely to solve the problems that I mentioned here. The stress for others in DevOps roles — testing, operations and application support — isn’t going to go away as the CI part is streamlined.
- While the focus is on CI improvements, Anthropic does touch on how they are are working on improving testing and operations, but the details are limited in this piece. They admit: “What does CI even mean when hundreds or even thousands of changes can merge while tests are running? We haven’t been able to effectively replicate the industry standard of a global repository lock on the merge queue, so instead, we’ve invested in post-merge and pre-deploy automated testing. ” Likewise, it sounds like they are dumping lots of telemetry into Slack and having agents monitor that. I’d like to know more about that part of their DevOps lifecycle and how effective it is and anything we could learn and apply.
- Anthropic is clearly an organization that has the need to make massive amounts of changes to their code base. They have plenty of requirements and constraints to meet, and they need to meet them yesterday. Likewise they have an enormous user community wanting those changes. All that adds up for the need to pump out software at the rate they do. It’s very unlikely your organization has any of that. Even if you can pump out more code faster with AI, and even if you could speed up your DevOps processes to integrate and deploy and test and operate as efficiently as Anthropic, chances are your user community will not be able to keep up with the changes. That’s why “Plan” is an important part of the lifecycle. Otherwise the user community becomes the ultimate bottleneck.
- The planning part is also important to make sure your deployed code does not impact the non-functional/quality aspects of the system it runs on. It’s great that you can use agents to monitor if the system is at capacity due to these exciting new changes, but do you have a plan to increase capacity before you hit your limit? Do you have a plan to fix or roll back changes if serious new security problems occur? If downstream systems suddenly start crashing due to increased use on your side, what is the plan to improve the overall availability of your entire system? Getting more and more code deployed faster is only good if there isn’t a degradation of the system it runs on. You need to do more than ramp up your software development: you need to ramp up your ability to maintain the health of the systems that software lands on (and hopefully it lands gently vs crash landing).
I may revisit this piece when I hear more about what Anthropic and other organizations are doing to deal with the impact that AI software development has on the DevOps lifecycle. These are my thoughts for now.
(The opinions expressed above are mine only and not necessarily those of my employer.)

First up, what is a blog? According to Wikipedia, “A blog (a truncation of “weblog”) is a website whose basic unit is a “post” or “entry”, with posts typically presented in reverse chronological order.” So, a website made up of posts.



Many people are succumbing to hysteria(1) when it comes to A.I. I understand why people feel this way. But I think it is important for people to know that some of this hysteria is being whipped up by many of those in the A.I. industry. To see what I mean, I recommend you read this piece by Dave Karpf: 

























