Why GitHub Wasn't Built for AI Agents (and What to Do About It)

A field note from our own build pipeline. When we put AI coding agents to work on our own software, the agents weren’t the slow part. The workflow around them was: pull requests, reviews and GitHub Actions runs designed for people working at a person’s pace.

The rhythm GitHub was built for

A developer picks up a task, works on it for a few hours or days, opens a pull request, and waits for a colleague to review it. GitHub Actions runs the tests on each push. A few changes a week per person. The tools, the review screens and the habits all assume that pace.

An AI agent works differently. It makes a dozen small changes in an afternoon, often several at once, each building on the last. Squeeze that through a one-at-a-time review queue and three things happen.

Changes fall out of step

Every time one change merges, the others have to be brought up to date and tested again. When we measured three days of our own agents’ work, about 60% of our automated test runs were spent just on that catching up. Not new work. Keeping in sync. (The detail is in our note on Jujutsu and Git for AI coding.)

One reviewer becomes the bottleneck

If a senior person must approve every change, agents wait on them all day. Worse, when someone approves fifty changes a day, they stop really reading them. The approval becomes a rubber stamp, which is the opposite of what it was for.

Green ticks feel like progress

Automated tests passing tells you the code does what it attempted. It doesn’t tell you it was the right thing to build. We judge AI work by a harder question: would a senior engineer actually accept this change?

GitHub Actions: where the time and money go

GitHub Actions is GitHub’s built-in system for running checks on every change. At a person’s pace it’s excellent. At an agent’s pace, its defaults work against you:

• Every push runs everything again. An agent that updates its change five times triggers five full runs, and the first four are wasted the moment the fifth arrives.
• Every merge makes other changes stale. When one change lands, every open change needs bringing up to date, and each update triggers another full run.
• Agents wait for checks. If a run takes twenty minutes, every agent sits idle for twenty minutes, many times a day. Paid runner minutes climb at the same time.

The mechanisms that help

None of this means leaving GitHub. It has good tools for exactly these problems, most of them off by default:

1. The merge queue. Approved changes join a queue, are tested one by one against the latest code, and merge in order. Workflows listen for the merge_group event, so the final check runs once, at the point that matters.
2. Cancel superseded runs. A concurrency group with cancel-in-progress stops the old run as soon as a newer push arrives, so you only pay for the latest version.
3. Run only what changed. Path filters skip checks for parts of the code a change didn’t touch. One catch: a required check that gets skipped can leave a pull request waiting forever, so add a small always-run job that reports the overall result.
4. Cache what you can. Caching dependencies and build outputs often turns a fifteen-minute run into a few minutes.
5. Split fast checks from slow ones. Make the quick checks required on every change, and run the long suites in the merge queue or nightly instead of on every push.
6. Approve by risk. Rulesets and code owners can require a person’s review only for the folders that touch money, logins and customer data, and let everything else merge once checks pass.
7. Bigger or self-hosted runners. When checks are the bottleneck, more powerful machines are usually cheaper than idle agents and developers.

It comes back to your velocity and workflow type

There’s no single right setup. It depends on how fast changes arrive and who makes them:

How your team works	What’s enough
People writing most changes, a few a week each	GitHub’s defaults are fine. Keep pull requests small and checks fast.
People working with AI assistants, several changes a day	Turn on the merge queue, cancel superseded runs, cache, and approve by risk.
AI agents writing most changes, dozens a day	The settings above, plus build on trunk instead of long-lived branches, stack small changes, and let checks do the first review. Expect to outgrow the one-pull-request-per-branch model.

We sit in the last row. That’s why we changed how we work, not just our settings.

What we changed

• Trunk, not long-lived branches. Every change is small and lands on the main code within hours, not weeks. We explain why in to branch or not to branch.
• Stacked changes. Small changes sit on top of each other and update automatically when the one below moves. We use Jujutsu, a tool that works alongside Git, so the catching up happens without anyone doing it.
• Checks first, people second. Automated tests and an independent automated review look at every change before a person does.
• Approval by risk. Anything that can’t be undone, like payments, logins, customer data or database changes, needs one person’s approval. Low-risk changes merge once the checks agree.
• No marking your own homework. An AI agent never approves its own change, and never gets other agents it started to approve it either.
• A merge queue. Approved changes go in one at a time, in order, tested against the latest version.

The bigger point

AI doesn’t make a team fast on its own. It makes whatever way you already work go faster, including the bottlenecks. Fix the decisions and the workflow first, and the speed shows up as working software, not just more activity.

This is the setup we put in place with teams in our AI Build Kickstart.