Purpose: define how human contributors stay meaningfully engaged when AI agents do most of the implementation work. The bottleneck has shifted from writing code to specifying intent and supervising output; this doc says what humans do now that AI does most of the typing.
Humans and AI agents collaborate as active contributors under explicitly asymmetric authority and accountability. AI may author and maintain most of the implementation; a named human remains accountable for its acceptance and operation. This doc says what the human side of that collaboration looks like — and what stops working when humans drift out of the loop.
Contributing across traditional job boundaries is welcome when the contributor can do the work and its required evidence, review, and human authority are covered. AI-assisted competence does not transfer professional accountability to the AI. See assurance profiles for risk-based requirements.
| Responsibility | Question | Who covers it |
|---|---|---|
| Author | Does the implementation or artifact address the approved intent? | A capable human or AI contributor, including someone working outside their usual title. |
| Verifier | Does evidence show the approved criteria are met? | At A2, a separate human or fresh AI session; at A3, qualified human specialist participation is mandatory. |
| Acceptor | Is the result suitable for its intended use at this risk? | The accountable human, using the required evidence and reviews. |
For A0/A1, an author may also perform verification where existing gates permit; this does not remove human accountability, user testing, or human decision gates. At A2/A3, separate authorship from verification and obtain explicit human acceptance. The acceptor may also be the human author or verifier where domain/project rules permit, but independent verification cannot be the author’s self-review. A solo contributor can use a fresh AI verifier for A2; A3 needs a qualified human verifier independent of the author, potentially a shared specialist.
Independent evidence, not model agreement: the verifier starts from approved criteria and repository artifacts, checks assumptions against sources, and runs or independently inspects reproducible evidence rather than relying on the author’s summary. Record verifier identity/session, scope, evidence, and findings. Cross-AI review is useful adversarial evidence, but different models can share blind spots or the same mistaken specification. It does not by itself establish independent assurance or replace domain review.
Accountable acceptance: the human confirms intent, classification, required reviewers/checks, evidence sufficiency, operational ownership where relevant, and any acceptable residual risks. Record the decision on the item or link a durable acceptance record. This is responsibility for the delivered result, not a requirement to read every generated line. Required gates cannot be traded away as residual risk; unresolved required review or acceptance keeps the item open.
Every epic identifies human owners for customer intent/outcome, product/UX judgment, technical delivery, verification coordination, and accountable acceptance, plus security/compliance when applicable. Use names or human-held roles with current holders discoverable in the repository. Mark an inapplicable capability with a reason. The verification owner arranges the required verifier; ownership does not make an author independent.
One person may cover several capabilities. A shared specialist may cover several squads. AI agents can perform work within these capabilities under the existing decision matrix; they are not the accountable owners. No specific job titles, headcount, or squad composition are prescribed. See the charter and solo/squad walkthroughs.
Projects with parallel implementers must declare Implementation WIP and Verification WIP in the project instruction file, with one shared project-wide view across squads. Start with 3 and 2 respectively, then let the accountable human adjust to actual review capacity. Solo sequential work need not add numeric limits. These item limits supplement the separate active-epic cap.
in-progress; verification WIP counts the combined under-review and to-be-tested queue, including work actively being reviewed. Count each item once.blocked or mark it done to meet a number.in-progress when an implementation slot is free; until then keep the truthful review/testing state with the failure and rework need recorded. A lock or a separate squad does not grant extra capacity. Resolve contention through the existing lock/coordination protocol; counts are cooperative signals, not enforced reservations.When AI generates code faster than humans can review it, three things happen if nothing changes:
The methodology’s other docs cover how to work and how to gate completion. This one covers how the human stays a real contributor when they’re not the one typing the most.
The classical software workflow bottleneck was execution: writing code is slow; understanding requirements is comparatively fast; reviewing code at a sensible pace fits in between.
The AI-assisted workflow inverts this: writing code is fast (sometimes order-of-magnitude faster); understanding what you actually want is now the slow step; reviewing volume is the constraint on the system.
The implication: rigor must shift upstream. The specification is the thing that determines whether the AI produces useful output. Sloppy specs produce confident-looking wrong code, and the wrong code passes superficial review because the spec was never sharp enough to disprove it.
A well-defined test suite can be fed to an AI agent to reproduce an implementation in a different language, framework, or runtime. The implementation is increasingly replaceable; the test suite (when it accurately captures intent) is not.
That’s a real shift in what the team should treat as the durable asset:
| Era | Durable asset | Replaceable |
|---|---|---|
| Pre-AI | Code (humans wrote it; it took months) | Tests (often added later, often skimped) |
| AI-assisted | Specification + test suite (captures intent) | Code (AI rewrites in any stack from the spec) |
Teams that treat code as the asset and tests as overhead will be slower than teams that treat the spec + test suite as the asset and let AI regenerate code as needed.
A new layer of work has appeared between writing code and shipping to production. The article-of-record term is “supervisory work.” It consists of:
This supervisory layer is the human contribution in an AI-driven workflow. It is not less work than writing code was; it is differently shaped work.
Four anti-patterns capture most of the ways an AI-driven workflow fails. Each has a defense.
The AI writes the implementation. The AI also writes the tests. The tests are subtly tuned to validate the (wrong) implementation. The test suite passes; the code is wrong; the loop is self-consistent. No human in the loop catches it because the green test suite looks like done.
This is the AI-coding equivalent of marking your own homework.
Defenses:
AI models are trained to be helpful and agreeable. That works most of the time and breaks at the worst moments: during a production incident, when evaluating an architectural fork, or when a load-bearing assumption is on the table.
In those moments, you propose a theory. The AI agrees with it. You both proceed. The system continues to fail because the theory was wrong — but you both believed it because you reached consensus.
Consensus between you and the AI is not validation. You may both be wrong in the same way.
Defenses:
You used to know your codebase. Now most of it was written by an AI agent over the last quarter and you’ve only superficially reviewed it. When something breaks, you reach for the AI that wrote it — because you don’t know where to start.
This is a slow-rotting failure mode. It doesn’t manifest as a single incident; it manifests as a steady decline in your team’s ability to operate the system without the AI.
Defenses:
The AI reads documentation. It does not have the lived experience of “we tried this two years ago and it failed because…” or “this looks redundant but is workaround for the X-Y bug.” That context lives in human heads, in old issue threads, in postmortems nobody reads anymore.
When that context is missing, AI agents will confidently propose the same failed approach the team tried two years ago — because nothing in the codebase or the docs warns against it.
Defenses:
docs/incidents/ or similar. AI agents read them as context for new work.When AI is doing most of the implementation, the specification — not the code — is the thing the team should be best at producing.
A good specification is:
| Format | Good for | Why AI handles it well |
|---|---|---|
State machines (mermaid stateDiagram-v2 or text tables) |
Stateful flows, lifecycles, modal UIs | Discrete states + named transitions = code that almost writes itself |
| Decision tables | Branching logic, permissions, eligibility rules | Exhaustive coverage of input combinations; AI can detect missing rows |
Sequence diagrams (mermaid sequenceDiagram) |
Multi-actor flows, API choreography | Explicit ordering removes a major source of AI guesswork |
| Schema-first definitions (JSON Schema, Zod, Pydantic, etc.) | Data contracts, API requests/responses | Type system as spec; AI generates parsing + validation deterministically |
| Given / When / Then acceptance criteria | Item-level behavior | Maps directly to test names; AI implements until the named test passes |
| Examples + counter-examples | Edge cases, ambiguous categorization | “Input X → output Y; input X’ (one char different) → output Z” forces the AI to reason about the boundary |
The methodology’s existing plan-mode rule is the foundation. This section sharpens it for the supervisory layer.
These are all things the AI will pick something for if you don’t specify. Picking something is usually fine for trivial work and dangerous for non-trivial work.
For non-trivial work, the human reviews:
This is a dedicated review, not a PR comment after the code is written. Unwinding a wrong architecture from generated code is much more expensive than catching the wrong direction at the planning stage.
Format suggestion: an “Architecture Decision Record” (ADR) per non-trivial choice, written by the AI, reviewed by a human, before the code lands. Plain markdown; one page; what / why / alternatives / consequences.
XS or S per the item effort scale in 04_backlog_items.md — XS is under 2 hours; S is a half-day).Use judgment; over-applying this slows everything down. The goal is to catch the high-impact wrong directions, not to add ceremony to every change.
Not all human skills transfer equally to an AI-assisted workflow. Some that were peripheral become central; some that were central become less critical.
This isn’t a claim that writing code is obsolete — engineers still write code, sometimes a lot of it. It’s a claim that being fast at producing keystrokes is no longer the differentiator it used to be. The differentiator is the upstream and supervisory work — the architecture, the spec, the review, the judgment.
The methodology is silent on hiring (that’s strategy-doc territory). But the patterns above shift what’s worth hiring for:
The point isn’t to rank these tiers. The point is that the shape of work changes for each, and pretending it doesn’t is the failure mode.
The supervisory layer lists what humans do. This section gets concrete about which decisions are theirs. Without an explicit ownership map, two failure modes appear: AI agents quietly making decisions that turn out to need human judgment, or humans bottlenecking decisions an AI is fully capable of making.
The map below is a starting point — a default that fits most projects. Adapt to your team’s risk tolerance. Pairs with 09_git_workflow.md “What AI agents can and can’t do in git” — that table maps the same ownership logic to specific git operations; this table maps it to decision types.
| Decision type | AI proposes | AI decides | Human reviews | Human decides | Human-only |
|---|---|---|---|---|---|
| Code style and formatting | ✓ | ✓ | |||
| Variable / function naming | ✓ | ✓ | |||
| Refactor structure (no behavior change) | ✓ | ✓ | ✓ | ||
| Adding a unit test for an existing function | ✓ | ✓ | |||
| Bug fix (small, well-scoped, in code AI wrote) | ✓ | ✓ | ✓ | ||
| Bug fix (legacy code AI didn’t write) | ✓ | ✓ | ✓ | ||
| New small feature in established pattern | ✓ | ✓ | ✓ | ||
| Choice of library / dependency | ✓ | ✓ | ✓ | ||
| Database schema change | ✓ | ✓ | ✓ | ||
| Public API shape (request/response, errors) | ✓ | ✓ | ✓ | ||
| Authentication / authorization logic | ✓ | ✓ | ✓ | ||
| Performance-critical optimization | ✓ | ✓ | ✓ | ||
| New architectural pattern (where data lives, async vs sync, etc.) | ✓ | ✓ | ✓ | ||
| Pillar definition / strategy phase shift | ✓ | ||||
| Pricing, business model, contractual terms (the decision — operational price-list edits inside an approved model are AI-eligible) | ✓ | ||||
| Hiring / firing / team composition | ✓ | ||||
| Production deploy execution | ✓ | ||||
Destructive workspace operations — git reset --hard, force-push, branch -D, clean -fd (approval-gated) |
✓ | ✓ | |||
Destructive production operations — DROP TABLE, data resets, cancelling payments, rm -rf outside the workspace (agent-prohibited) |
✓ | ✓ | |||
| Anything affecting real user data in production | ✓ | ||||
| Anything involving money, payment, or financial systems | ✓ | ||||
| Anything with legal, compliance, or regulatory implications | ✓ |
The columns escalate left-to-right:
“Destructive” is not one category, and treating it as one is how a rule ends up meaning three different things in three places. Two classes, disjoint, every destructive operation in exactly one:
| Class | Who executes | What an explicit user approval does |
|---|---|---|
approval-gated |
The agent may execute — never autonomously | A scoped, per-operation “yes” authorizes that operation. It does not generalize to the next one, or to the rest of the session. |
agent-prohibited |
A human executes. Always. | Nothing. A “yes” does not transfer execution to the agent; it authorizes the human to proceed. |
The line between them is blast radius, not danger. A destroyed working tree costs an afternoon and is often recoverable through the reflog. A dropped production table costs real users’ data and is not. Both deserve a confirmation prompt; only one of them can ever be safely answered by the agent acting.
This is also the boundary where the authority ladder stops being unlimited. Explicit user direction outranks every other rule and can authorize an exception to any approval-gated operation. It does not hand an agent the execute step on an agent-prohibited one — that class is defined by who acts, not by who consents, so there is nothing for consent to unlock. If a project wants a live yes to be able to override that too, it must say so explicitly; the default is that it cannot.
Three knobs to turn:
The matrix is not a contract with the AI — it’s a contract among the humans about what they own. Make it explicit, then enforce it via the project-instruction file (“the following operations require human authorization: …”).
Some decisions must be human-only regardless of how capable the AI is. The methodology’s hard rules and the operational discipline in 09_git_workflow.md name several:
agent-prohibited — a human executes.agent-prohibited — a human executes.approval-gated — the agent may execute once authorized, never before.These are non-negotiable across projects. Even if the matrix becomes more AI-permissive over time, these rows stay in the rightmost column.
In practice, the matrix has gaps. New decision types appear all the time (new dependency category, new compliance question, new performance corner). The protocol when a row is unclear:
This is the same shape as the memory promotion loop — a one-off judgment call, repeated, gets written down as a rule.
Without an explicit ownership map:
Naming the rows makes the contract visible. Everyone — humans, AI agents, future contributors — knows where the lines are.
| Mistake | Fix |
|---|---|
| Senior contributors approve PRs without reading the diffs because volume exceeds capacity. | Reduce PR volume per cycle, or add another reviewer (human or cross-AI), or invest in pre-implementation review so post-implementation review can be lighter. |
| Architectural decisions get made implicitly in AI-generated code. | Require explicit ADRs (or equivalent) for non-trivial choices, reviewed before code lands. |
| Tests are written by the AI immediately after the implementation; nobody human-reviews the test design. | At minimum: human-review the test names and acceptance criteria. Ideally: write the test (or the acceptance criteria) first. |
| Team agrees with AI on a debugging theory; the system keeps failing. | “Challenge before consenting.” Use a different model to argue the contrarian case. Treat suspicious unanimity as a signal. |
| AI proposes the same broken approach you tried two years ago. | Build the incident archive; write the “why we don’t do X” docs; populate the memory directory. |
| Junior contributor ships AI-generated code they don’t understand. | Mentor them through what the AI did and why; build their architectural muscle alongside their AI fluency. |
| Senior contributor checks out of the codebase because “the AI handles it now.” | Codebase walks (humans only) on a quarterly cadence; force the architectural muscle to stay active. |
| Specifications are vague prose; AI fills the gaps with plausible-sounding guesses. | Move spec format toward state machines, decision tables, schema-first definitions, Given/When/Then. |
| AI keeps recommending the documented fix even when the actual cause is elsewhere. | Build the tribal-knowledge layer (incident archive + memory) so the AI has the context to consider non-documented causes. |
| The team has no idea what the AI just shipped over the last week. | The supervisory layer has collapsed. Reduce AI throughput until human review can keep up, or invest in the supervisory layer until throughput is sustainable. |
This doc defines the shape of the human contribution in an AI-driven workflow. It doesn’t prescribe specific roles, titles, or org structure — those are project-specific. The patterns and anti-patterns transfer; the implementation is yours.
When the methodology’s other docs and this one appear to conflict: the working principles (06) and the Definition of Done (07) are foundational and win. This doc adds human-side guidance on top of those foundations.
The integrity rule from templates/AUTONOMOUS_LOOP.md (“never claim something is tested / secure / complete / production-ready unless it was actually verified”) applies doubly to the human side: don’t claim oversight you didn’t actually exercise.
End of the methodology set. Return to 00_README.md for the index.