---
title: "Trunk-based development with AI coding agents · Cork"
description: "Trunk-based development when AI coding agents write much of the code: short-lived agent branches, daily merges, feature flags, rebase-test-push, merge queues."
canonical: "https://corkcli.com/blog/trunk-based-development-ai-coding-agents"
last_updated: "2026-10-03"
published: "2026-10-03"
author: "Kevin Vera"
---

# Trunk-based development with AI coding agents

Trunk-based development when AI coding agents write much of the code: short-lived agent branches, daily merges, feature flags, rebase-test-push, merge queues.

By Kevin Vera · October 3, 2026 · [Guides](https://corkcli.com/blog/c/guides) · 6 min read

Trunk-based development works well with AI coding agents, as long as you keep its rules strict: every agent works on a branch that lives hours, not days, starts from the latest trunk, lands through a rebase and a full test run, and hides unfinished behavior behind a feature flag. Agents produce many small changes quickly, which suits trunk-based development, but they also multiply the number of branches racing to land on the same trunk, so the landing step needs more discipline than it does with humans alone.

## What trunk-based development asks for

The reference definition, from trunkbaseddevelopment.com: "A source-control branching model, where developers collaborate on code in a single branch called 'trunk' and resist any pressure to create other long-lived development branches by employing documented techniques." The core practices:

- **Commit to trunk often.** The site's rule is to "commit to trunk at least once every 24 hours."
- **Short-lived feature branches are fine** when they exist for code review and CI, "before commits land in the trunk for other developers to depend on."
- **Feature flags and branch by abstraction** let incomplete work merge safely: use "feature flags in day to day development" and branch by abstraction "for longer to achieve changes."

Every one of these applies to agents. The question is how to enforce them when the developer is a process that never gets tired of opening branches.

## Rule 1: every agent branch starts from fresh trunk

An agent that starts from a stale base produces a branch that conflicts on arrival. Claude Code's worktree default already does the right thing: new worktrees branch "from the repository's default branch on the remote," and if the repo has not been fetched in the last 24 hours, Claude Code fetches the default branch first.

```bash
claude --worktree fix-rounding
```

Leave `worktree.baseRef` at its default (`"fresh"`) for trunk-based work. Set it to `"head"` only when an agent must build on unmerged local commits, which in trunk-based development should be rare.

With plain git:

```bash
git fetch origin
git worktree add ../app-fix-rounding -b fix-rounding origin/main
```

## Rule 2: one agent task, one small branch, merged the same day

Size agent tasks to land within a day. If a task cannot, it is two tasks, or it needs branch by abstraction:

1. Land the new abstraction (an interface both the old and new code satisfy).
2. Land the new implementation behind a flag, unused.
3. Switch callers over in small batches.
4. Delete the old path.

Each step is a short-lived branch an agent can finish and land the same day. Put the rule where agents read it:

```markdown
## Branching
- Work on a short-lived branch from origin/main. Aim to land within a few hours.
- If the change cannot land today, stop and propose how to split it.
- New user-facing behavior goes behind a feature flag, default off.
```

## Rule 3: land with rebase, full tests, push

On trunk, the landing step is where agents collide. Two agents each pass their own tests, then break each other on trunk. The routine:

```bash
git fetch origin
git rebase origin/main
# run the FULL test suite here, not only the tests for this change
git push origin HEAD:main      # or open a PR if trunk is protected
```

Rebasing replays the agent's commits on top of what landed since it started. Running the full suite after the rebase catches semantic conflicts that git merges cleanly: a function another agent renamed, a type that gained a required field, a default that changed.

If trunk is protected and changes go through pull requests, use a merge queue so the test run happens against the real future trunk. GitHub's merge queue ensures "the pull request's changes pass all required status checks when applied to the latest version of the target branch and any pull requests already in the queue." With many agent PRs in flight, that turns "it passed on my branch" into "it passes on trunk."

## Rule 4: keep trunk green, fast

With several agents landing per hour, a red trunk stalls everyone, humans and agents alike. Three practices help:

- **Revert first, debug second.** If a landing breaks trunk, revert it and let the agent fix it on a new branch.
- **Fast feedback.** A slow suite tempts people (and agent instructions) to skip it. Split smoke tests that run on every landing from the long suite that runs on a schedule.
- **Never rewrite trunk.** Agents should never force-push the main branch. On their own branches, `git push --force-with-lease` is the safe form; git's docs explain that plain `--force` can "lose their work" if someone built on the old history.

## Rule 5: watch for the trunk-specific agent failure modes

| Failure | What it looks like | Prevention |
|---|---|---|
| Stale base | Agent's branch conflicts the moment it is done | Start from fresh `origin/main`; rebase before landing |
| Semantic conflict | Clean merge, broken build | Full test suite after rebase; merge queue |
| Long-lived agent branch | A "quick" refactor still open after three days | Same-day rule; branch by abstraction |
| Flagless half-feature | Unfinished UI ships to users | Flags default off for new behavior |
| Duplicate work | Two agents fix the same thing on trunk in different ways | Claim work in one place before starting |

## How Cork helps

Trunk-based development concentrates every agent's work on one branch, which is exactly where parallel agents collide. Cork is built for that point. Cork is the [coordination layer](https://corkcli.com/blog/coordination-layer-ai-coding-agents) for multiplayer coding agents: it keeps Claude Code, Codex and Cursor agents, on one machine or across a team's machines, from overwriting each other on one codebase, and hands each agent what the others already learned.

For this problem specifically:

- **Landing:** `git push` becomes one step that rebases onto teammates' commits, reruns the tests and pushes, which is Rule 3 done the same way every time.
- **Live awareness and [semantic lint](https://corkcli.com/blog/semantic-lint):** when another agent renames or re-signatures a symbol yours uses, your agent hears it on its next step and is checked against the change, before the landing test run has to catch it.
- **[Write gate](https://corkcli.com/blog/write-gate):** an edit against code another agent is changing right now is held until your agent has their version.
- **Briefing:** each agent starts with the exact signatures, callers and recent changes of the code it will touch, so its base is current in practice, not just in git.

Install it once for every repo on the machine:

```bash
curl -fsSL https://corkcli.com/install.sh | sh
```

## Frequently asked questions

### Does trunk-based development work with AI coding agents?

Yes, and agents' small, frequent changes suit it. The difference is volume: more branches land on trunk per hour, so rebasing onto fresh trunk and running the full suite before each landing becomes mandatory.

### Should AI agents commit directly to main?

Only if your trunk accepts direct pushes and each push goes through a rebase and a full test run. Most teams have agents open short-lived pull requests and use a merge queue.

### How long should an AI agent's branch live?

Hours. Trunk-based development's guideline is to commit to trunk at least once every 24 hours; size agent tasks so each lands the same day.

### How do I stop parallel agents breaking trunk?

Start each agent from fresh trunk, rebase before landing, run the full suite after the rebase, and use a merge queue or a coordination layer that tells agents about each other's renames before they land.

## Sources

- <https://trunkbaseddevelopment.com/>
- <https://code.claude.com/docs/en/worktrees>
- <https://git-scm.com/docs/git-worktree>
- <https://git-scm.com/docs/git-push>
- <https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue>

## Related reading

- [How to land agent changes in one step: rebase, test and push](https://corkcli.com/blog/land-agent-changes-rebase-test-push): Land AI agent commits in one step: fetch, rebase onto teammates' work, rerun tests and push, using a script, a pre-push hook or a merge queue.
- [How to review pull requests from several AI agents at once](https://corkcli.com/blog/review-pull-requests-from-multiple-ai-agents): Review pull requests from several AI coding agents at once: triage with gh, review for cross-PR conflicts, use CODEOWNERS, AI review passes and a merge queue.
- [How to onboard an engineer when AI agents write half the code](https://corkcli.com/blog/onboard-engineers-ai-coding-agents): Onboard a new engineer on a codebase where AI agents write much of the code: agent instruction files, guardrails, ownership, and a first week plan that works.
- [Landing: rebase, test and push in one step for AI coding agents](https://corkcli.com/blog/landing-rebase-test-push): Landing means getting finished work onto the shared branch in one step: rebase onto everyone else's commits, rerun the tests, then push only if they pass.

[All articles](https://corkcli.com/blog.md) · [Cork in Markdown](https://corkcli.com/index.md) · [llms.txt](https://corkcli.com/llms.txt)

This page in HTML: https://corkcli.com/blog/trunk-based-development-ai-coding-agents