Agents Make Trunk-Based Development Cheap: One Task, One Branch, Landed Same Day

• Book: RAG Pocket Guide
• The series: Pocket Guides for Developers — 8 short books on agents, RAG, prompts, observability, events, databases and system design — the whole series
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

DORA's bar for trunk-based development fits in one sentence: three or fewer active branches in the repository, and every branch merged into trunk at least once a day. Most teams never got close. Feature branches lived for a week or a sprint, and the merge at the end was a small project of its own.

Now picture your repo after a few months of coding agents. There is a branch called agent-work. Several agent sessions have committed to it, each one finishing a tidy little task. The branch touches files all over the codebase, it is well past a week old, and it is waiting for "the big review" that nobody has blocked out an afternoon for.

My take: the agent era is the cheapest moment there has ever been to adopt trunk-based development, and a lot of teams are spending it rebuilding the exact merge pain DORA measured.

What DORA has been saying for years

Trunk-based development, as DORA describes it, means developers merge small batches into the main line "at least once (and potentially several times) a day", on branches that "typically last no more than a few hours". DORA ties the practice to its 2016 and 2017 data, where teams that followed it achieved higher software delivery and operational performance. The capability page gives three goals you can measure: three or fewer active branches, at least one merge to trunk per day, and no code freezes.

It is just as direct about the alternative. Long-lived branches "require bigger and more complex merge events", large merges "frequently introduce bugs or regressions", and "the longer a merge is delayed, the more likely it is to create merge conflicts and associated issues."

None of that surprised anyone, and teams kept the long branches anyway.

Many short branches that rejoin the trunk the same day, and the one long branch that drifts away.

Humans batch. Agent tasks don't have to.

The reason sits on the same DORA page, under common pitfalls: when code review "is laborious and takes hours or days, developers avoid working in small batches." If every merge costs a trip through the review queue and a context switch, you save changes up so you only pay once. That is a rational move for a person. It is also how a two-day feature turns into a branch nobody wants to rebase.

Google's code review study shows what the other side looks like. Sadowski et al. analysed review logs for 9 million reviewed changes (ICSE SEIP 2018). The median change modified 24 lines, over 35% of changes touched a single file, and about 90% touched fewer than 10 files. Authors waited a median of under an hour for first feedback on small changes and about 5 hours on very large ones, and the median for the whole review process was under 4 hours. The paper notes that developers there "are strongly encouraged to make small, incremental changes", and cites earlier studies where review latency rises as change size grows.

A coding agent's task arrives already cut to that size. You write one prompt: fix the flaky login test, or add a refund endpoint with a test. The agent works until that prompt is done, then it stops. The task has a clear end and its own diff, and nothing about it needs to wait for the rest of the week.

The agent has no batching instinct. It doesn't find small merges tedious, and it doesn't sit on half-finished work to dodge a context switch. The habit DORA kept fighting was a human one. The agent doesn't have it. You still might.

The agent branch that waits a week

The numbers say the agent era can go either way. DORA's 2024 report estimated that as AI adoption increased, delivery throughput fell by 1.5% and delivery stability by 7.2% (Google Cloud, October 2024). Its advice pointed back at the basics of successful software delivery: small batch sizes and solid testing. A year later, DORA's AI Capabilities Model (September 2025) listed working in small batches as one of seven capabilities, saying it "amplifies the positive influence of AI on product performance and reduces friction for development teams."

Faros AI's Q2 2026 report used two years of telemetry from 22,000 developers across 4,000 teams. Compared with low-adoption teams in the same organizations, high-adoption teams had a 16.2% higher PR merge rate, 51% larger PRs, 5x the median review time and 28% more bugs per PR. Faros labels these findings correlations. In that data, more work lands, in bigger pieces that take longer to read.

On a single repo, the agent-work branch is how you get there. Each agent session produced a small diff. Stacking them onto one branch and reviewing them together throws away the one property that made them easy to review, and rebuilds the delayed merge DORA warned about. What reaches the reviewer is a wide diff with no clear author per change, against a main that kept moving the whole time.

One task, one branch, landed the same day

These are the rules I would hold an agent workflow to:

• One task per branch, cut from trunk when the task starts. A second task never commits onto it.
• The branch lands the same day, or the task gets smaller. If the diff is too big to read in one sitting, split the prompt and delete the branch. Rerunning a narrower task is usually cheaper than reviewing a wide one.
• Review while the task is fresh. DORA's pitfall list warns against asynchronous review, where a request sits in a queue while its author moves on. When an agent finishes, read its diff before you start the next thing.
• Unfinished feature? Merge it switched off behind a flag instead of parking it on a branch.
• Watch the count. Three agents running in parallel already puts you at DORA's limit of three active branches. That is fine if all three land today.

Plain git does all of it. git worktree gives each task its own folder and branch, so parallel agents never share a checkout:

# start a task: own branch, own folder, cut from main
git switch main && git pull --ff-only
git worktree add -b task/fix-login ../fix-login

# ...the agent works in ../fix-login and commits...

# land it the same day: refresh main first
git pull --ff-only
git -C ../fix-login rebase main
git merge --ff-only task/fix-login
git push
git worktree remove ../fix-login
git branch -d task/fix-login

If your team merges through pull requests, push the branch and run gh pr create --fill from the worktree instead of the local merge. The rule stays the same: the PR is opened and reviewed the day the agent finishes.

To see how far you are from DORA's numbers, list local branches by their last commit, oldest first:

git for-each-ref refs/heads --sort=committerdate \
  --format='%(committerdate:relative)  %(refname:short)'

Any unmerged branch near the top whose last commit says "days ago" has missed the once-a-day merge.

Where Hermes fits

I build Hermes IDE, so weigh this section with that in mind. You don't need it for any of the above: the git commands are the whole technique. Hermes is built around the same shape. It runs Claude Code, Codex and other agent CLIs side by side, each in its own terminal, and ⌘N (Ctrl+Shift+N on Windows and Linux) starts each task on its own hermes/<name> branch in its own worktree, with the task as the agent's first prompt.

The ⌘N New task sheet: Claude Code, the orders-api project, a new hermes/ worktree, Accept edits, model and effort, and the "Hermes will run" preview of the claude command.

When the agent finishes, the Review Desk (⌘G) shows its changes by turn or by file, with risk flags. Land then commits, opens a pull request or merges locally in one step, into the branch the task started from, and it can be undone. Undo data for a landed task is cleared after 14 days (release notes). Your own checks can decide when a task counts as done, which is where the "tests before commit" rule from DORA's pitfall list belongs.

The Worktrees tab: one Hermes worktree each for orders-api, web-app and orders-types, with each worktree's hermes/ branch, task, age and disk size, and the free disk space.

Under the hood these are ordinary git branches and worktrees. Hermes is free to download, source-available under BSL 1.1, and runs on macOS, Windows and Linux. It is not affiliated with Nous Research, Anthropic, OpenAI or any agent vendor.

Where this take breaks

Some work doesn't fit in a day. A schema change with a data backfill, or a framework upgrade that breaks call sites across the codebase, is several tasks wearing one name. Split it into steps that each land on their own, and keep the old path working until the last one is in.

Trunk-based development without fast tests ships breakage faster. DORA calls the practice a requirement for continuous integration, which pairs it with fast automated tests after every commit, and lists skipping tests before commit as a pitfall. If your suite takes an hour, fix that before you raise the merge rate.

Review is still the bottleneck. The 5x median review time in Faros's data is the warning: small branches only help if a human reads them the day they appear. Short branches also shrink the window in which two parallel agents edit the same file, but they don't close it, so you still sequence work that overlaps.

An agent's task is small when it finishes. The only way to make it big again is to let it wait, so land it today.

If this was useful

If you want to try the one-task-one-branch flow with the agents you already pay for, Hermes IDE is a free download and the source is on GitHub.

A task stays small more easily when the agent finds the right code before it starts editing, and that is a retrieval problem. My RAG Pocket Guide covers retrieval, chunking and reranking, the ideas you need when a model has to find the right context in a large codebase or docs set before it answers. It is one of 8 short books in the Pocket Guides for Developers series, covering agents, RAG, prompts, observability, events, databases and system design: the whole series is here.