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
| Rule | Reason, and how to enforce it |
|---|---|
| PRs stay small | A 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 intent | No mixing refactors with features. Agents love “while I am here, let me improve this too”. Forbid it in AGENTS.md |
| A human owns every PR | One person is fully accountable, even if the agent wrote every line. No ownerless PRs |
| Short-lived branches | Two days maximum. Agents move fast, and a week-old branch conflicts badly |
| CI is the same gate as local | Run the same verify.sh. Never two standards |
| Rebase first, always | Pull 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>
| Level | Meaning | Review required |
|---|---|---|
| none | Entirely human-written | Normal review |
| light | AI filled in code, a human shaped the structure | Normal review |
| heavy | AI wrote the bulk, a human directed and checked all of it | Read every line of the tests, plus a blast-radius check |
| autonomous | AI worked in a loop, a human saw only the result | Requires 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:
| File | Content |
|---|---|
docs/specs/xxx.md | The spec, updated to match what was actually built |
memory/decisions.md | What was decided along the way, and why |
memory/pitfalls.md | What was tried and did not work, so the next person does not repeat it |
| PR description | Blast radius, rollback, what remains outstanding |
| TODOs in code | Always 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.