uyeon.dev
Published on

Agents Get Lost in GitFlow — Why AI-Native Development Converges on Trunk

In January 2010, Vincent Driessen published a blog post titled “A successful Git branching model”. develop, feature, release, hotfix, main — that diagram of five interlocking branches is GitFlow. For the next decade, it sat on the first page of engineering wikis around the world.

Ten years later, Driessen added a reflection note to the top of that same post. Not a retraction — he kept it, noting that GitFlow remains valid for software with explicitly versioned releases. But he narrowed its scope: for web apps that deploy continuously, consider a much simpler workflow instead of GitFlow. The kind of software he had imagined ten years earlier, he wrote, was not this. Atlassian, famous for its GitFlow tutorial, now files the model under “legacy workflows” and states outright that the page is kept for historical purposes.

And yet, in 2026, GitFlow — or its cousin, the dev/prod environment-branch model — is still the default for countless teams, for the simple reason that it works. Branching strategy is so foundational that once it settles in, nobody ever looks at it again.

When only humans wrote code, that was tolerable. Inconvenient, but manageable. In AI-native development, where agents write the code, that manageability ends. Branching strategy is no longer a matter of taste but a matter of throughput, and the answer is converging on trunk-based development. This post is about why.

GitFlow was right for its time

GitFlow was not a bad design.

In 2010, deployment was scary. CI was uncommon, test automation was a luxury, and a release was a quarterly event you scheduled and braced for. With integration that expensive and risky, quarantining dangerous things in branches was the best available move. Unfinished code goes to develop, release candidates to release, production code to main. Perfectly rational.

The problem is that every one of those premises has since disappeared. CI now runs on every commit, deployment is a button, and tests grow alongside the code. The conditions that made integration expensive are gone, but the structure built for those conditions survived as habit. And in 2026, agents climbed on top of that habit.

What long-lived branches actually cost you

If you’ve worked with GitFlow, these scenes will feel familiar. They’re familiar to me firsthand: on a small team that needed to move fast, I once tried following GitFlow to the letter, and before long the branching strategy itself had become the bottleneck.

The day you merge a two-week-old feature branch into develop, half a day vanishes into conflict resolution. A reviewer receives a 40-file PR and clicks “LGTM” — which effectively means they didn’t read it. That code ships with a bug in it, the bug surfaces three weeks after the code was written, and by then even its author doesn’t remember writing it.

A production incident hits at 3 a.m. and you push a hotfix to main. You must also remember — at 3 a.m. — to back-merge it into develop. Forget, and the bug you just fixed resurrects in the next release. I’ve lived this one too. The back-merge rule was written down, plainly. Following it properly while putting out a fire turned out to be a different kind of difficulty altogether.

And one more. If your setup builds separately per branch, your QA team may never once have tested the build that actually went to production. The build validated on the dev branch and the build deployed from main are different combinations of commits. Without build promotion — moving the exact artifact you validated on to the next stage — that mismatch repeats on every release as this structure’s default behavior, with nobody making a single mistake.

Go one variant further, splitting branches per component as well (dev-frontend, dev-backend, prod-frontend, prod-backend), and a single API change needs two PRs with a human choreographing the deploy order. You’re running a monorepo while reenacting the pain of polyrepos.

Trace these scenes to their root and you find a paradox. Deployment is scary, so you batch changes up before shipping. But batching makes each deployment scarier. The longer the release interval, the more changes each release carries; the bigger the change set, the higher the odds of an incident and the harder the postmortem. So next time you’re even more careful, and batch even more. It’s a vicious cycle. Many teams remember this structure as “we’re being careful,” but what that caution actually does is carry the risk forward into the future. Merge conflicts are not a git problem. They are the invoice for all the time you spent deferring integration.

What trunk-based looks like today

Say “trunk-based” and many people picture the SVN days — everyone shoving commits into one line. There’s also a lingering impression that elaborate branching is elegant and dumping everything on trunk is crude. Both are misconceptions. Here is what a day looks like in the modern version.

You pick up an issue in the morning and branch off main. You open a PR in the afternoon. CI passes, review completes, you merge to main, and the branch is deleted. A branch lives a day at most. Merging to main auto-deploys to the dev server. Once verified, you tag the commit, and that tag triggers the production deploy. Crucially, nothing is rebuilt at this point — the exact build validated on dev is promoted to production. Features that aren’t ready for the public get merged anyway, switched off behind a feature flag.

Path comparison between GitFlow and trunk-based development: GitFlow needs four merges (feature to develop to release to main) plus a hotfix back-merge, while trunk-based needs one merge from a short-lived branch, followed by a tag and pipeline promotionPath comparison between GitFlow and trunk-based development: GitFlow needs four merges (feature to develop to release to main) plus a hotfix back-merge, while trunk-based needs one merge from a short-lived branch, followed by a tag and pipeline promotion

Branches are still there. Only their role changed. In GitFlow, the branch did four jobs at once: it isolated work, represented environments (dev/prod), stored versions, and hid unfinished features. The modern approach hands each of those four jobs to the tool that does it best. Isolation goes to the day-long PR branch, environments to the deployment pipeline, versions to tags, and hiding to flags.

Mapping of the four jobs a GitFlow branch used to do at once (isolating work, representing environments, storing versions, hiding features) to their trunk-based replacements: short-lived PR branches, pipeline stages, tags and releases, and feature flagsMapping of the four jobs a GitFlow branch used to do at once (isolating work, representing environments, storing versions, hiding features) to their trunk-based replacements: short-lived PR branches, pipeline stages, tags and releases, and feature flags

Control didn’t vanish either. It moved. GitFlow’s safeguards were largely team convention. “Back-merge your hotfixes.” “No new features after cutting release.” Rules nobody enforces. Trunk-based safeguards are machines: if tests are red, the merge button doesn’t work; without approval, the production deploy won’t run. There’s less for humans to remember, because the system does the blocking.

On a human team, this distinction amounted to “good habits.” With agents on board, it becomes the difference between surviving and not.

AI amplifies your branching strategy

The 2025 DORA report (State of AI-assisted Software Development) surveyed roughly 5,000 technology professionals and reached a conclusion that fits in one sentence: AI doesn’t fix your team. It amplifies what’s already there. Organizations with good systems get better with AI; organizations with broken systems break faster.

When the report named seven foundational capabilities that amplify AI’s impact, two of the seven slots went to version control: “strong version control practices” and “working in small batches.” Frequent commits amplify AI’s individual productivity gains, robust rollback capability lifts team performance when handling the volume of AI-generated code, and small batches boost AI’s contribution to product outcomes while reducing friction. An old conclusion from 2010s DevOps research got re-validated in the AI era. The direction held; the magnification grew.

From the agent’s perspective, the magnification grows for three structural reasons.

First, agents have no conventions. Birgitta Böckeler’s piece on harness engineering, published on Martin Fowler’s site, nails this point. A coding agent has no social accountability, no aesthetic revulsion at a 300-line function, no “that’s not how we do things here” intuition, no organizational memory. A prompt alone won’t fill that gap. What will is the harness — guides (steering up front) and sensors (verification after the fact): linters, tests, CI gates.

“Just write the conventions into AGENTS.md,” goes the obvious rebuttal. And yes, well-documented context does tend to improve agent output. But a key distinction remains: documented conventions are followed by agents probabilistically; CI gates are enforced deterministically. My own experience matched both halves of that. Even with the procedure written down and handed over, my agents would sometimes skip a detailed step — in a way that felt no different from a careless human at work. Write “back-merge hotfixes into develop” in a doc and it will mostly be followed. Mostly. That is a different grade of guarantee from a merge that is physically impossible while tests are red. GitFlow entrusts much of its safety to the former. Trunk-based puts it in the latter.

Second, agents need unambiguous signals. For an agent to self-correct, “am I currently succeeding or failing” must be crisp. With one main, there is one answer: is main green? With four branches, the answer becomes a combination of four. The confusion starts at the rebase: is the base develop or main? Which branch’s CI decides whether the commit you just pushed succeeded? If a hotfix went in, is the task done before or after the back-merge? Every task now carries these branching judgments, and an agent with no conventions will get some fraction of them wrong. And how is it supposed to judge a state where dev-frontend passes but breaks when combined with prod-backend? A structure that confuses humans is, to an agent, a broken traffic light. As the title says: that is where agents get lost.

Third, the volume is different. There are numbers on this now. Faros AI’s “AI Engineering Report 2026: The Acceleration Whiplash” analyzed two years of telemetry from 22,000 developers across 4,000+ teams, comparing each organization’s own lowest- and highest-AI-adoption periods. In the periods of heaviest AI use, organizational throughput genuinely rose: epics completed per developer up 66.2%. But in that same comparison, average PR size grew 51.3%, median time in PR review grew 441.5%, PRs merged without any review rose 31.3%, and incidents per PR more than tripled (+242.7%). Output exploded while the integration and verification path failed to keep pace — code piles up in front of the bottleneck, and some of it leaks through unverified. Faros calls the pattern “Acceleration Whiplash”: the injury that shows up after the sudden acceleration. DORA 2025 confirmed the same direction: AI raises throughput and deployment instability at the same time.

The carrying cost of long-lived branches — drift, conflicts — scales with the volume of change. Multiply the volume and you multiply the cost. That is why what was merely inconvenient in the human era becomes unmanageable in the agent era, and why trunk-based’s “short lifespans, frequent integration” wins: the time you spend deferring integration is now itself the most expensive resource.

In one line, for the executive summary: the payoff of adopting agents ultimately converts into “number of changes that reached deployment.” No matter how fast code is produced, if the road from merge to production is jammed, what piles up in front of the bottleneck isn’t output — it’s inventory.

The worktree-era misconception: it’s lifespan, not count

“But we run a worktree per agent — our branch count went up,” someone will object.

True. In 2026, the standard pattern for running multiple agents in parallel is one git worktree, one branch, per agent. As an isolation mechanism against file conflicts, nothing beats it. Count active branches and you’ll blow past trunk-based development’s “fewer than three” guideline easily.

But count was never the point. What trunk-based measures is lifespan and integration delay. A worktree branch lives a few hours. It takes one task, gets merged into main when done, and is deleted. It sits apart from main for so little time that drift never accumulates. It is the exact opposite of a GitFlow feature branch that survives for weeks, drifting further from develop the whole time. In practice, the playbooks of teams running parallel agents are converging on nearly the same shape: independent tasks split at the spec level, one worktree per task, quality gates that block merging, sequential integration, and a single main. Trunk-based’s short-lived branches simply started running in parallel.

One caveat: short branches do not guarantee small batches. As the telemetry above shows, agents left to themselves grow their PRs. Batch size can’t be fixed in the branching strategy. Humans have to enforce it at the task-splitting stage — spec decomposition. What the tools shorten for you is only the branch lifespan.

Of course, it isn’t free

Trunk-based has preconditions of its own — and the list is one item longer than it used to be.

Four things must come first: trustworthy CI, feature flags that separate deploy from release, a merge queue that keeps main green, and a fast review path. That last one is the new addition — and, as of 2026, the one collapsing hardest. As the review-time explosion above attests, the bottleneck has moved from merging to reviewing. Make branches ephemeral all you want; if they wait three days in a review queue, your integration delay is unchanged.

The Faros data has a more sobering line still: organizations with high DevOps maturity did not escape this downstream degradation either. Maintaining good pre-AI practices was not enough for them; review throughput itself has to be redesigned. Trunk-based in the agent era is only complete when it includes review-throughput design: review SLAs, agent pre-review to shrink the human review burden, and enforced batch-size limits.

Flaky tests — tests that occasionally fail for no reason — are at their worst when they meet agents. A human shrugs, “oh, that one just flakes sometimes.” An agent takes the signal seriously and either retries forever or “fixes” the test. There’s a real-world case: GitHub co-founder Scott Chacon, in his retrospective on Grit — a project using agents to rewrite Git in Rust — wrote that one of his parallel agents broke a fundamental part of the test harness, and it looked like such a massive regression that he nearly abandoned the project midway. The cause was uncoordinated parallel writes. When the signaling system breaks, the entire agent-parallelization scheme collapses with it.

DORA’s caveat deserves an honest airing too. In recent years, research on trunk-based development in isolation has produced mixed results: it helps development performance but has been observed to increase burnout, which is why DORA doesn’t prescribe it as a cure-all. The rhythm of frequent integration is also a pressure that keeps pushing people toward a perpetually “mergeable state.” This caveat weighs differently in the agent era, though. As the fiddly labor of integration — rebasing, conflict resolution, CI retries — becomes something you can hand to agents, the share of trunk-based’s cost structure paid by humans is shrinking. That doesn’t mean the burnout factor is gone, but the cost-benefit scale is clearly tipping further toward trunk.

There are exceptions, too. Mobile apps waiting on app-store review, libraries with long multi-version support windows, and regulated industries with per-release audits are right to cut short-lived release branches from main as needed. That is precisely the territory Driessen’s reflection note reserved for GitFlow.

Nobody ever got promoted for changing the branching strategy

So nobody changes it. Fundamentals like branching strategy are absorbed early in a career as “the way the team does it,” and after that there’s never an occasion to revisit them. It works, after all. And there’s no incentive: fix the branching strategy and nothing shows up in your performance metrics; break something while changing it and the blame lands on whoever proposed it. The status quo is always the individually rational choice. But “it works” and “it’s optimal” are different claims. Fundamentals get an exemption from scrutiny merely by working. Which is why it’s so common to see an organization that swaps frameworks every quarter still running the same git workflow it had ten years ago.

Agents end that exemption. If AI is an amplifier, the branching strategy is the first circuit wired into it. An agent on trunk becomes throughput; an agent on long-lived branches becomes a review queue and merge-conflict hell. Same model, same prompts. The difference comes from the integration structure underneath.

Want to check? Five minutes, today. Open the repo and count how many unmerged branches exist and how old the oldest one is. That number is the total integration your team has deferred — the principal that will multiply the moment you plug in agents. Then ask yourself one more thing: when did your team last revisit its branching strategy? The answer is probably “never.”

If you decide to change, you don’t have to jump in one leap. Four branches? Go to two first. Once CI and flags are in place, go to one. Shrink your branch count exactly as fast as your harness matures.

GitFlow versus trunk is, in the end, secondary. What matters is the habit of periodically re-examining the things too basic for anyone to examine. Fundamentals have an expiry date. Just know that this particular re-examination accrues interest the longer you defer it. The amplifier is already on.

References

Comments

Loading comments…