For a while we took the unfashionable side on branching at GrowthX: feature-sized branches that live as long as the feature needs, the model DHH described for Basecamp. That works fine with a team that has autonomy, knows the domain, has a designer who codes, and works in well-sized features.
Then agents started writing most of the code, and the question stopped being how long a branch lives. It became how you prevent slop and codebase rot at that volume, so we moved to slow planning and fast execution.
Writing about spec engineering made me look at what other teams do with branching, so this is trunk-based development and its alternatives, plus what teams with agents writing most of their code are running today.
What trunk-based development is
One shared branch, and every other branch too short-lived to matter. trunkbaseddevelopment.com asks developers to "resist any pressure to create other long-lived development branches by employing documented techniques," and calls the model "a key enabler of Continuous Integration and by extension Continuous Delivery."
Two styles share the name. Committing straight to trunk: run the pre-integrate build locally and push. Short-lived feature branches: allowed, but "the branch should only last a couple of days. Any longer than two days, and there is a risk of the branch becoming a long-lived feature branch (the antithesis of trunk-based development)." Either way it is one developer per branch, two if pairing, and Google runs the model with 35,000 developers on one monorepo trunk.
Branching vocabulary: mainline, integration frequency, feature branching and feature toggles
Everyone in this debate uses the same words for slightly different things. The names here come from Martin Fowler's "Patterns for Managing Source Code Branches".
Mainline, trunk, healthy branch: The mainline is "A single, shared, branch that acts as the current state of the product." Trunk, master and main are the same branch across three decades of tooling. A healthy branch runs checks on every commit, and a failure is "our number one priority."
Integration frequency: How often your work meets everyone else's on the mainline. "Frequent integration increases the frequency of merges but reduces their complexity and risk."
Mainline integration and continuous integration: Pull mainline, merge, push back if healthy. CI is doing that at least daily; a CI server is not CI. Continuous delivery is keeping the mainline releasable so that "the decision to release the latest version of the product into production is purely a business decision."
Feature branching and pre-integration review: "All work for a feature on its own branch, integrate into mainline when the feature is complete." Pre-integration review is the pull request holding the merge until approval.
Release toggles, permissioning toggles, experiment toggles: The feature-toggle taxonomy on Fowler's site. A release toggle hides incomplete work so it can merge without shipping: transient, static. A permissioning toggle decides which audience sees a finished feature: long-lived, per request. An experiment toggle splits traffic. Every trunk-based prerequisite list means the first one.
Branch by abstraction: Replace a large component without a long branch: abstraction in, callers moved, new implementation behind it, switch, delete. Every step lands on mainline.
Release, maturity and environment branches: A release branch stabilizes a version. Maturity and environment branches encode readiness or deployment targets in source control; Fowler treats both as a smell that belongs in configuration.
Merge hell, integration friction, code drift: Merge hell is the compounding cost of merging weeks of divergence. Integration friction is the everyday tax. Code drift comes in two kinds: textual divergence, which a rebase fixes, and semantic drift, where the branch still compiles against an assumption main stopped holding.
Work-in-progress as inventory: The Poppendiecks put "Partially Done Work" first on their list of software wastes: "Partially done software has all of the evils of manufacturing inventory: It gets lost, grows obsolete, hides quality problems, and ties up money." An open branch is inventory.
What DORA is
DORA is DevOps Research and Assessment: founded in 2015 by Nicole Forsgren, Jez Humble and Gene Kim, acquired by Google Cloud in 2018, now at dora.dev. Since 2014 it has surveyed a few thousand teams a year and correlated practices with delivery outcomes. Accelerate (2018) is the long-form write-up.
DORA's four metrics: deployment frequency, lead time for changes, change failure rate, time to restore. The 2024 report added rework rate. Trunk-based development is a named capability: "each developer divides their own work into small batches and merges that work into trunk at least once (and potentially several times) a day." Thresholds: three or fewer active branches, daily merges, no code freezes.
DORA's data is survey-based and correlational, so it measures how fast changes move; whether the code was any good is outside its scope.
How trunk-based development works
Branches are short-lived: work sliced into pieces that integrate within a day, two at the outside. "Merges to main (trunk) are allowed only as part of closing out the short-lived feature branch (and just before deleting it)." Slicing is the skill; DORA names not knowing how as a primary adoption obstacle.
Every commit builds and tests, and the trunk stays releasable. DORA, Fowler, the Continuous Delivery book and trunkbaseddevelopment.com all put the ceiling on build time near ten minutes. Kent Beck's rule, via Fowler: "nobody has a higher priority task than fixing the build." No freezes, no stabilization phases.
Automated tests are the gate. Fowler: "Self-testing code is so important to Continuous Integration that it is a necessary prerequisite." A ten-minute suite means a wide unit base and thin integration and end-to-end layers; TDD is the habit that tends to produce one. Speed never comes from cutting coverage: "Faster meant to reduce the elapsed time to 'a few minutes'."
Incomplete work merges behind a release toggle: "If it is being built up incrementally on the trunk, it should be hidden behind a feature flag so that incomplete work has no effect on a release cut at any moment." Merge dark, flip when done, delete the toggle. This is how the model decouples deployment from release; canaries and testing in production extend the same idea. The cost is flag debt: the same taxonomy warns "toggles do come with a carrying cost," and a Chrome study across 39 releases found 53% of release toggles survived more than 10 releases and 17% lingered as technical debt. Its mitigations: a removal task at creation, expiry dates, tests that fail past expiry, a cap on flag count.
Review latency is measured in minutes: "A few minutes for the review is best, and tens of minutes acceptable. More than an hour or two, and you are negatively affecting cycle times." Pair and mob programming get latency to zero. Daily integration makes ownership collective by default.
Trunk-based development benefits
Fewer merge conflicts: Divergence is bounded by a day. Merge hell requires accumulation; the model forbids it.
Faster feedback: A conflicting assumption surfaces within hours, before either design hardens.
Delivery performance: In the 2017 Accelerate dataset, high performers deployed 46 times more often with 440 times faster lead time. The 2017 report had high performers' branches "typically lasting hours" against low performers' "typically lasting days." The 2021 report: elite performers 2.3 times more likely to use trunk-based development.
Less work-in-progress: "The more frequently we deploy, the smaller the size of the batch."
Shared ownership: Everything visible to everyone, daily.
What trunk-based development costs
Slicing discipline: Every change decomposes into day-sized increments that each leave main coherent.
The test suite is the real project: A trustworthy sub-ten-minute suite takes months. Teams that adopt the branching model first tend to get the failure mode without the payoff.
Flag debt: Chrome is the ordinary case. Knight Capital is the catastrophic one: $460 million lost on August 1, 2012, after new code "repurposed a flag that was formerly used to activate the Power Peg code," per the SEC order.
Review pressure: Minutes-scale review assumes a colleague is awake and interruptible. Across nine time zones it fails daily.
Open source and async teams: DORA excluded open source from its scope in 2019. A 2026 study of 27,103 branches found open-source feature branches with a median lifespan over two years. Linux, Git, Kubernetes and PostgreSQL all run staged multi-branch models.
The 2022 reversal: The 2022 report found trunk-based development, loosely coupled architecture and continuous delivery together "may have a negative impact on a team's performance," framed as an adoption J-curve. The 2023 report found the effect runs through continuous deployment and is far larger where documentation quality is high. Both findings are usually left out of secondhand summaries of the reports.
How feature branching works
Feature branching comes in three uniforms.
GitFlow is the heaviest. The original post, January 2010: permanent master and develop, feature branches off develop, release branches merged to both, hotfixes off master, --no-ff merges. The author's 2020 note: "If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team." His carve-out is explicitly versioned software supporting multiple versions in the wild.
GitHub Flow is the lightest: branch, PR, review, merge, delete. "We recommend merging a pull request as soon as possible." Run with hour-old branches, it is trunk-based by DORA's definition.
The Basecamp model is one PR per project, weeks long, beta servers on the production database, ship when done. This is the one I worked in for years.
What long-lived feature branches buy you
DHH made the case in "The advantages of large, long-running pull requests":
"My favorite part of doing code reviews is to see all the trade-offs, design decisions, and changes in context together. You can't easily do that if your feature has been chopped into itty bitty pieces as independent pull requests under pressure never to let them run longer than a week."
"So at Basecamp, we let pull requests run as long as they need to encompass a complete feature or fix. That's everything from a few weeks up to as much as six (since we follow Shape Up)."
"When working on a substantial piece of work, I'm frequently hopping back and forth between TextMate and the complete GitHub diff for all the commits. It's in this dance you see the shape of the code, pick up on bad smells, and ultimately decide whether you're happy with the whole."
What a long branch buys is design coherence. Fragments show correct pieces; the whole diff shows whether the pieces should exist in that arrangement. "The size isn't nearly as important as the cohesion of the scope."
What feature branching costs
Divergence compounds worse than linearly. Jez Humble, 2011: "The probability of this happening increases substantially... as the amount of stuff you need to merge, and the time between initial branch and final merge, increases." And: "A feature that is dev complete is 'done'. A feature that is released is 'done done'."
Size cuts against landing. Agent-authored PRs that never merged were 17% larger and touched 10% more files than those that did (arXiv:2601.15195).
Long branches punish refactoring on main, because every structural change conflicts with every open branch, so teams stop refactoring main.
Design feedback also arrives after weeks of investment, when asking for a different shape means asking for a rewrite. Until it merges, the branch is inventory that can go obsolete on the shelf.
Trunk-based vs GitFlow vs feature-sized branches
Branch lifespan: Trunk-based: Hours; two days at the outside; GitFlow: Feature branches days to weeks;
developandmasterpermanent; Feature-sized branches: As long as the feature needs.Integration frequency: Trunk-based: Every developer, at least daily; GitFlow: Features land on
developwhen complete;masterat releases; Feature-sized branches: Once, at completion; main merged in often.Merge conflicts: Trunk-based: Small and constant; GitFlow: Concentrated at release boundaries, double merges; Feature-sized branches: Concentrated at feature merge; reduced by keeping the branch fresh.
Release coupling: Trunk-based: Decoupled via release toggles; GitFlow: Merge to
masteris a release "by definition"; Feature-sized branches: Decoupled; ship each feature when done.Review unit: Trunk-based: Fragment-sized diffs; GitFlow: Feature or release batch; Feature-sized branches: The whole feature in one diff.
What breaks first at scale: Trunk-based: Mean code quality, absent a gate beyond tests; GitFlow: Ceremony and drift between two mainlines; Feature-sized branches: Rebase upkeep and reviewer stamina.
When agents write the code: Trunk-based: Maximizes how fast patterns, good and bad, propagate into the repo agents read; GitFlow: Ceremony an agent gains nothing from; Feature-sized branches: Rebase cost drops to a prompt; the whole-feature diff matches how agents produce work.
What the research says changed once AI agents started writing code
Trunk-based development prices integration risk. Design coherence was priced by an implicit gate: a human wrote the diff and a human read it. Agents removed the first and buried the second.
What DORA's 2024 and 2025 reports found about AI and delivery performance
The 2024 report, under the heading "AI is hurting delivery performance": "an estimated 1.5% reduction for every 25% increase in AI adoption" in throughput, and "an estimated 7.2% reduction for every 25% increase in AI adoption" in stability. Their explanation: "since AI allows respondents to produce a much greater amount of code in the same amount of time, it is possible, even likely, that changelists are growing in size. DORA has consistently shown that larger changes are slower and more prone to creating instability."
The 2025 report, 4,867 respondents: "AI adoption now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability." Batch size held: "With a high degree of certainty, we found that AI adoption's positive benefits depend on teams working in small batches."
Then the AI Capabilities Model, written for "an agentic world": "Promote trunk-based development: Encourage a branching strategy that minimizes long-lived branches and promotes frequent integration." The same program every trunk-based article cites looked at agents and doubled down. Its one finding the other way: "while AI has a positive impact on individual effectiveness, our data suggests that these benefits are slightly reduced in teams that are working in small batches."
Human code review capacity stays fixed while AI authoring volume grows
A July 2026 study: 802 developers, 196,212 PRs, one company under a CTO mandate to double merged PRs. Throughput reached "2.09× the pre-mandate baseline." Cost: "The share of PRs receiving at least one human review fell 21 percentage points (89% to 68%), while the share receiving an automated AI review climbed from ∼19% to ∼84%." Their frame: "AI accelerates authoring while human review capacity stays fixed, so surplus work accumulates downstream." Their partial defense: "merge and revert rates stayed about flat." Their hedge: those proxies "miss the downstream costs of AI-generated code at scale—technical debt, diluted ownership and understanding."
Faros, 22,000 developers: PR size +51.3%, median time in review +441.5%, "Pull requests merged without any review, human or agentic, are up 31.3%," incidents per PR +242.7%. Their prescription: "Set PR size guidelines for your coding agents and enforce them."
LinearB, 8.1 million PRs: agentic PRs at P75 293 lines vs 157 unassisted, pickup 1,055 minutes vs 201, 30-day merge rate 32.7% vs 84.4%.
DX, relaying Meta: "significant lines of code per human-landed diff increased by 106%. Diffs per developer per month rose 51%. More than 80% of that growth came from agentic AI." DX's own telemetry: median PR "growing from 44 lines to 72 lines per pull request between July 2025 and June 2026."
From a survey of 3,100 documents on code review: "review is the control point through which a coding agent's effect on software is decided, and that AI does not fix the sign of that effect: the team sets it."
Automated tests catch behavior failures and miss design failures
Agents produce code that passes. In GitHub's RCT, Copilot users were 53.2% more likely to pass all ten unit tests.
So our most common failure is code that passes every check and should not exist: a fourth pagination helper, a service object duplicating a concern that had a home. Stack Overflow's 2025 survey found 66% of developers frustrated by output that is "almost right, but not quite."
And it compounds, because agents read the repo to decide what to write. A mediocre pattern merged today is precedent tomorrow. GitClear, 623 million changes, vendor data without per-line attribution: block duplication +81% since 2023, moved code from 21% of changes in 2022 to 3.8% in 2026. GitClear's CEO: "you have five different implementations of the same thing that are similar yet different."
Every trunk-based guide lists tests, CI, flags and quick review as prerequisites. None lists a mechanism that stops mean code quality drifting down, because with human reviewers it was free. Continuous integration without one merges mediocre patterns faster.
What other teams report doing now
These are the teams that published mechanics and numbers in 2026, the year agents became the default author.
Stripe: minions, two CI runs, then a human
Minions, February 2026, take a task from ticket to PR on their own branch. "Over a thousand pull requests merged each week at Stripe are completely minion-produced, and while they're human-reviewed, they contain no human-written code." Hard cap: two CI runs, then back to a human, then a second engineer reviews. The branch is uninteresting; the control is how long an agent gets to keep pushing before a person looks.
Anthropic: Claude maintains the apps and tunes its own routines
"As of May 2026, more than 80% of the code we merge into Anthropic's codebase was authored by Claude" (source). The Claude Code lead, August 2026: "we have a Slack channel called proj-claude-maintains-apps. In it, Claude Tag runs a bunch of daily routines across iOS, Android, Desktop, web, CLI, and Agent SDK." Eleven in the attached table: crash fuzzer, dup unifier, dead-code removal, flaky-test fixer, abstraction police, and so on.
"Over the last few weeks, these routines have opened 388 PRs across our repos, 180 of which we merged after Claude Code Review + human review." When one is wrong: "we ask Claude to tune its routines so it's better the next day." The review is aimed at the generator, and the fix is delegated back to it.
Fin and Intercom: an agent approves the PR, if it is small
April 2026: 93% of PRs agent-driven, 19% auto-approved with no human. "Our Agent is strict. It won't approve large PRs." The gate is scope: "If a change is too big, too complex, or too broad in scope, it flags it and requires it to be broken down." Revert rate for AI-authored backend code 0.53% against 5.39% human. Small PRs exist so a model can approve them; human readability stopped being the reason.
Figma: two models review every PR, a third adjudicates
Figma, July 2026, runs two frontier models on every PR, an adjudication agent for borderline findings, later re-reads of disputed findings, escalation to security on-call if a pattern persists. The policy the agents enforce is a 2,560-word threat model. The branching is unremarkable; the review layer has more redundancy than most teams give their humans.
Cloudflare: agents ship behind flags
Flagship, April 2026: "An agent writes a new code path behind a flag and deploys it — the flag is off, so nothing changes for users." Textbook release toggles, applied to agent output.
Meta: 106% more code per diff
Secondhand via DX: lines per human-landed diff +106% in a year, diffs per developer +51%, over 80% of the growth from agentic AI, "reviewers are staring down thousands of pending reviews." Meta's stacked diffs and automated review predate agents; the wave landed on infrastructure built for it.
exe.dev: no code review
exe.dev, August 27, 2026: "Peer code review is dead. We don't do code reviews at exe.dev: we merge code we deem should be merged." Each agent got its own checkout and branch, "and the source collisions mostly went away, but worktrees only solved the Git part." What carries the contract: "Behavior, contract, and property tests matter so much more now."
Their long-lived branches rotted, by abandonment rather than conflict: tasks started, sat for weeks, died. Faros sees 26% more in-progress tasks idle seven or more days. A February 2026 post names it: "many of the PRs cannot be merged after a certain point because they are too far out of date." Agents fixed the textual cost of keeping a branch current. They did not fix abandonment, and free branch creation may have made it worse.
Trigger.dev and GitButler: many branches, one checkout
GitButler is the dissent from one-worktree-per-agent: many branches applied to a single working directory, so two branches with conflicting work cannot both be applied. Trigger.dev's CTO, April 2026: "When we tried worktrees for parallel Claude Code sessions, we spent more time on setup than shipping code." It is the one published case for more branches, and the reason was integration friction.
GitHub: stacked pull requests as a native feature
Public preview July 30, 2026, Vercel and TED named as early adopters. GitHub's engineering post: "That large pull request that's hard to review becomes a stack of smaller, logically ordered pull requests, each scoped to a single concern, small enough to hold in a reviewer's head and with just enough context naturally flowing from the previously reviewed pull request."
"Merge cadence and review unit might be separable" was a hypothesis a year ago. It is now a platform feature.
Where the coding-agent vendors converged: one ephemeral branch per task
Cursor cloud agents "work on a separate branch, then push changes to your repo for handoff." Copilot coding agent "can only work on one branch at a time." Jules: "You are the branch owner." Devin recommends "branch protection rules on your main branch." Claude Code worktrees branch from the remote default branch and remove themselves on exit; /batch splits "the change across 5 to 30 subagents. Each subagent works in its own worktree and opens a pull request."
All current docs, none dated. The pattern: ephemeral, machine-named, task-scoped branch off the default branch, integrated by a human through a PR. It has no settled name yet, and the nearest is Merge Debt, from a July 2026 post: "Writing code got parallel. Landing code stayed serial. Debt piles up exactly at that seam."
What the 2026 teams have in common: the review gate moved off the diff
Every team that kept quality moved the review gate off the diff. Stripe: a CI-run cap plus a second engineer. Anthropic: the routine. Fin: a model with a scope rule. Figma: two models and an adjudicator. Cloudflare: a flag. Us: the plan. Nobody moved it to a bigger diff.
The branch stopped being the unit of anything. One per task, machine-named, dead at merge. The argument about branch lifespan is not one any of these teams is having; their variable is where the check happens.
Small still does work, for a different reason. In the textbook, small PRs exist so a human can review them in minutes. At Fin and in GitHub's stacks, they exist so a model can approve them or so the agent produces better code.
How we work at GrowthX
GrowthX core product, GrowthOS repo: 14 PR authors in the window, agents writing most PRs, humans shepherding. We also have an auto-fix loop for performance and bugs called Amender.
Here’s the last 30 days stats (2026-08-27):
Merged PRs: All PRs: 402 (13.4 per day, 14 authors); Amender (auto-fix loop): 99 (3.3 per day); Human-managed: 303 (10.1 per day, 14 authors).
Open-to-merge, median: All PRs: 1.5 hours; Amender (auto-fix loop): 3.7 hours; Human-managed: 0.9 hours.
Open-to-merge, p90: All PRs: 20.9 hours; Amender (auto-fix loop): 16.9 hours; Human-managed: 23.7 hours.
Open-to-merge, p99: All PRs: 275 hours; Amender (auto-fix loop): 99 hours; Human-managed: 284 hours.
Merged inside 24 hours: All PRs: 91%; Amender (auto-fix loop): 93%; Human-managed: 90%.
Open longer than 7 days: All PRs: 2%; Amender (auto-fix loop): 0%; Human-managed: 2%.
PR size, median: All PRs: 74 lines added across 4 files; Amender (auto-fix loop): 27 lines across 2 files; Human-managed: 125 lines across 5 files.
PR size, p90: All PRs: 931 lines; Amender (auto-fix loop): 95 lines; Human-managed: 1,125 lines.
Main carries 410 commits and zero merge commits: every PR is squash-merged, so main is linear and reads like a changelog. About 86% of merged PRs carry zero human review comments. At this volume, line-by-line human review of every PR is not happening. What replaced it is the reviewed plan and a lot of agent review.
A big part of the 397 is our agentic loop producing fixes for bugs and performance issues, with our lead engineer, reviewing and merging.
Two populations in one repo: trunk-based routine work and long-lived structural branches
A 1.4-hour median against a 174-hour p99 is two populations. The 92% that merges inside a day is trunk-based development by trunkbaseddevelopment.com's own definition. The tail is where the long branches went: PR #3408 ran 16 days and landed 32,534 lines across 190 files; the next longest ran 11, 9, 7 and 7 days, each a coherent piece of structural work that would have been worse as forty fragments. Routine work behaves trunk-based, structural work gets a feature-sized branch. I expected a Basecamp-shaped repo and found this.
Our flags: audience first, feature second
Our flag system handles both: which audience sees a feature, and whether a feature is on at all. Permissioning and release toggles on the same key. The order is a habit rather than a mechanism: we roll out to ourselves first, then to named client workspaces, then to everyone.
Home-made Feature Flag system using a table + a Rails Model (No Flipper, no LaunchDarkly).
Allowlist model. No row for a key means GA. A row restricts to allowlisted workspaces. GA means deleting the row.
Dogfooding is a permission check for
growthx_employee?Exposure opens in layers: employees, then named client workspaces, then delete the row.
Most of what goes behind a flag is complete, because the plan defined "complete" before the code existed; the flag is then about who sees it. When work does merge unfinished, the same key hides it. Two flags is enough for us; a team merging most work dark will run many more.
Where our quality gate is: the reviewed plan
We review the plan. Non-trivial work starts as markdown in docs/plans/: pitch, UX, sliced implementation, adversarially reviewed by a second model before code exists. At merge the plan retires and the tests carry the contract. The spec post has the mechanics.
Things to consider when choosing
Test suite maturity: Without a trustworthy sub-ten-minute suite, trunk-based development tends to arrive before the thing that makes it safe.
Team size and coupling: Many engineers on a coupled codebase is the classic trunk case.
Share of code written by agents: The higher, the more the missing quality gate dominates, and the question becomes where you put it.
Distribution: Minutes-scale review does not survive a team with no shared hours.
Regulatory constraints: Versioned software supporting multiple releases is GitFlow's own carve-out.
Monorepo scale: Google and Uber run trunk on directed-graph builds, merge queues and test selection. Those examples do not make it the only model.
Reading list
trunkbaseddevelopment.com. The definition and every mechanic.
Feature Toggles, on martinfowler.com.
DORA, AI Capabilities Model, plus the 2024 and 2025 reports.
AI Writes Faster Than Humans Can Review, arXiv, July 2026.
exe.dev, Six Months of Writing Code Exclusively With Agents.