# Your Git workflow probably doesn't need to change for AI

> Source: <https://dev.to/krlz/your-git-workflow-probably-doesnt-need-to-change-for-ai-121c>
> Published: 2026-09-25 12:50:31+00:00

A peer-reviewed study presented at EASE 2026 looked at 33,596 pull requests authored by AI agents in GitHub repositories with at least 100 stars. It found that **61.38% received no recorded review activity at all**. Widen the lens to include PRs reviewed only by other bots, and the number reaches 84%.

That is the actual problem worth solving. Not whether you should migrate to trunk-based development because you started using Copilot.

I spent a while researching what changes about Git when AI writes the code, half-expecting to find that some new branching model had emerged. It hasn't. What I found instead is that the interesting question moved somewhere else — and most of the advice circulating right now is answering the old one.

"Git Flow or trunk-based for AI?" is a 2015 question wearing a 2026 costume. It asks how long a branch should live.

Meanwhile every major agent vendor — Copilot, Cursor, Devin, Jules, Claude Code — independently converged on the same shape without coordinating:

```
task → branch → pull request → human handoff
```

That's it. That's GitHub Flow, which predates all of them. The convergence happened because it's the only shape that fits an agent's unit of work: one task, one sandbox, one handoff point. GitHub's own documentation describes the Copilot agent workflow in exactly these terms — the agent opens a PR and adds you as a reviewer, and you're told to "review the code changes yourself, just as you would for any contributor's pull request."

Nobody invented `agent/` as a new branch *type*. They invented it as a naming prefix.

Here's the shift in one line. **An agent can produce a plausible 400-line diff in ninety seconds. A human still needs twenty minutes to review it properly.** Every consequence follows from that asymmetry.

The telemetry backs this up. Across industry measurements in 2026:

| Metric | Change | 
|---|---|
| Median PR size | +51% | 
| Median time in review | +441% | 
| Agentic PR wait for reviewer pickup | 5.3x longer (1,055 min vs 201) | 
| Reported incidents per PR | +243% | 

LinearB analyzed 8.1 million PRs across 4,800+ organizations and found developers *felt* 20% faster while measuring 19% slower. More tasks completed, 98% more PRs merged — and review time up 91%.

None of those numbers are a branching problem. You cannot fix a verification bottleneck by renaming your branches.

Back to the EASE 2026 study, because its second result is sharper than the first.

The researchers compared agent-authored and human-authored PRs *within the same repositories*, then classified what humans actually wrote in review comments. The categories: genuine review feedback, agent-steering commands (`@coderabbit fix the lint failure`), and CI chatter.

| Human comment type | On agent PRs | On human PRs | 
|---|---|---|
| Genuine review content | 65.5% | 93.6% | 
| Agent-steering commands | **25.9%** | 1.6% | 

Chi-square 1280, p < 0.001, Cramér's V = 0.34 — a large effect, not noise.

When a human engages with an agent's pull request, a quarter of the time they aren't reviewing it. They're operating it. The role is drifting from evaluator to dispatcher.

The authors are careful here, and so am I: absence of recorded comments doesn't prove absence of oversight. A maintainer can read a diff carefully and merge without typing anything. The study measures observable interaction, not attention. But it's the only signal your process can actually audit.

Trunk-based development genuinely fits agent work well. Short-lived branches mean no divergence; an agent produces a complete change in minutes, so there's no reason it should sit on a branch for a week. Each change stays independently revertible.

But notice *why* it helps. DORA's 2025 report — 90% AI adoption among respondents, median two hours of daily AI interaction — found that AI now correlates positively with delivery throughput, with an explicit condition: **the benefit depends on teams working in small batches.**

Trunk-based doesn't win because it's a superior branching model. It wins because it *forces* small batches, and small batch size is the variable that gates whether AI helps or hurts. Two of DORA's seven amplifying capabilities are version control practices and small batches. The branching scheme is downstream of both.

Which means you can get the benefit without the migration. A 200-line cap in CI does the same work.

And trunk-based isn't free:

`develop` still earns its place
If your team runs `feature/* → develop → main`, the AI-era advice to flatten it is weaker than it sounds.

The empirical comparison work here (arXiv 2507.08943, interview-and-survey based) concludes that trunk-based suits "fast-paced projects with experienced and smaller teams" while branch-based approaches fit "less experienced and larger teams." AI doesn't appear in that paper's findings at all — and I think that's the honest answer. It didn't settle the question.

Two practical notes if you keep `develop`:

**Agents can target it now.** The old limitation where Copilot's coding agent could only branch from the repository default was lifted in July 2025 — you can select a base branch when delegating a task. Git Flow is no longer disqualified by tooling.

**You're not an outlier.** The npm package `agents-gitflow-guard` — a branch-role guard that blocks agents from pushing directly to protected branches — ships `develop` + `main` as its *zero-config default*, and pulls ~7,500 downloads a month. The ecosystem assumes your shape.

Keep `develop` if it's where you actually integrate and test before release. Drop it if it's ceremony nobody uses. That decision was never about AI.

If you change one thing, don't change your branch names. Change where the quality gate sits.

Reviewing diffs doesn't scale, because diff review costs human attention in proportion to volume — and volume is now set by a machine. The teams holding quality under agent load moved the gate off the diff:

**Earlier — review the plan, not the patch.** Have the agent write a short spec before it writes code. A 200-line plan review catches an architectural mistake at a fraction of what the same catch costs in a 2,000-line diff, and it catches it before the work exists.

**Harder — cap the batch mechanically.** A CI check that fails PRs over ~200-500 changed lines. Not a convention, a gate. This forces decomposition, which produces reviewable units *and* better agent output, since a tighter task means a tighter context.

**Layered — let machines do the first pass.** GitHub's internal data on the "review sandwich" pattern (automated review first, humans on architecture and business logic) reports a 30-50% reduction in human review time.

One caveat on that last one, straight from GitHub's docs: **Copilot leaves a "Comment" review by default, not an "Approve" review**, and comment reviews don't satisfy required-approval rules. That default is correct. Approvals *are* now configurable at enterprise, org, and repo level — which means someone on your team can turn the human gate off with a settings toggle. Know whether yours is on.

And the highest-leverage habit, which barely anyone does: **when an agent makes the same mistake twice, fix the generator, not the diff.** Correct the spec, the prompt, the `CLAUDE.md`, the skill. Fixing a diff fixes one PR. Fixing the generator fixes every future one.

A few things the research doesn't settle, and I'd rather name them than paper over them:

One thing I'm confident about: record provenance now. A `Co-Authored-By` trailer naming the model costs nothing today and is impossible to reconstruct later.

```
git log --grep="Co-Authored-By: Claude" --oneline | wc -l
```

That command is how you answer, six months from now, "which code was agent-authored, and did it fail more often?" Without the trailer, that question has no answer — and it's exactly the question an incident review will ask.

Your branching model is probably fine. One task, one branch, one pull request still works, and every agent vendor agrees because they all built for it.

What's worth your attention is that human review is measurably thinning out while PR volume climbs, and most teams haven't noticed because their metrics still say "reviewed."

So the question I'd put to you, if you're running agents in a real codebase: **do you know what fraction of your merged agent PRs a human actually read?** Not approved — read. I suspect most teams can't answer that, and I'd genuinely like to hear from anyone who can.

*Sources: [DORA 2025 State of AI-Assisted Software Development](https://dora.dev/dora-report-2025/) · Duma et al., ["These Aren't the Reviews You're Looking For", EASE 2026](https://arxiv.org/abs/2605.02273) · [Choosing the Right Git Workflow (arXiv 2507.08943)](https://arxiv.org/abs/2507.08943) · [GitHub Docs: Copilot code review](https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/copilot-code-review) · [GitHub Changelog: base branch for coding agent](https://github.blog/changelog/2025-07-23-agents-page-set-the-base-branch-for-github-copilot-coding-agent-tasks/) · [GitHub Docs: Stack AI-generated code in pull requests](https://docs.github.com/en/copilot/tutorials/stack-ai-generated-code-in-pull-requests)*