Trunk and Trains

Five engineers, each running something like twenty agents, all pushing at one repo. That’s roughly where we are at work, and it’s forced a question I used to answer on autopilot. When code arrives this fast, how do you keep the release stable?

Most teams already have the answer drawn on a whiteboard somewhere. It’s a line:

feature ──▶ dev ──▶ uat ──▶ prod

A branch per environment, a merge at every arrow, a sign-off at every stop. It looks like control. It was built for code written at human speed, and it leaks.

The line leaks

Friday afternoon, someone does the stale-PR sweep. There’s one sitting there from three weeks ago, the same diff as a fix that’s already in production, rotted into a conflict with a feature branch nobody remembers opening. They close it. Nothing goes red. Nobody gets paged.

The bug is now back on the next train.

Here’s how it got there. Something broke in UAT, on release/2026.09, two weeks before it shipped. Someone fixed it on the release branch, because that’s what ships, and opened a twin PR with the same diff into develop, because that’s where everyone actually works. The first one was reviewed, merged and on staging before lunch. The second is the one that died on Friday.

Nobody broke a rule. The rule was the bug.

Code flows down the line, but fixes have to swim back up it, and every step back is a merge somebody has to remember. A twin PR isn’t one change in two places. It’s two originals, reviewed by different people against different bases, and nothing in git says they’re related. They can produce different trees, and often do. Only one of the two merges wakes anybody up at 3am, so guess which one gets forgotten. GitLab has had a request open since 2020 to automate the double merge, complete with a workaround that involves a third branch and switching your protections off. When a workflow needs a bot to remember its own steps, the workflow is shit.

That rule comes from git-flow, which Vincent Driessen wrote up in 2010 for software that shipped in numbered versions to customers who might sit on 2.3 for years. In 2020 he added a note to the top of his own post telling web teams to use something simpler. The reference implementation was archived in October 2025, and Atlassian files its git-flow tutorial under legacy. The line on your whiteboard is the same picture with server names painted on the lanes. That’s all the history this needs.

Now pour agents into it

By April 2026 Sundar Pichai was saying three quarters of Google’s new code is AI-generated. Anthropic’s own retrospective puts Claude’s share of merged code at 80%. Across GitHub, merged PRs went from about 25 million a month in early 2023 to about 90 million a month by mid-2026.

The pull request was invented so one human could explain a change to another human. LinearB’s benchmark of 8 million PRs found AI-authored ones wait over sixteen hours for a first review and merge at 33% instead of 85%. A study of 33,000 agent PRs found 61% never got a human review at all. Run several agents on the same repo at once and 42% of PR pairs conflict.

Push that through a four-stage line and every gate turns into a queue. Work piles up in front of the slowest sign-off, fixes pile up behind it waiting to be merged back, and every extra agent makes both piles taller.

Look at where those numbers actually hurt. None of them is about writing code. Agents are very good at writing code. The pain is in reviewing it, landing it without collisions, and knowing afterwards why it’s there. Scott Chacon, who co-founded GitHub and wrote Pro Git, put it about as plainly as it can be put when GitButler raised its Series A: generating change was never the hard problem. Organising, reviewing and integrating it is.

The forge is being rebuilt around that

That’s the bet behind a wave of new forges, and each one goes after a specific place where the old workflow breaks under agents.

The one I think about most is memory. For twenty years the answer to “why does this code exist” was the commit message, or a person you could walk over to. When 80% of the code comes out of an agent in a session that’s closed and gone, that person doesn’t know either. The diff was never the knowledge, and now nobody has it. Entire, from Thomas Dohmke, who ran GitHub until 2025, stores every agent session (the prompt, the transcript, the tool calls) as refs inside the repository, next to the commit it produced. The reasoning lives where the code lives, and travels with it.

Then there’s integration. Cursor’s Origin is a full forge with stacked PRs and an agent-aware merge queue. Stacked PRs keep a big change reviewable by breaking it into a chain of small PRs, each built on the last. A merge queue tests each change against what main will actually look like when it lands. That’s exactly the machinery a hundred agents need, and Origin builds it in instead of bolting it on.

Then context. GitLab’s Orbit builds a context graph so an agent can ask the platform about your codebase instead of re-reading your repo from scratch every morning.

And GitButler, which started out letting you work on several branches in one working directory at once, is building its whole company on Chacon’s line. The work that’s left for people is sorting, reviewing and landing change, and the tooling should be shaped around that.

Put them side by side and you get a list of questions your repo can’t answer today. Why did this change happen? Which session produced it? What else did that agent touch? What’s safe to land next? If the market is selling those answers as features, it’s because your process can’t give them.

Don’t switch forges this year. It’s too early to know which of these wins, and your release can’t wait for the answer. Do two things now instead.

First, start writing agent sessions into the repo, because the format is a git ref and a git ref travels. I made the same argument in May. Capturing it now is cheaper than reconstructing it during an incident in 2028, and it’ll move with you to whichever forge you end up on.

Second, get the shape right.

Trunk and trains

You still have dev, UAT and prod. They just stop being a line of branches. Environments are places you deploy to, not branches you merge into. You build from main, and the same commit rolls forward: to dev on every merge, to UAT when a train is cut, to prod when the train leaves. Nothing gets merged on the way.

main      ●──●──●──●──●──●──●──●──●──●──▶  always green
             │                    │
             └ release/2026.09 ●──●──▶ v2026.09.0 (prod)
               cherry-picks only  └ release/2026.11 ●──▶
feature/x ●──●──┐  two days, rebased on main, merge queue
agent/y   ●──┘

One long-lived branch, held to release standard rather than to “mostly works.” Every merge redeploys it somewhere product and sales can open without asking. Forget what CI says. The real test is whether you’d let a salesperson click around it during a customer call without hovering behind them.

Feature branches come off it and go back within days, through a merge queue. An agent branch is just a very short feature branch: it comes off main, goes through the queue, and either lands green or doesn’t land at all. Anything longer than a train goes behind a flag or gets split into a stack of small PRs.

Release branches get cut on a fixed date and from that moment accept cherry-picks of commits already on main and nothing else. A bot opens them with -x so each commit records where it came from, and the release manager asks one question: does this need to ride this train, or can it wait eight weeks? Hotfixes use the same path, because there isn’t another one. Production is on fire, you fix it on main, and that’s the only PR anyone reviews. It’s how the Linux stable trees, Chromium and Kubernetes already work. One canonical change on the trunk, and the backport is a mechanical copy with provenance.

Everybody’s first instinct under load is to add a branch, because a branch feels like control. It isn’t. It’s a place to hide work until it becomes somebody else’s problem. Add machinery instead: a merge queue that batches and bisects, affected-target testing so CI doesn’t turn into a number somebody in finance forwards to your CEO, CODEOWNERS with real names on a rotation, and a size cap that agents will find annoying. Which is, not by coincidence, most of what the new forges are building in.

The last holdout is always the same guy, and he’ll tell you the double merge has never actually bitten him. That’s bollocks, and it takes ten minutes to prove. Run git log --oneline release/current..develop and then the reverse, count the commits that exist on one side only, and put the list up on the screen. It bit him in March. He just wasn’t the one who had to fix it.

Want to chat? X / LinkedIn