The AI-Native SDLC Moves Review Upstream — Three Links Have No Check

At a glance

The playbook (Louis Claxton, Anthropic, 2026-08-21) reorganises the software development lifecycle around six stages, each of which commits a version-controlled artifact the next stage consumes. The commit history is the audit trail; the plays are the practices that produce each artifact.

The chain is the interesting part, not the stage count. Six-phase lifecycle diagrams are older than most of us; a lifecycle where every phase boundary is a git commit of a machine-readable artifact is new, and it is what makes the rest of the playbook enforceable rather than aspirational.

"Code is no longer the bottleneck" is a claim about queues

The playbook opens on that line, and it is easy to read as a productivity boast. It is not. It is a statement about where a pipeline's constraint sits, and constraints do not disappear when you speed up the stage in front of them — they relocate. Make implementation ten times faster and throughput does not rise ten times; work-in-progress piles up at whatever comes next, which in every software organisation is review, test, and release.

The 2025 DORA report measured exactly that shape. Ninety percent of respondents now use AI at work — up fourteen points year over year — spending a median of two hours a day with it. AI adoption is now positively associated with delivery throughput, a reversal of the previous year's finding. And it is still associated with elevated instability: more change failures, more rework, longer time to restore. Throughput up, stability down, in the same dataset, is the signature of a pipeline whose build stage got faster while its verification stages did not.

Trust tracks the same fault line. Twenty-four percent of DORA respondents report high trust in AI output; thirty percent trust it a little or not at all. Those are not people who dislike the tool — they are people whose control systems have not caught up with its volume, and who are correctly discounting output they cannot check at speed.

So the honest framing of the playbook is not "here is how to go faster." It is: the constraint has already moved, you are already living downstream of it, and here is a reorganisation that moves the human attention to where the constraint now is. As the playbook itself puts it, "when agents multiply code output, either the review queue builds or code ships under-reviewed."

The chain is a compiler, and its passes are unverified

Think of the chain as a compilation pipeline. An intent is lowered into a spec, a spec into a plan, a plan into a diff, a diff into findings. Each hop is a translation from a higher-level representation into a lower one, and — exactly as in a real compiler — the whole thing is trustworthy only if you can trust each pass.

A real compiler earns that trust structurally. Its intermediate representation is typed, its passes are deterministic, and a lowering that produces something the next pass rejects fails loudly at build time. None of those three properties holds here. The intermediate representation is English prose. The passes are language models, so the same input can lower two different ways on two different days. And there is no type error for "this plan does not implement this spec" — a plan that quietly drops a requirement compiles fine, all the way down to a green CI run.

Which means the plays are not a grab-bag of productivity tips. Each one is a check bolted onto one hop, standing in for the verification a compiler would get for free. Reading the playbook that way — asking of each play "which translation does this validate?" — is what makes the gaps visible, because the gaps are the hops nobody named a play for.

Git does not close them for you. The commit history gives you an ordering of artifacts, not a derivation: it records that spec.md was committed after intent.md, never that it was written from it. Amend the intent after the spec lands and the log looks identical.

Which play guards which hop

Compare the hops across one axis — what happens when the translation is wrong? — and they sort into three groups rather than eight. On the spec.md → plan.md hop, plan mode withholds every file edit until a human approves the plan, so a wrong translation stalls; on plan.md → diff, a PreToolUse hook can refuse the tool call outright, so a forbidden action never happens; on config → behaviour, an eval suite below its pass-rate threshold fails the pipeline. Those three fail closed. On diff → policy, layered agentic review produces severity-ranked findings and a human adjudicates the critical ones — a wrong translation is usually caught, probabilistically. And on the remaining three, a wrong translation produces a perfectly well-formed artifact that flows downstream unremarked.

The asymmetry worth naming is that hooks are the only genuinely deterministic control in the entire playbook. Everywhere else the chain is a model checking a model, or a person reading prose. A hook is a shell script the harness runs before the tool call, and its refusal is not advice:

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Credential pattern in staged diff"
  }
}

Note what the hook contract does not let you do. A hook can deny a call; staying silent does not approve one, and exit code 2 is the one outcome that later JSON cannot override. Hooks tighten policy and can never loosen it. That asymmetry is exactly right for a governance layer — and it also means you cannot hook your way out of a review backlog by auto-approving. The deterministic layer is available for saying no, and only for saying no. See policy as code for agents for the general shape, and guardrails 101 for why an enforced refusal beats an instructed one.

The three thin hops

intent.md → spec.md: the most invention, the least checking

This hop creates more information than any other in the chain. A few paragraphs of problem statement, affected users, and open questions become a full specification with interfaces, edge cases, and acceptance criteria. The playbook's contribution here is real but orthogonal: organisational skills inject brand, security, compliance, and UX standards while the spec is being written, so policy is applied at authoring time instead of discovered in a review three weeks later. That is a genuine improvement, and it is a check on the spec against policy — not against the intent.

Nothing checks the spec against the intent except a product owner reading two Markdown files side by side. A requirement the intent never implied, or an open question the spec quietly resolved in the convenient direction, is invisible to everything downstream: the plan will implement it faithfully, the tests will cover it, the review will pass it, and the eventual incident will be filed against a spec that everyone approved.

diff → spec.md: reviewing the code is not reviewing the requirement

Agentic PR review, as the playbook describes it, reads the incoming diff against organisational policies and ranks findings by severity. That catches bugs, vulnerabilities, and convention breaches — the things a reviewer looks for when the requirement is assumed correct. It is a different job from asking whether this diff is what the spec asked for, and it is that second job that catches the expensive failure mode: an agent that built the wrong thing, correctly.

Evals do not cover it either. A regression suite tells you the behaviour did not change in ways your eval set already knows about; it says nothing about whether the behaviour matches a spec written last Tuesday. See eval-driven development and CI for what an eval gate can and cannot promise.

production → intent.md: the only artifact with no human author

The Maintain stage is the most novel part of the playbook and the least guarded. A detection script watches production control bands — test failure rate, error rates, cycle time — and when one breaches, Claude is invoked to diagnose; the diagnosis is written as an intent.md and re-enters the pipeline at stage one. It is the only hop where an artifact enters the chain with no human author at any point.

Its check is entirely downstream: the stage-one product-owner review. Which means the loop is closed only as tightly as that intake queue is attended. An unattended intake turns a closed feedback loop into an open-ended generator of work — and the playbook's own leading indicator for stage one, time from first conversation to a committed intent.md, gets better as the generator gets more prolific. Pair it with the lagging indicator (survival rate into stage two) or it will read as progress.

What the metric set does not measure

The playbook proposes a thoughtful set of leading and lagging indicators — time to a committed intent, elapsed time between intent and spec, share of parallel sessions per engineer while review quality holds, time to first PR review, eval pass rates; then survival rate of intents, requirements rework after build starts, first-pass CI success for agent-written changes, escaped defects, repeat incidents of the same class. Two things are missing from it.

The first is any measurement of a hop. Survival rate measures whether the product owner accepted the intent, not whether the spec was faithful to it. Requirements rework after build starts is the closest proxy, and it only fires after the mistranslation has already cost you a build.

The second is cost. Parallel sessions and layered agentic review both multiply token spend by design, and "share of parallel sessions per engineer while review quality holds" measures the numerator only. An agent re-sends its whole transcript each step, so a long session's input tokens grow with the square of its step count — see agent cost control. Six stages of agentic artifacts is a lot of transcripts.

Making the chain load-bearing

None of the gaps above is an argument against the playbook. They are the parts it leaves to you, and each has a cheap fix that fits the playbook's own idiom — a versioned artifact, or a hook.

Stamp provenance, so git records derivation and not just order

Put the upstream artifact's commit SHA in the downstream artifact's front matter: spec.md carries the SHA of the intent.md it was written from, plan.md carries the spec's, the PR body carries the plan's. Now the chain is a real graph rather than a sequence of files that happen to sit in the same repository, and "the intent changed after the spec was approved" becomes a CI check instead of a thing someone has to remember. A PreToolUse hook can refuse a commit whose front matter points at a SHA that is no longer the head of that artifact. This is the decision receipt pattern applied to the SDLC.

Make the easiest hop check mechanical

Of the unchecked hops, spec.md → plan.md is the one you can validate with a script rather than a model: a plan that touches files no spec section mentions, or omits a subsystem the spec names, is a signal worth surfacing at approval time. It is a crude heuristic and it will produce false positives on refactors. It also costs nothing to run and catches the plan that quietly grew a scope.

Give the intent → spec hop a judge, not a reader

The hop that most needs a check is the one least amenable to a script, because faithfulness between two prose documents is a judgement. That is what an LLM judge with a fixed rubric is for: does the spec address every open question the intent raised, and does it introduce any requirement the intent does not imply? Run it as a gate on the Design stage and you have converted a reading task into a measurable one. Calibrate it before you trust it — see judge calibration and meta-evaluation, because an uncalibrated judge on a governance gate is worse than no gate at all.

Gate the autonomous intake

A production-detected intent should land as a draft with an owner and an expiry, not as a peer of a human-authored one. Count acceptances, not creations. This is the human-in-the-loop placement question in its sharpest form: the loop is autonomous everywhere except one point, so that point has to actually be staffed.

Reserve hooks for what must never be probabilistic

Credentials in a diff, writes to protected paths, production deploys, anything irreversible. These are the places where "the model usually gets it right" is not an acceptable control, and they are the places where the hook's deny-only asymmetry is a feature. Everything else can be a review finding.

Portable, or Claude Code?

The playbook is explicitly modular — organisations pick stages and plays by priority, and each play names its prerequisites. Worth separating, before you plan an adoption, is which plays are file conventions you could adopt this afternoon and which are harness features you cannot reproduce with a prompt.

Spec-driven development is not a Claude idea and has a healthy ecosystem: GitHub's Spec Kit is MIT-licensed, passed 130,000 stars, reached v1.0.1 on 2026-08-21 — its first birthday — and drives specification, plan, tasks, and implementation across thirty-plus agents including Claude Code. AWS's Kiro builds an IDE around three spec files, requirements.md, design.md, and tasks.md. Anthropic's naming differs; the shape does not.

So the format half of the playbook is a convention, and the convention is converging across the industry. The enforcement half is harness features — and the enforcement half is the half that does the work. A team that adopts intent.md without adopting anything that can refuse has adopted a filing system.

One row deserves more caution than it gets in the original. Exposing deployment and rollback through MCP hands an agent the release button behind environment-scoped permission tiers, and permission tiers are only as good as the identity behind them. Read agent identity and permissions and ambient authority before wiring that one up; a deploy tool that inherits a human's credentials is not a permission tier, it is a costume.

Where to start

Modularity is only useful if you pick by constraint rather than by stage number. The relevant question is which queue is currently the deepest.

The last row is not a filler answer. A reorganisation whose entire premise is that the constraint has moved is not one you should adopt blind — if you cannot see where your own work-in-progress accumulates, you cannot tell an improvement from a relocation. See agent observability for the instrumentation, and AFK coding for the same constraint argument at the level of a single feature rather than an organisation.

The playbook's closing line is "The loop keeps running. Human judgement stays above it." That is the right ambition, and it is a claim about placement: judgement stays above the loop only where an artifact is genuinely reviewed. Put the checks on the hops and the sentence describes your pipeline. Leave the hops bare and it describes a diagram.

Further reading

On this wiki:

• AFK coding — the same constraint argument at feature scale: parallelism is bounded by review capacity, not agent capacity.
• Policy as code for agents — why enforcement belongs in the harness rather than the prompt.
• Decision receipts and audit — the provenance-stamping pattern behind the SHA suggestion above.
• Eval-driven development and CI — what an eval gate can and cannot promise.
• Judge calibration and meta-evaluation — required reading before an LLM judge guards a stage boundary.
• Agent skills and agent harness — the two primitives most of the plays are built from.
• Human in the loop · Guardrails 101 · Agent cost control · Agent observability
• Claude Code vs Codex CLI vs Cursor Agent vs Aider — which harnesses offer the enforcement half.

Sources:

• The AI-native SDLC playbook — Louis Claxton, Anthropic, 2026-08-21
• Claude Code hooks reference — event names and the PreToolUse deny contract
• Announcing the 2025 DORA report — throughput, instability, and adoption figures
• github/spec-kit — MIT, 130k+ stars, v1.0.1 (2026-08-21)
• Kiro specs documentation — the requirements.md / design.md / tasks.md structure