AI coding assistants have made code production roughly ten times faster. Yet most teams’ Git workflows still assume code is written by humans.
This assumption is subtle, but it shapes how we commit, review, and branch. It presumes that:
- A commit should be small enough for one person to digest in a focused session;
- The point of a PR review is to check whether the author wrote the code correctly;
- Branches exist to give humans parallel workspaces.
When a few hundred lines of changes can spring from a prompt in minutes, those assumptions start to crack. The question is no longer “Will AI replace programmers?” but rather: If the “author” of a piece of code has shifted from “a person” to “a person plus AI,” what should version control record, verify, and protect?
This article is not about “how to use Git more efficiently.” It is about three underlying shifts the AI era forces on Git workflow:
- What should determine commit granularity?
- What is a PR review actually reviewing?
- What should branch strategy even look like?
1. First, Unpack the Hidden Assumption: Git Records Changes, Not Authorship
Git’s commit model is simple: it records who changed which files, when, and how. It does not care whether those changes came from a keyboard, a script, or a large language model. That used to be fine, because almost all changes did come from keyboards.
AI coding assistants make provenance matter again. The same 300-line diff could result from many very different production paths:
- A human designs the structure, AI fills in the implementation;
- A human describes the requirement, AI generates everything at once;
- AI produces a first draft, a human edits line by line;
- A human pastes AI output with barely a glance;
- AI, in agent mode, touches a dozen files automatically.
Git’s diff looks almost identical in each case. But the risk profile is completely different.
When we say “code is written by a human,” we implicitly guarantee that the author has read every line they committed. That guarantee no longer holds. With AI-generated code, the author may have read only 30% of it, or perhaps only the summary. Git has no built-in format for this “semi-reading author,” but a team’s workflow must be redesigned for this new production relationship.
This is not as simple as slapping an “AI-generated” label on a commit. The real question is: Once the “author has read it” premise collapses, what new verification step must the Git workflow add?
2. Commit Granularity: From “What a Human Can Digest” to “What a Human Can Verify”
The conventional advice is to keep commits small, atomic, and frequent. The reasoning is solid: small commits are easier to review, easier to revert, and easier to bisect.
But AI amplifies and distorts this advice at the same time.
2.1 AI Makes Big Commits Dangerously Easy
A common trap is telling the AI, “Implement the user authentication module for me,” watching it touch a dozen files, and then casually running git add . && git commit -m "add auth". Such a commit may bundle routing, models, controllers, frontend components, tests, and config changes together.
The problem is not the commit’s size; it is the coupling of unrelated kinds of changes. When something breaks in production, you cannot easily tell whether the bug is in the routing, the model constraints, or the missing edge-case tests. Reverting becomes blunt: either roll everything back or live with the risk.
AI will not absorb this coupling cost for you. On the contrary, it is especially good at producing changes that look cohesive but are actually a mishmash.
2.2 The New Unit of Granularity: An Intentional, Verifiable Loop
In the AI era, the right unit for commit granularity is no longer “how many files” or “how many lines,” but a verifiable intention loop.
A verifiable intention loop means:
- The commit solves one clear problem or completes one clear step;
- The commit can be confirmed correct through automated tests or minimal manual verification;
- Reverting the commit will not break unrelated functionality.
This resembles the classic atomic commit, but the emphasis is different. Traditional advice focuses on “small”; the AI-era version focuses on “verifiable.” AI can generate 500 lines at once, and if all 500 lines serve a single verifiable intention and pass tests, that is still a good commit.
Conversely, if 50 AI-generated lines mix three different intentions, that commit is still too large.
2.3 Practical Pattern: Generate → Review → Reorganize into Commits
A workable three-stage pattern:
Stage 1: Let AI generate in an isolated workspace.
Do not let AI directly modify the branch you are developing on. Have it output to a temporary branch or a patch file, so you can read the result before deciding how to integrate it.
Stage 2: Regroup changes by intention.
After reading the AI’s output, do not commit it as a lump. Split the changes into separate commits by intention:
refactor: extract shared utilities first;feat: add the new interface next;test: add boundary tests next;chore: update config or docs last.
This step cannot be delegated to AI, because it requires human judgment about business intent.
Stage 3: Attach verification evidence to each commit.
Not every commit needs a test, but every commit needs a verifiable claim. That could be a minimal reproduction step, a unit test, a screenshot, or simply a clear commit message explaining how this step would fail if it were wrong.
3. PR Review: From “Did You Write It Correctly?” to “Did You Verify It Correctly?”
This is the deepest change AI forces on Git workflow.
The traditional PR review asks: “Is your code correct?” The reviewer checks logic, naming, edge cases, performance, and style. It assumes the reviewer is at least as knowledgeable as the author and can catch things the author missed.
AI changes that dynamic.
3.1 The Reviewer Is Unlikely to Understand AI-Generated Code Better Than AI
When code is written by AI, the reviewer faces a strange situation: they may never have seen this implementation approach before, and they do not know why AI chose it. They certainly cannot read more related documentation than AI did in the time available.
In this context, asking the reviewer to “check every line for correctness” is inefficient and often performative.
3.2 The New Core Question: “What Did You Verify, and How?”
AI-era PR review should shift from code review to verification review. The reviewer does not need to re-read every line. They need to confirm that the author has done enough verification:
- What is the acceptance criteria for this change?
- Which tests did you run? Is there a minimal reproduction?
- For the AI-generated parts, which boundaries did you manually spot-check?
- If the AI hallucinated here, what is your safety net?
- What is the rollback path for this change?
In other words, the reviewer’s attention moves from “the code itself” to “the verification chain behind the code.”
3.3 The PR Description Matters More Than the Code
In the AI era, the PR description is no longer a polite explainer; it is the main object of review. A good PR description should answer:
- Intent: What problem does this change solve?
- AI involvement: Which files or functions were AI-generated? Which were human-edited?
- Verification checklist: What has the author already checked?
- Risk points: What is AI most likely to get wrong here, and how did you rule it out?
- Rollback strategy: If this goes wrong, can this PR be safely reverted on its own?
If the PR description cannot answer these, the reviewer should reject it outright rather than struggling through the code.
3.4 Large AI-Generated Changes Should Be Split, Not Reviewed in Bulk
If a PR contains 2,000 lines of AI-generated code, it should not be merged, even if the quality looks good. The problem is not laziness; it is that humans cannot build trust in such a large change in a single review session.
Break AI-generated features into a chain of dependency-clear sub-PRs:
- PR 1: interface definitions and data structures;
- PR 2: core implementation;
- PR 3: tests and documentation;
- PR 4: configuration and deployment changes.
Each PR can be verified independently, and the reviewer can build trust layer by layer.
4. Branch Strategy: Long-Lived Feature Branches Are Becoming Liabilities
The original purpose of branching was to isolate humans working in parallel. Everyone develops on their own feature branch, then merges back to main. This reduces conflict frequency and gives each person a stable workspace.
AI makes this pattern dangerous.
4.1 The Faster AI Generates, The Faster Feature Branches Rot
A feature branch that lives for one day is low-risk. But if AI can generate a week’s worth of work in a day, then a three-day feature branch may contain a month’s worth of code by old standards. The longer the branch lives, the larger the divergence from main, and the more likely a merge will suffer from “implicit conflicts between AI-generated chunks”—not Git-level conflicts, but semantic conflicts.
Worse, AI-generated code often looks internally consistent because it was produced within a fixed context. Once merged with the latest main, older assumptions may no longer hold. This kind of bug is hard to catch at merge time.
4.2 Trunk-Based Development Gains New Relevance in the AI Era
Trunk-based development is not new, but it takes on new meaning in the AI era:
- Shorter feedback loops: code reaches main quickly and is covered by integration tests sooner;
- Reduced accumulation of AI hallucinations: the longer a branch lives, the more AI-generated layers can stack hallucinations on top of each other;
- Forced small-step verification: if every change must land in main quickly, teams are naturally pushed to split large features into smaller pieces.
Not every team can switch to trunk-based development immediately, but the principle is clear: AI-generated code should not sit in a branch for long.
4.3 The New Purpose of Branches: Isolating AI Experiments, Not Development
In the AI era, branches are more valuable as experiment isolation than as daily development isolation.
For example:
experiment/ai-refactor-auth: let AI try refactoring the auth module; regardless of success, only the verified parts are kept;ai-draft/feature-x: AI generates a draft, and the author reorganizes it into clean commits on another branch;prompt/v2-auth-prompt: record the output of a specific prompt for comparison with the next version.
Branches become sandboxes for AI experiments, not ownership boundaries for code.
5. Git Needs New Metadata: What Are We Actually Recording?
A Git commit today only records author, date, message, and diff. That is no longer enough in the AI era.
A more complete set of commit metadata would include:
| Metadata | Purpose |
| Human author | Who is accountable for this commit |
| AI tool | Which AI tool or model was used |
| Prompt summary | The core prompt that generated this code |
| Verification method | Tests, spot-checks, static analysis, runtime logs |
| Risk level | Share of AI changes, impact on critical paths |
| Rollback confidence | Whether reverting this commit alone is safe |
Git itself does not support all these fields, but they can be added through commit-message conventions, PR templates, CI labels, or external tools. The key is not the technical implementation; it is team agreement that code is no longer just “written by a human”—Git history needs to record how it was produced.
6. A Minimum Viable Workflow
If you only change one thing, start with this minimum workflow:
- AI does not commit directly. All AI output goes into a temporary branch or patch first; the author reads it before integrating.
- Reorganize commits by intention. Do not split by file size; split by one verifiable intention per commit.
- PR description includes a verification checklist. The reviewer checks how you verified before reading the code.
- Break large features into dependency chains. Do not review thousands of lines of AI-generated code in one go.
- Feature branches live no longer than 2–3 days. AI-generated code should not stay in a branch for long.
- Revert safety beats commit prettiness. Every commit must be independently reversible without breaking unrelated functionality.
7. Conclusion: The Essence of Git Workflow Has Not Changed, but What It Protects Has
The core mission of Git workflow has never changed: in collaborative work, keep code history understandable, verifiable, and reversible.
But in the AI era, “collaborators” include non-human ones. These collaborators write fast, never tire, and never complain, but they also hallucinate, omit things, and err at boundaries. They do not take responsibility; the humans who use them do.
So the new question Git workflow must answer is this: When code is produced far faster than any human can read it, what mechanism ensures that the code merged into main remains accountable, auditable, and reversible?
The answer is neither banning AI nor blindly trusting it. It is upgrading the workflow from “recording code written by humans” to “recording code verified by humans.”
A commit is no longer just “what I changed,” but “what I verified.” A PR review is no longer just “did you write it correctly?” but “did you verify it correctly?” A branch is no longer just “my development space,” but “a sandbox for AI experiments.”
This shift is the inevitable path for software engineering in the AI era: from individual craft to auditable production.
Leave a Reply