Agent-Scale Git: Why Code Hosting Is Being Rebuilt

Git doesn't care whether a commit came from a person or an agent, but the tools around it 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.

Agents break that cadence. When a team runs several at once, each one can finish a task and open a change while you are still reading the last one. 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 covers two things. The first is volume: more commits, branches and pull requests an hour. The second is when work arrives. An agent's change shows up whenever its task finishes, whether or not anyone is ready to read it. Human-paced hosting assumes the person who produces a change is also the person waiting on it.

Agent throughput lands on four parts of the workflow that every host already has. A pull request that waits for review also holds a branch, needs CI runs and drifts toward a merge conflict, so the strains add up.

The review row hurts first. A model can write a correct change in a minute, but a person still reads it at human speed, and now there is a queue of them. There are two ways to ease it: make changes smaller so each review is quicker, or move the first pass to a bot.

Branches look like the harmless row, and storage isn't the issue. The issue is that the branch list stops working as a record of what is in flight. Nobody can say what is open without asking, and stale branches pile up faster than anyone prunes them. Money is a second cost: if CI runs on every push, a branch per task produces a bill that tracks agent activity rather than headcount.

Which row limits you first depends on your CI bill and your number of reviewers, not on how many agents you run.

Cursor argues that the hosting layer should be rebuilt for this workload, not patched. Origin's product page states the premise in one line: code is "moving faster than any infrastructure was built to handle." Cursor has since documented parts of the mechanism: an engineering post on the storage layer, docs for stacked pull requests, and release notes for a merge queue.

The same post describes the strain from Cursor's side. Agents bring more code, more pull requests and more CI runs, and Cursor says it faced these problems internally for many months. The post doesn't describe a team whose changes were written, reviewed and approved, then blocked on the host. The reported numbers all measure storage, and a queue that waits on reviewers doesn't move when storage gets faster. We read Origin as a bet on the workload agents are bringing: worth watching, not worth migrating for this quarter.

You don't need Origin to feel this problem or to start managing it. These moves work 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. In the Cursor editor, the /worktree command runs a task in one.
2. 2Keep changes small. Smaller diffs review faster, and review is the bottleneck once agents write the code.
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 flags likely bugs, on plans that include Bugbot (not Free or Plus).
4. 4Slow down at the merge. Throughput is worth nothing if you merge a change nobody understood.

The order of those four matters, and swapping the middle two is the mistake to avoid. A bot's first pass over a huge diff produces a long list of comments nobody reads. Over a small change, the same bot 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. You already choose what runs per push and what runs per merge, and at agent volume that choice decides whether the queue clears. A merge queue is where the split gets enforced.

If agent output isn't turning into shipped work, look at the age of your open changes before their count. Forty changes that are all four hours old is a throughput problem. Six changes open since last week is a review-attention problem, and no amount of hosting speed fixes it. On a small team the second is more likely, and the unwelcome fix is to run fewer agents at once. In a larger organization, look for a shared choke point such as a runner pool or one required approver.