GitLab Builds Next-Gen Source Control for Coding Agents on the Git Protocol

Responding to agent-driven load on Git

GitLab framed its work as a response to a recent engineering blog post from Anthropic. According to that post, as described by GitLab, agentic coding pushed Anthropic's source control beyond what Git was designed for: merges to its monorepo grew from around 2,500 a day in May to more than 30,000 a day by September.

Anthropic built an in-house system called Scion around the assumption that nearly all clients are agents that are always online. GitLab notes that Anthropic is clear that Scion is not meant to replace Git and was not designed with Git compatibility in mind. It targets scaling problems that could become common over the next six to 12 months.

The Anthropic article suggests that Git platforms can add richer server-side operations while staying compatible with Git. GitLab says that is the problem space of its own next-gen SCM work. It quotes Nick G. of Source Control at Anthropic: "We see room to expand what Git servers can do for these workloads without departing from the overall Git model."

How the architecture works

GitLab says its next-gen SCM uses the Git protocol that developers and their tools already rely on. The backend can scale across many compute nodes, and its interfaces let agents request the files and history needed for each task, which the company says can reduce repeated full repository clones.

The design separates compute from repository storage. Object storage holds repository data, while stateless compute nodes serve requests from local caches. Capacity grows by adding nodes, and the components communicate through the standard S3 API. According to GitLab, the system can run on GitLab.com and in self-managed environments, including air-gapped setups where repository data never leaves the customer's infrastructure.

The aim is to reduce bottlenecks from heavy read and write activity. In early internal tests, GitLab reports, workloads completed up to 50x faster, used half the tokens, and generated up to 1,000x less network traffic. These are the company's own results from internal testing.

Roadmap: context, traceability and policy

GitLab says the backend is only one part of preparing source control for coding agents. Teams also need to know which instructions shaped a change, which commits and merge requests were affected, and which policies applied. The roadmap includes:

• Capturing the instructions and decisions behind an agent session as the work happens.
• Keeping each session linked to the commits and merge requests it produces, including after a squash or rebase.
• Showing reviewers changes alongside relevant context, so they can focus on work that needs human judgment.
• Applying branch policies to agent identities, so teams can control which agents can change specific code.

GitLab places this work within its vision of a governed software factory, which it described at its Transcend customer event as a connected system that helps teams move software from idea to production under their own policies and standards. The company stresses these capabilities are planned, not yet delivered, and its post carries forward-looking statement disclaimers.

Upstream Git work and what comes next

GitLab says much of its Git work happens upstream, and that it has been the largest corporate contributor to Git in recent releases. It delivered a pluggable interface for Git's object storage in Git 2.54 and has been moving more of Git's object database subsystems behind it. In Git 2.56, consistency checks, housekeeping and packfile generation moved behind the interface, and the work continues.

The company says its next-gen SCM will run as its own fast, scalable implementation of that interface, with agent-facing interfaces on top. It also intends to extend the same abstraction to upstream Git to improve how Git handles large binary files.

For teams whose repositories already strain their Git backend, GitLab invites them to request early access and test the system against those repositories. The company's pitch is that agent workloads can be scaled without leaving the Git model or depending on a fork.