# To Branch or Not to Branch: Why We Build on Trunk With AI Agents

> Long-lived branches and worktrees feel safe, but with AI agents they multiply copies, collisions and lost work. Why we moved to trunk-based development, and when a branch still makes sense.

Canonical: https://thegrowthproject.com/blog/to-branch-or-not-to-branch/

**A field note from our own build pipeline.** For a while we gave every piece of work, and every AI agent, its own branch and its own copy of the code. It felt organised. It turned out to be the most expensive habit we had.

**TL;DR:** There are two ways to organise code changes. In branch-based development, each piece of work lives on its own branch, often for days or weeks, and merges at the end. In trunk-based development, everyone makes small changes straight onto the main code ("trunk"), several times a day, and hides unfinished features behind a switch. With AI agents making dozens of changes a day, long-lived branches multiply copies, collisions and lost work. We moved to trunk, and we only branch for a few specific reasons.

## The two ways, in plain terms

**Branch and worktree.** Each task gets its own branch: a separate line of the code where work happens out of the way. With agents, each one often gets its own full copy of the project on disk, called a worktree. When the work is done, the branch merges back.

**Trunk-based.** There is one main line of code. Work is cut into small changes that land on it within hours. Anything not ready for customers is hidden behind a switch until it is. The main code is always in a state you could release.

With a few people making a few changes a week, either works. The difference shows when changes arrive quickly.

## What happened when our agents worked on branches

We ran several AI agents at once, each on its own branch in its own worktree. The problems weren't dramatic, just constant:

- **Collisions.** Agents working on overlapping parts of the code merged changes that each looked fine alone and broke the shared development app together.
- **Copies everywhere.** Every worktree is a full copy of the project and its build. They piled up to tens of gigabytes, and nobody was sure which ones still mattered.
- **The wrong build shipped.** Switching branches inside a worktree ran a build automatically, and it once built into a different copy than we thought. We deployed a stale version without knowing.
- **Half-finished work went missing.** Agents left work on branches that never merged. Cleaning up meant carefully rescuing each copy, checking what had already landed under a different name, and bundling the rest so nothing was lost.
- **Constant catching up.** Every merge made every other branch out of date. About 60% of our automated test runs went on bringing branches back in step. (More in [why GitHub wasn't built for AI agents](/blog/github-wasnt-built-for-ai-agents/).)

## What trunk-based looks like for us

- **Small changes, straight onto trunk.** A change is a few hours of work at most, and it lands the same day.
- **Stacked, not branched.** When one change depends on another, it sits on top of it. We use Jujutsu, a tool that works alongside Git, so stacked changes update themselves when the one below moves. There's no branch to manage. ([Our note on Jujutsu](/blog/jujutsu-git-for-ai/).)
- **One workspace per agent, not one branch per agent.** Agents still need their own place to work so they don't trip over each other, but that space always starts from the latest trunk and gives its work back quickly.
- **A merge queue.** Changes land in order, each tested against the latest code, so two changes that look fine alone can't break trunk together.
- **Switches for unfinished features.** Work can land before it's ready for customers, as long as it's switched off.

## When a branch still makes sense

We're not against branches. We just stopped using them as the default. They earn their place when:

- **You're trying something you'll probably throw away.** A risky experiment can live apart, and be deleted cleanly.
- **You must look after an older version.** If customers run a specific release that needs fixes while trunk moves on, a release branch is the right tool.
- **The change genuinely can't be split yet.** Even then, keep it short-lived. If a branch has been open more than a day or two, it's costing you.

## How to move to trunk

1. **Make the main code always releasable.** If trunk is broken, everything stops, so protect it with quick, reliable checks.
2. **Cut work small.** One idea per change. AI agents are good at this when you ask.
3. **Add switches for unfinished features,** so work can land before it's ready.
4. **Turn on a merge queue,** so changes land in order.
5. **Retire long-lived branches one at a time.** Check what has already landed, finish or rescue the rest, and only then delete.

## For founders and directors

You don't need to know any of the commands to ask the right question: **"Is there any work that has been sitting on a branch for more than a week, and what's stopping it landing?"** If the answer is a long list, momentum is leaking, and it's usually the workflow, not the people.

This is part of what we set up with teams in our [AI Build Kickstart](/services/ai-build-kickstart/).