Summary: The traditional SDLC was built to maximize efficiency in an era when writing code was the most time-consuming and expensive stage. That is no longer true. When generation becomes cheap, the constraint moves to the human-speed stages — planning, review, deployment, maintenance — and a process optimized for the old bottleneck starts obstructing rather than helping. The playbook's answer is to convert the linear handoff chain into a loop with AI embedded at each point, where each stage produces a version-controlled artifact that triggers the next, and human attention concentrates at decision gates instead of spreading evenly across every step.

Provenance note: the vault's raw clipping of this page captured only the frontmatter and one sentence — the page is JS-rendered and the clipper got nothing. This article was written from the live page retrieved on 2026-09-11. The clipping also carries published: 2001-08-21, a mis-parse of "August 21, 2026"; the date used here is the corrected one.

The premise

Controls in a conventional SDLC exist to force alignment across weeks or months of human work. Review capacity in particular was planned around human output: a PR waits for a reviewer to read all of it, review quality varies with reviewer load, the author chases, and the backlog grows. That model does not survive a step-change in how much code arrives.

The inversion the playbook proposes is to enforce governance automatically before human review — through hooks, skills and sandboxing — so that human attention lands on intent and risk rather than mechanical verification. The recurring principle is stated plainly: "humans remain accountable for every decision that requires judgment." The human stays above the loop, not in it.

This is the structural answer to the problem The Senior Review Bottleneck documents from the field: generation got cheap, verification did not, and the cost landed on seniors because nothing else was positioned to absorb it.

The six stages

1. Plan — capture as intent.md

Ideas are captured by the originator rather than filtered through committee refinement. The originator describes the problem conversationally to Claude, which generates an intent.md from an organizational template — problem, proposed outcome, affected systems, constraints, open questions. The originator corrects misunderstandings, and the artifact commits to version control with author and timestamp.

  • Leading metric: time from first conversation to committed intent.md — hours, against multi-week traditional cycles.
  • Lagging metric: survival rate of accepted intent.md files; rework frequency once Design begins.
  • Governance: the product owner approves; the merge or closure decision is recorded in git history.

2. Design — requirements and design collapse into one session

Once intent.md is approved, Claude produces a spec.md guided by organizational skills that encode policy for brand, security, compliance and UX. The product owner iterates on it but does not write it, and works through flagged concerns with policy owners first; higher-risk changes go to a technical lead before approval. Both artifacts are committed, recording the request and the decision.

The key idea here is skills as institutional knowledge: versioned, explicit, applied consistently. When a policy changes, the skill is updated centrally and everyone picks up the new version on their next session. That is the difference between policy enforced concurrently and policy discovered in post-hoc review.

3. Build — plan mode as the default starting point

Engineers begin in read-only plan mode with the approved spec.md. Claude interviews the engineer and proposes an implementation plan naming the files, the order of work and the tests; the engineer interrogates it — what could break, which step is riskiest — and commits it as plan.md before any edit mode is entered. If the implementation later departs from the plan, plan.md is updated in the same commit.

Institutional knowledge becomes machine-readable in a repository-root CLAUDE.md: conventions, build and test commands, architecture notes, and the things the model gets wrong. The examples given are concrete — "Money is always BigDecimal, never double", "Do not bump dependency versions; the platform team owns them." The maintenance rule is equally concrete: update it whenever Claude repeats a mistake twice.

Scale comes from parallel sessions — one engineer orchestrating several Claude Code instances in separate git worktrees on independent tasks — and subagents for recurrent jobs within a session, such as a verifier that runs tests without fixing what it finds.

  • Leading: share of changes merging on the first implementation pass; time from plan approval to merged PR.
  • Lagging: rework cycles per change; alignment between the merged diff and the committed plan.md.

Design review thus happens before code generation, via plan approval — which is what makes the build stage largely autonomous afterwards.

4. Test — every session checks its own work

Testing moves from a late-stage QA gate to a continuous feedback loop. The rule is to always give the agent a measurable, checkable target: all tests in test_status.py pass, screenshot matches the approved mock, endpoint returns 200 with the new field. The agent iterates until the check passes, before a human sees the work.

Practically: wrap checking into one command such as make test; document the expected healthy output in CLAUDE.md; for a bug fix write the failing test first, commit it, and mark the test files off-limits to the agent via a hook so the fix cannot be achieved by editing the test; for UI work supply a browser tool and the mock and iterate visually; and make verification part of the definition of done.

The more distinctive practice is continuous evals in CI. Collect 20–50 real tasks with expected outcomes, write them as prompt plus acceptance checks, run them non-interactively in CI whenever CLAUDE.md, skills or hooks change, and gate configuration changes on the pass rate. The configuration steering the agent is regression-tested like code, and every production incident becomes a permanent eval.

That mechanism is the direct answer to the silent decay described in You Coach an Engineer Once. You Coach an Agent Forever — behaviour that erodes without announcing itself is exactly what a scheduled eval suite catches.

5. Deploy — review in both directions

Review becomes symmetrical: the agent reviews incoming PRs while humans review agent-authored PRs. A REVIEW.md policy file defines the review passes — bugs, security, compliance — and findings are ranked by severity. Tagging @claude on a review comment has the agent address it and push a fix. Human approval is still required, but concentrates on intent and risk.

Hooks act as approval gates, pausing execution until a named person approves — blocking a production deploy without release-manager sign-off, for instance. In CI/CD, the agent runs non-interactively for judgment steps such as triaging failed builds, summarizing flaky tests and drafting changelogs, with write operations behind existing gates, sandboxed execution, and scoped short-lived credentials. Deployment is exposed through MCP tools tiered by environment: free deploys in dev, intermediate controls in staging, an authorization hook in production.

The separation of duties is preserved absolutely — the agent cannot approve its own code — and approvals are logged in PR history as an audit trail.

  • Leading: time to first review, expected in minutes; share of comments resolved without a human touching the branch.
  • Lagging: defects and vulnerabilities caught before merge versus those escaping to production.

6. Maintain — the loop closes

Maintenance becomes proactive: breached control bands, incidents and tickets invoke the agent with no human in the invocation path, and findings re-enter the pipeline as intent.md.

A deterministic script — no model involved — watches production metrics such as test failure rate, 5xx rate and PR cycle time against a rolling baseline, with tiered responses defined in a version-controlled bands.yaml:

Breach Response
1σ log only
2σ agent diagnoses, read-only
3σ agent proposes a fix — opens a PR or triggers a pre-approved runbook

The agent writes its diagnosis as an intent.md in Stage 1 format, which then flows through the normal pipeline; an on-call engineer triages the queue as fix-now, schedule, or dismiss, with dismissals recorded and a reason given. Each incident gains an eval so the class cannot regress.

Two adjacent surfaces extend the same loop: scheduled vulnerability scanning, where each finding is validated with a confidence rating before reporting and small bounded findings flow through the PR gate while larger ones become intent.md; and incident response in chat, where the agent joins Slack or Teams under its own identity as a first responder, keeping the conversation and decisions in-channel and delivering fixes as PRs through the review gate.

  • Leading: time from band breach to intent.md in the triage queue.
  • Lagging: share of findings that become merged fixes; repeat incidents of the same class.

The artifacts

The playbook's real substance is that every stage hands off a file under version control rather than a meeting outcome, which is what lets the next stage trigger automatically and what makes git history the audit trail:

Artifact Purpose Stage
intent.md problem statement and proposed outcome Plan
spec.md requirements and design, with flagged concerns Design
plan.md files to change, order of work, risks, proof Build
CLAUDE.md repo conventions, commands, mistakes to avoid Build
Skills versioned, centrally distributed policy Design / Build
REVIEW.md review passes, severity definitions, thresholds Deploy
bands.yaml control metric thresholds and response tiers Maintain

This is the spec-driven argument made operational. Return of the spec predicted the specification would regain primacy; Spec-Driven Development Will Collapse warns that specs collapse under their own weight without a mechanism to keep them honest; The Solo Developer Gets More From SDD Than a Team shows the four-phase cycle working for one person. The playbook's contribution is the enforcement layer those arguments needed — hooks, evals and gates that make the artifacts load-bearing rather than aspirational, because an artifact nothing checks is documentation.

What this costs, and what it assumes

The playbook is a vendor-authored methodology, and worth reading with that in mind — it assumes a particular toolchain, and the metrics it proposes are leading indicators rather than demonstrated outcomes. The honest counterweights are already in the vault: Spec-Driven Development Will Collapse on specification decay, the conflicting METR and rework evidence aired in The Solo Developer Gets More From SDD Than a Team, and Are We Really Engineers on the gap between a documented process and an engineering discipline.

What is not vendor-specific is the structural claim, and it is the durable part: when generation stops being the bottleneck, a process designed around the generation bottleneck becomes the bottleneck. Where the verification work lands, and whether it lands on a person or on a check, is the decision that actually matters.