Agent-Scale Git: Why Code Hosting Is Being Rebuilt

Git itself does not care whether a commit came from a person or an agent. The tools built around git do. Pull requests, review queues, CI runs and merge rules all assume a human cadence: you finish a change, open one request, wait for a teammate, then merge. That rhythm is the thing agents break.

When a team runs several agents at once, each one can finish a task and open a change while you are still reading the last one. The work piles up at review and merge, not at writing. Agent-scale is shorthand for hosting that expects that pile-up and is built to clear it.

The phrase is doing two jobs, and only one of them is about volume. Volume is the easy half: more commits, more branches, more pull requests an hour. The other half is arrival pattern. Work from an agent shows up whenever it finishes, with no regard for whether anyone is ready for it, and human-paced hosting quietly assumes the person producing a change is also the person waiting on it.

The strain shows up in a few familiar places, and they compound. The table names each one and what it looks like when agents, not people, are the ones generating the work.

The review column is the one that hurts first. A model can write a correct change in a minute, but a person still reads it at human speed, and there is now a queue of them. Most attempts to fix this either make changes smaller and easier to review, or push more of the first-pass review onto bots.

Branches look like the harmless row. Storage is not the problem. The problem is that your branch list stops functioning as an index of what is in flight, so nobody can say what is currently open without asking, and stale branches pile up faster than anyone prunes them. There is a second-order cost in money too: if CI runs on every push, a branch per task produces a bill that tracks agent activity rather than headcount.

Which row binds you first depends on your CI bill and your reviewer count, not on how many agents you happen to be running.

Cursor's framing is that the hosting layer itself should be rebuilt for this, not patched. The confirmed part is the intent: a git forge for the agent era, with the line that code is "moving faster than any infrastructure was built to handle." The mechanism is where confirmed runs out.

One specific observation would show that the hosting layer is really the constraint, and it is teams whose changes get written, reviewed, approved and then blocked on the forge itself. I cannot find that written down anywhere. The reported numbers all measure the storage layer, which is the capacity most teams have never come near saturating. So Origin reads as a bet on the workload that is arriving rather than a description of the one teams have now, which makes it worth watching and not worth migrating for this quarter.

You do not need Origin to feel this problem, or to start managing it. The moves that help are ones you can make on GitHub or GitLab right now, with Cursor features that already ship.

1. 1Give each parallel agent its own worktree so two agents editing nearby files don't collide. The /worktree command sets one up.
2. 2Keep changes small. Smaller diffs review faster, which is the real bottleneck once agents are writing.
3. 3Put a bot on the first pass. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. reviews pull requests and Auto-review can gate risky changes before a human reads them.
4. 4Treat the merge as the moment to slow down, not speed up. Throughput is worth nothing if you merge a change no one understood.

The order of those four is not arbitrary, and inverting the middle two is the common mistake. A bot's first pass over a huge diff produces a long list of comments nobody reads; the same bot over a small change produces two comments you act on. Shrink the unit first, then put automation in front of it.

Running the full test suite on every push is a habit from human-paced work. What runs per push and what runs per merge is a choice you already have, and at agent volume it decides whether the queue clears. A merge queue is where that split gets enforced.

If agent output is not turning into shipped work, the cheapest thing to look at is the age of your open changes rather than their count. Forty changes that are all four hours old is a throughput story. Six that have been open since last week is a review-attention story, and no amount of hosting speed touches it. Small teams tend to find the second, where the unwelcome fix is to run fewer agents at once. Larger organisations find both, and their pile-up usually sits at a shared choke point such as a runner pool or one required approver.