Proposal

Git-AI-Flow

A branching model for the AI orchestration era. Same shape as Git-Flow. Different roles.

Why a new flow is needed

Both Git-Flow and GitHub-Flow were designed around a pace that human developers can sustain — humans write the code, humans review every PR, and the system as a whole moves only as fast as humans can keep up. In the AI orchestration era, that pace is no longer the binding constraint. An autonomous agent can open ten PRs while a human is at lunch.

Git-AI-Flow introduces a buffer between AI velocity and human oversight: the agents work on a long-lived ai-develop branch, and humans promote selected states into main on their own schedule.

The shape

Two persistent branches: main (human-approved, production-ready) and ai-develop (agent-managed, continuously updated). Short-lived feature/* branches are forked from ai-develop. Humans review ai-develop on a cadence and promote a chosen state into main.

main          ●─────────●──────────●─────────●  (human-promoted)
                       ▲          ▲
                       │ promote  │ promote
ai-develop    ●─●─●─●─●●─●─●─●─●─●●─●─●─●  (agent-driven)
                  ▲       ▲       ▲       ▲
                  agent   agent   agent   agent

What flows on ai-develop is not raw prompts — it is GitHub issues compiled from the intent tree. Each issue inherits the relevant slice (architecture, contracts, UI patterns), so writing a clear issue (the highest-leverage skill in modern AI-assisted coding) actually pays off: implementation by an agent is straightforward because the context is already there, and the human review at promotion time compares the PR to the intent slice rather than to personal taste.

Promotion path: from ai-develop to main

On a large or already-released codebase the path looks like this. The agent works on ai-develop. At any chosen point, an AI reviewer reads across the implementation, the issue, and the intent tree at the same time and judges whether the change honors the intent. Once that review passes and a human gives the final approval, the chosen state of ai-develop is merged into main. main stays human-approved and production-ready by construction; ai-develop carries the agent-paced churn.

Bug reports become Intent-Bug issues

Reality returns signals after release: defects, edge cases, surprising behaviors. Each one is filed as an Intent-Bug issue and routed back into the same loop. The triage step asks the question the Intent Tree page already names — is this an implementation bug (intent was right, code did not honor it) or an intent gap (intent said nothing; the implementer made a local choice; the result was not what the team wanted)? Implementation bugs are fixed by an agent on ai-develop, reviewed against the unchanged intent slice, and promoted. Intent gaps first promote the tree (clarification → canonical), and the corrected intent then drives the fix. Either way, the bug enters the same agent-led fix loop and exits via the same human-approved promotion to main.

bug report (from production)
   │
   ▼
Intent-Bug issue                filed in the implementation repo
   │
   ▼
triage on the intent tree
   │     ┌─────────────────────────────┐
   ├─────▶ implementation bug — fix on ai-develop
   │     │
   └─────▶ intent gap — promote the tree first, then fix
              │
              ▼
        ai-develop (agent fix loop)
              │
              ▼
        AI review across impl + issue + intent tree
              │
              ▼
        human final approval → promote to main

Comparison with prior flows

Aspect	Git-Flow	GitHub-Flow	Git-AI-Flow
Long-lived branches	main + develop	main	main + ai-develop
Who works on develop	humans	n/a	agents
Release cadence	scheduled releases	continuous deployment	human-gated promotion
Reviewer	humans on each PR	humans on each PR	agents on ai-develop; humans on promotion
Bottleneck	release coordination	reviewer availability	promotion frequency

When NOT to use Git-AI-Flow

AI is used only as autocomplete (Copilot-style); humans author every PR.
The team is already happy with trunk-based development.
Single developer reviewing their own PRs as they write them.

Notation

Standardize on Git-AI-Flow (capitalized, three words, hyphenated) in titles and prose. In code or commands, lowercase git-ai-flow is acceptable. The recommended branch name is ai-develop, but free to use what your organization prefers — what matters is the role separation, not the name.