Agents broke CI. Here is the part you can fix today.

On October 13, 2026, Anthropic published Redesigning source control at Anthropic. The numbers first: "In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day." To keep up, a team of seven built an in-house version control system called Scion and moved the monorepo off git in five months.

One sentence in that post applies to everybody else: "The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI."

What Anthropic changed

Two details go further than a new storage layer. The Scion team still reviews every change request, "but they now examine the intent of the change as opposed to reading every line of code," and Anthropic says it makes extensive use of adversarial review. The merge queue changed too. The team says it has not been able to replicate "the industry standard of a global repository lock on the merge queue," so it invested in "post-merge and pre-deploy automated testing." Then the post asks the question most CI setups have no answer for: "What does CI even mean when hundreds or even thousands of changes can merge while tests are running?"

Anthropic is plain that this is not for you. "Scion is by no means a suitable replacement for git for general use." The post says the design only makes sense for enormous monorepos, that Scion would be difficult to offer in a form other organizations could use, and that what Anthropic is sharing is its thinking. There is no public version to adopt.

The same wall, at our size

We are a small company and we hit it anyway. A GitHub Actions budget of roughly $100 to $120 used to cover four or five developers. It now runs $500 to $600 per developer. When CI backs up, runs have to be restarted, and that can cost two to three hours.

We moved much of our CI to self-hosted runners. The round trip stayed. The agent pushes, waits on GitHub, reads the result, fixes, and pushes again. That ping-pong takes forever and burns API usage.

GitHub is under the same load. The Pragmatic Engineer reported on May 7, 2026 that GitHub CTO Vlad Fedorov blamed months of poor reliability on agent load far bigger than expected, and quoted him: "We started executing our plan to increase GitHub's capacity by 10X in October 2025 with a goal of substantially improving reliability and failover. By February 2026, it was clear that we needed to design for a future that requires 30X today's scale."

The part you can fix today

You will not rebuild source control, and you should not try. What you control is where a required check runs and what makes its result believable.

With Pushgate, required checks run where the agent already works: your laptop, your runner, or your cluster. CI/lock signs the result and binds it to the exact commit. On push, Pushgate verifies that evidence against the repository's policy. A push without it is refused, and the refusal comes back as the next step. The agent runs the check and pushes the same commit again. Pushgate then delivers it upstream.

This is the sample transcript from our home page. It is an illustration, not captured output:

$ git push pushgate HEAD
↳ push needs attention
Required: passing test evidence
Commit: a81f9c2

$ cilock run --step push-tests -- npm test
✓ 42 tests passed · evidence signed
$ git push pushgate HEAD
↳ policy passed · push accepted

Reviewing intent is where human review is going, and it has a precondition. If nobody reads every line, something else has to show that the required checks ran against this exact commit and passed. That is the job of signed, commit-bound evidence checked before the push is accepted.

What changes is that verification stops waiting on a shared CI queue. Hosted CI keeps the jobs it is good at: privileged release operations, protected deployment credentials, and cross-platform matrices.