A peer-reviewed study presented at EASE 2026 examined 33,596 pull requests created by AI agents in GitHub repositories with at least 100 stars. It found that 61.38% had no recorded review activity. If you include pull requests reviewed only by bots, that number reaches 84%.
That does not prove nobody read the code. A maintainer can inspect a diff carefully and merge it without leaving a comment. But recorded activity is the only oversight a team can audit later, and right now that record is disappearing.
This is the Git problem worth solving for AI. It is not whether your team should replace Git Flow with trunk-based development because it started using Copilot.
I started researching what changes about Git when AI writes the code, expecting to find a new branching model. I did not find one. The more important change is simpler: generating code became cheap, while verifying it did not.
The branching question is mostly a distraction
“Git Flow or trunk-based for AI?” is an old question with a new label. It asks how long a branch should live.
Most coding agents have converged on a familiar workflow:
task → branch → pull request → human handoff
That is essentially GitHub Flow. It already fits an agent's natural unit of work: one task, one isolated workspace and one handoff point.
GitHub describes Copilot's coding-agent workflow in similar terms. The agent opens a pull request, assigns a reviewer and expects the code to be reviewed like a contribution from any other developer.
The agent/ prefix may be new. The workflow is not.
Code generation got faster. Review did not
An agent can produce a plausible 400-line change in a few minutes. A human may still need twenty minutes—or much longer—to understand whether it is correct.
Recent industry measurements show the same pattern:
| Metric | Reported change |
|---|---|
| Median PR size | +51% |
| Median time in review | +441% |
| Agentic PR wait for reviewer pickup | 5.3× longer |
| Reported incidents per PR | +243% |
LinearB analyzed 8.1 million pull requests across more than 4,800 organizations. Developers felt 20% faster, but measured delivery performance was 19% slower. Teams completed more tasks and merged 98% more pull requests, while review time increased by 91%.
These numbers do not describe a branching failure. They describe a verification bottleneck. Renaming branches does not reduce the amount of code a person must understand.
“Reviewed” may no longer mean reviewed
The EASE 2026 study also compared agent-authored and human-authored pull requests within the same repositories. Researchers classified human comments as genuine review, instructions directed at an agent, or CI-related activity.
| Human comment type | Agent PRs | Human PRs |
|---|---|---|
| Genuine review content | 65.5% | 93.6% |
| Agent-steering commands | 25.9% | 1.6% |
When humans interacted with an agent's pull request, roughly a quarter of their comments were instructions such as asking the agent to fix a failure. They were operating the agent rather than evaluating the change.
This matters for engineering metrics, incident analysis and compliance. A dashboard can say that a pull request was reviewed without showing whether the interaction was a real evaluation, an agent command or an automated comment.
Should you switch to trunk-based development?
Trunk-based development fits agent work well. Short-lived branches reduce divergence, and small changes are easier to test, review and revert.
DORA's 2025 report found that the benefits of AI depend partly on teams working in small batches. Trunk-based development often encourages that behaviour, but it is not the only way to achieve it.
You can keep Git Flow and still require small, independently reviewable changes. You can also use trunk-based development badly by allowing agents to open enormous pull requests.
Trunk-based development also has costs:
- It works best with a fast and reliable test suite.
- It often depends on feature flags, which require ownership and cleanup.
- Adoption may initially slow delivery while teams improve their automation and release practices.
So the decision should still depend on the team, release process and maturity of the test suite—not on whether the code was written with AI.
Where develop still earns its place
If your team uses feature/* → develop → main, AI is not a reason by itself to remove develop.
Keep it when it is a real integration environment where changes are tested together before release. Remove it when it only adds waiting time and nobody uses it to discover integration problems.
Modern coding agents can work with either model. Copilot's coding agent, for example, can now use a selected base branch instead of only the repository's default branch.
The useful question is not “Is develop outdated?” It is “What risk does this branch control, and is it actually controlling it?”
A workflow you can adopt now
You probably do not need new branch names. You need clearer gates between an agent receiving a task and its code reaching production.
1. Review the plan before the patch
Ask the agent for a short implementation plan before it writes code. The plan should explain:
- which files, services and data are affected
- API or schema changes
- migration and rollback steps
- tests that will be added
- risks and assumptions
Keep the plan in the issue or pull-request description. Repository instructions such as CLAUDE.md or .github/copilot-instructions.md can make this a default part of the workflow.
It is much cheaper to reject a bad approach before it becomes a large diff.
2. Keep changes reviewable
Use GitHub Actions, Danger JS or a PR-size action to label large changes and require an explanation when they cross an agreed threshold.
A hard line limit will not fit every repository. Generated files, lockfiles and migrations can distort the number. The goal is not to worship a 200-line rule; it is to make large changes exceptional and intentional.
When possible, split work into small pull requests that can be tested and reverted independently. GitHub also documents a stacked pull-request workflow for AI-generated changes.
3. Automate the mechanical review
Run automated checks before asking for human attention:
- CodeQL or Semgrep for static analysis
- SonarQube or SonarCloud for maintainability rules
- Gitleaks for secrets
- Dependabot or Renovate for dependency changes
- Snyk or Trivy for dependency and container vulnerabilities
- Playwright, Pact or integration tests for behaviour across boundaries
AI review tools such as GitHub Copilot code review, CodeRabbit, Qodo Merge or Greptile can provide another first pass.
These tools are useful for finding common problems. They should not own the final decision. Humans still need to evaluate architecture, product behaviour, security assumptions and failure modes.
4. Protect the merge
Use GitHub rulesets, protected branches, required status checks and CODEOWNERS to make ownership explicit.
For sensitive areas, require approval from the team that owns the code. Do not allow a bot comment or an agent-generated fix to satisfy the same rule as a human approval.
GitHub Copilot code review leaves a comment review by default rather than an approval. That default is sensible. If AI approvals are configurable in your organization, verify that changing the setting cannot silently remove the human gate.
5. Record AI involvement
Add a pull-request label, metadata field or commit trailer that records which agent was involved. Link the task, plan and relevant session transcript from the pull request.
For example:
Co-Authored-By: Claude <noreply@anthropic.com>
This gives you enough information to ask useful questions later:
- Do agent-assisted changes fail more often?
- Which repositories need more review?
- Which instructions repeatedly produce the same mistakes?
- Does AI reduce lead time after review and rework are included?
GitHub's API can provide the raw data. Engineering analytics platforms such as LinearB, Swarmia or Jellyfish can help track change size, review time, rework and deployment outcomes.
6. Fix the generator when mistakes repeat
When an agent makes the same mistake twice, do not only repair the current diff. Update the issue template, prompt, repository instructions, examples or agent skill that produced it.
Fixing a diff improves one pull request. Fixing the generator improves the next hundred.
The resulting workflow is deliberately boring:
task → plan → small change → automated checks → human review → merge
That is a feature. Good delivery systems make ownership obvious.
What is still unresolved
There are questions the current research does not answer:
- If review counts no longer measure oversight, what should replace them? Time spent on a page would be easy to game, and comments are an incomplete signal.
- What happens at full autonomy? Every workflow above assumes a human remains in the merge path. At dozens of agent pull requests per day, that assumption may stop working.
- What is the right commit granularity? An agent session may contain forty steps, but forty commits are rarely useful. I currently prefer squashing into logical units while keeping the session history separately.
These are more important questions than whether an agent branch should start with feature/ or agent/.
The takeaway
Your current branching model is probably fine. One task, one branch and one pull request still works.
What changed is the pressure placed on the review system. AI can produce code faster than humans can verify it, while existing dashboards may still report that everything was “reviewed.”
Before changing Git Flow, strengthen the path to merge: review the plan, keep changes small, automate mechanical checks, require clear ownership and record where AI was involved.
Then ask the uncomfortable question:
Do you know what fraction of your merged agent pull requests a human actually read—not merely approved?
I suspect most teams cannot answer that yet. I would genuinely like to hear from anyone who can.
Sources: DORA 2025 State of AI-Assisted Software Development · Duma et al., “These Aren't the Reviews You're Looking For,” EASE 2026 · Choosing the Right Git Workflow (arXiv 2507.08943) · GitHub Docs: Copilot code review · GitHub Changelog: base branch for coding agent · GitHub Docs: Stack AI-generated code in pull requests
Top comments (0)