Skip to content
KoishiAI
ไทย
← Contents

Chapter 11 of 12 · Agentic Engineering — A Practitioner Playbook for Production Software with AI Agents

Git for a Team Where Everyone Has an AI

When code per person rises three to ten times but review capacity does not, the bottleneck moves from writing to reviewing and merging. Six core rules, a commit trailer recording provenance, a PR template that requires a blast radius, and CI in four layers.

What changes when everyone has an agent: code produced per person rises three to tenfold while the team’s review capacity stays the same. The bottleneck moves from writing to reviewing and merging. Every rule in this chapter exists to stop that bottleneck exploding.

11.1 Six core rules

RuleReason, and how to enforce it
PRs stay smallA 400-changed-line ceiling, with CI warning past it — an agent can produce a 2,000-line PR in twenty minutes, and nobody genuinely reviews that
One PR, one intentNo mixing refactors with features. Agents love “while I am here, let me improve this too”. Forbid it in AGENTS.md
A human owns every PROne person is fully accountable, even if the agent wrote every line. No ownerless PRs
Short-lived branchesTwo days maximum. Agents move fast, and a week-old branch conflicts badly
CI is the same gate as localRun the same verify.sh. Never two standards
Rebase first, alwaysPull main before each new round of agent work, not when opening the PR

11.2 Recording provenance

The team needs to know which code a person wrote, which an agent wrote, and how thoroughly a human checked it — because the level of review should differ. The approach that works without friction is a commit trailer.

feat(checkout): add coupon validation and discount calculation

Implements R1-R6 from docs/specs/coupon.md
Discount applied before tax, clamped at 0 per R4

AI-Assisted: heavy          # none | light | heavy | autonomous
AI-Tool: claude-code
Human-Review: full          # full | tests-only | spot
Spec: docs/specs/coupon.md
Gate: verify.sh green (run 2026-08-04T09:12Z, 47 tests, cov 84%)
Co-Authored-By: Claude <noreply@anthropic.com>
LevelMeaningReview required
noneEntirely human-writtenNormal review
lightAI filled in code, a human shaped the structureNormal review
heavyAI wrote the bulk, a human directed and checked all of itRead every line of the tests, plus a blast-radius check
autonomousAI worked in a loop, a human saw only the resultRequires a second reviewer, and may not touch paths handling money or user data

A PR template with required fields:

## What changed and why

## Spec
- Link: docs/specs/____.md
- Rules implemented: R__ through R__

## Gate

paste the real output of ./scripts/verify.sh here


## AI provenance
- AI-Assisted: [ ] none [ ] light [ ] heavy [ ] autonomous
- Tool: ______
- What a human wrote or corrected: ______

## Blast radius (required; do not skip)
- If this fails in the worst way, affected users: ______ people / ______ %
- Harm level: [ ] L1 [ ] L2 [ ] L3 [ ] L4 [ ] L5
- Detected within ____ minutes, by: ______
- Rollback: [ ] disable feature flag [ ] revert commit [ ] requires a reverse migration
  Time needed: ____ minutes

## What the reviewer should look at most closely (by risk)
1.
2.
3.

## Checklist
- [ ] Tests written from the spec, not from the implementation
- [ ] Every rejection case from the spec is covered
- [ ] No out-of-scope files touched
- [ ] No new dependencies (if there are, explain why)
- [ ] Migration is reversible and locks no table for more than two seconds
- [ ] memory/pitfalls.md updated if something new was learned

11.3 Dividing work to reduce conflicts

When three people direct agents simultaneously, conflicts become far more likely, because each agent tends to “improve the neighbouring file” as well. What works is declaring each task’s file scope in advance, and forbidding the agent from touching anything outside it.

11.4 Handling conflicts

When a conflict happens, run the tests from both sides, not just the current set.

git checkout theirs-branch -- tests/      # bring their tests across too
./scripts/verify.sh

And never let the agent use git checkout --ours or --theirs wholesale. That is how code disappears silently with no test catching it. Put it in the hook’s prohibition list.

11.5 CI that copes with the increased PR volume

Layer 1 — fast (<2 min), on every push
  format, lint, types, unit tests for touched files
  Result: blocks immediately

Layer 2 — full (<10 min), on PR open and every subsequent push
  the whole verify.sh plus the no-cheating check
  Result: blocks the merge

Layer 3 — quality (non-blocking), posted as a comment
  coverage diff, complexity delta, PR size, new dependencies,
  files touched outside the declared scope,
  an LLM report of "things worth a closer look" (advisory only, cannot block)

Layer 4 — nightly
  full E2E, mutation testing over the day's diff,
  security scan, a summary of which tests are flaky

The iron rule

Never leave a randomly failing test in a gate that blocks merges. The team learns to press re-run until it is green, and the entire gate loses its meaning. The moment a flaky test appears, remove it from the gate and open an issue — do not leave it there.

11.6 Handing work between people

When two people work in sequence, what must be handed over is not just the code but the context the other person’s agent will need — because their agent has none of your chat history.

What must be in the repository before handing over, not in Slack:

FileContent
docs/specs/xxx.mdThe spec, updated to match what was actually built
memory/decisions.mdWhat was decided along the way, and why
memory/pitfalls.mdWhat was tried and did not work, so the next person does not repeat it
PR descriptionBlast radius, rollback, what remains outstanding
TODOs in codeAlways naming a person or an issue. Never an orphan TODO

Test whether the handover is complete with one question:

“If a teammate opens this repo tomorrow morning and tells their agent ‘continue this work’, without asking me anything at all — will they get it right?”

If the answer is no, context is still sitting in your head or in a chat, and needs to move into a file.

A health metric for the team

Teams doing agentic engineering well see this pattern: the average time from PR opened to merged falls, while the rollback rate does not rise. If the time falls and rollbacks rise, you are not gaining productivity — you are moving the cost onto your users.

What this chapter settles

The bottleneck is review, so every rule aims at keeping review genuinely possible: small PRs, one intent each, short branches, and always a human owner. Record provenance in a trailer so the level of review matches the risk. Split CI into four layers by speed. And measure the team’s health by time-to-merge alongside the rollback rate.

The next chapter is the appendix: checklists and the twelve anti-patterns that come up most.