Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · October 19, 2026 · repo

gitaiScionmulti-agentagent-infrastructureagent-security

gitai Lets 50 AI Agents Land Code on One Branch. Your Tests Move to After the Merge.

An open-source take on Anthropic's agent-scale source control drops the merge queue. Here is what replaces it, and the part you have to lock down yourself.

A merge queue works like a single-lane toll booth. Each change waits its turn, the tests run, and only then does it reach the main branch. With five engineers pushing a few times a day, nobody notices the line.

Put fifty coding agents on the same branch and the line becomes the whole job.

Anthropic described this problem in plain numbers last week. Its engineering post on redesigning source control, published October 13, says the company went from about 2,500 merged changes a day in May to more than 30,000 a day in September, and that a traditional merge queue "doesn't make much sense at agent scale." Its answer, an internal system called Scion, tests changes after they land instead of making each one wait.

Five days later, an independent developer shipped an open-source version of that idea. gitai (the repository is feder-cr/git-ai) tagged version 0.2.0 on October 18 and sat at #10 on Trendshift's daily board when I checked at about 07:20 ET this morning. Its README calls it "an independent implementation of the publicly described design," and says plainly that it is "not affiliated with or endorsed by Anthropic."

The interesting part is not that it is fast, though it is. The interesting part is where the safety of your main branch goes once the queue is gone.

What gitai actually is

gitai is mainly a version control server. It also ships its own command-line client, graft, but it is not a drop-in replacement for the git you use every day. It started as a fork of Gitaly, the service GitLab uses to store and serve Git repositories, so the low-level Git plumbing is battle-tested. The project leaves out Gitaly's separately licensed ee/ directory and ships the rest under MIT.

On top of that plumbing, it changes three things about how agents work with a repository, per the README:

  • Agents stay online instead of cloning everything. A classic clone copies the whole history to your laptop. gitai clients fetch only what they need, and history questions (who changed this line, when did this file move) run on the server and get cached.
  • Landing happens on the server. An agent asks the server to land its change. The server rebases the change (replays the agent's edit on top of the newest version of the branch) and then moves the branch pointer.
  • Testing happens after landing. A separate tool, graft-verify, tests the new tip, hunts down the change that broke it, and reverts that change.

The server itself never calls a language model. When two changes conflict, gitai hands the conflict to a resolver you choose: a language model from any provider, a deterministic tool, or nothing at all.

How "land first" works without chaos

The trick that makes this safe enough to try is a compare-and-swap. In plain words: "move the branch to my new commit, but only if the branch still points where I last saw it." If another agent landed in between, the swap fails and the server rebases and tries again. Anthropic's post describes the same primitive in Scion, where moving a branch is "a compare-and-swap on a single database row."

gitai adds batching on top. When several agents land on the same branch at the same moment, the server groups them into a single branch update instead of letting them fight over it one by one.

The README's benchmark shows why that matters. Fifty agents each tried to land five changes (250 in total) on one 16-core machine, with 20% of the changes built to conflict on purpose. The baseline, which the README calls "classic," is the same server with batching turned off, where each agent rebases and retries on its own, up to 20 times:

  • Classic: about 100 changes landed, and each landed change took around 27 attempts.
  • gitai with batching: 200 changes landed, one attempt each. The other 50 were the planned conflicts, left unresolved because these runs used no resolver.

The p99 latency (the slowest 1% of lands) dropped from 6.3 to 7.0 seconds down to 1.5 to 1.8 seconds.

And the 50 conflicts? The README says that with the deterministic resolver configured in resolve.toml, all 250 changes land. Plug in a language model as the resolver instead and you get a different trade: merges that need judgment get it, from software that can be wrong. The limitations file notes that an AI resolver's output is checked only against the answer and the checks you configure, and that semantic conflicts (two edits that merge cleanly but break each other's logic) still need the verifier or a human.

Read those numbers as a sign of direction, not a promise. They come from two runs on one machine, and the project's own benchmark notes say the machine was "shared and saturated during several runs" and that run-to-run variance is large. That page reports one 50-agent run whose p99 jumped to more than nine seconds while the machine's load average (a rough count of processes waiting for the CPU) sat above 40.

Where your safety net moves

Here is the shift that the speed hides.

With a merge queue, broken code never reaches main. The tests act as a gate. With gitai, broken code reaches main for a while, and then the verifier takes it back out. Main stops being "always green" and becomes "green again soon."

That is a reasonable trade for agents. Anthropic's post leans on it, saying the company has "invested in post-merge and pre-deploy automated testing" and that conflicts are something "Claude can typically fix" fast. But it means the verifier now carries the weight the queue used to carry. And gitai's own limitations file is unusually candid about that verifier:

  • It runs with an operator credential, and "a wrong revert can happen when a flaky test passes the flake check."
  • It does not isolate test commands from the host machine. Sandboxing is your job.
  • The server overall is "not a security boundary by itself."

Put those together. Agent-written code lands on main, then graft-verify runs that code's tests with no isolation of its own on whatever machine hosts it, holding an operator credential so it can revert. If you would not run an untrusted pull request's test suite on your CI host without a container, do not run gitai's verifier that way either.

I appreciate that the maintainer wrote this down. Plenty of projects with ten times the stars would not.

Put this into practice

1. Run the quickstart on a spare machine

Pin the release tag so you build the version reviewed here. You need Linux or macOS, Go 1.26, a C toolchain, and the Meson and Ninja build tools (the build compiles its own bundled Git). Then:

git clone --branch v0.2.0 --depth 1 https://github.com/feder-cr/git-ai.git
cd git-ai
make build
examples/graft/quickstart.sh

Per the README, the quickstart starts a temporary server and cache, runs two agents, and lands one change. Expect the first build to take a while, since it compiles Git too. When it finishes, ./_build/bin/graft prints the command-line help.

2. Reproduce the benchmark before you believe it

The benchmark tool ships with the repo. The BENCH.md page documents it; a single run looks like this (note it uses ten changes per agent, not the README's five):

graft-bench --address unix:/var/lib/graft/run/gitaly.socket \
    --repo bench.git --branch bench-land-1 --agents 50 --changes 10 \
    --conflict-rate 0.2 --mode land --token "$GRAFT_TOKEN"

Point the address at your own server's socket, and use a fresh --branch name for every run. To reproduce the README's comparison itself, use the script examples/graft/demo/bench-batch.sh, which builds everything and runs batching off against batching on at 20, 50 and 100 agents, five changes each. Run it twice on your hardware. If your two runs disagree as much as the maintainer's did, you have learned something useful about your machine.

3. Sandbox the verifier first

Before any real agent lands on a gitai branch, decide where graft-verify runs its tests. A throwaway container or VM per run, with no access to the server's credentials, is the minimum. Treat every land as an untrusted pull request, because that is what it is.

4. Ask whether you need this at all

Most teams do not have 30,000 merges a day. If your merge queue is not backing up, gitai solves a problem you do not have yet. The cheaper half of Anthropic's lesson works with plain Git today: partial clone with git clone --filter=blob:none and sparse checkout keep agent workspaces small without changing your server, as long as your Git host supports filtered clones.

Honest limitations

gitai is version 0.2.0, and its own documents say so. The README warns that interfaces may change before 1.0. The limitations file adds more detail than most projects ever publish. The ones a newcomer should know:

  • Single-machine evidence. The limitations file says multi-node behaviour is untested, and the benchmark ran on one box.
  • Thin access control. Policy lives in a local config file. There are no users, groups or per-repository roles, and the shared token can act as any user.
  • Batched updates skip some checks. The combined update runs as a special graft-batch identity, and the pre-receive access check (the permission check Git runs before accepting a push) and the policy check are skipped for it.
  • Not a hosting product. No web UI, no issues, no review workflow, no CI. You bring all of that.
  • Storage assumptions. It expects a local disk with a crash-safe (journaling) filesystem such as ext4 or xfs, not a network share like NFS, and cleaning up the object bundles each batch writes is still a known gap.
  • Self-run numbers. The maintainer built both the tool and the benchmark, and the baseline is the same server with batching off, not GitHub or GitLab.

What to do next

If your agents already wait in line to merge, gitai is worth an afternoon on a spare machine. Run the quickstart, run the benchmark twice, and spend most of your time on the verifier, because that is where your main branch now lives.

If they do not, bookmark it, try partial clone this week, and come back when the line gets long.

Sources: feder-cr/git-ai README, main branch, v0.2.0 (October 18, 2026); doc/graft/LIMITATIONS.md; doc/graft/BENCH.md; Anthropic Engineering, "Redesigning source control" (October 13, 2026); Gitaly; Git partial clone; git sparse-checkout. Reviewed on the main branch as of October 19, 2026; Trendshift rank read at about 07:20 ET.