Give an agent repository access and a competent prompt, and you will not get your team's good habits. You will get your team's failure modes at machine speed.
Consider the ordinary shape of this. A team reviews every pull request but nobody ever writes down what "acceptable" means, so reviewers catch what they happen to notice. Now put the two or three parallel worktrees the playbook recommends [1] behind that team, and the same tacit standard has to survive several simultaneous sessions with no shared memory and no human in the loop. It does not. The agent ships the migration without a rollback, the rename that breaks a public contract, the endpoint that reads a secret from an environment variable nobody documented. None of this is a model failure. It is a process that was never written down, executed by something that does not get tired at 3 a.m.
The uncomfortable implication is that model selection is the least of the levers. Anthropic's AI-native SDLC playbook describes six stages driven by artifacts rather than by a scheduler [1], and its most transferable content is not the pipeline diagram. It is the set of deterministic supports that surround the agent: the versioned context it must read, the artifacts it must consume and produce, the checks that can refuse it, the boundaries it cannot cross. Get those wrong and a better model simply executes your mistakes more competently. Get them right and the model becomes interchangeable, because the guarantees live in the repository and the CI configuration rather than in the weights.
Layer 1: Versioned context
The first layer is the context the agent is guaranteed to see. Anthropic's guidance is that CLAUDE.md should stay at roughly one page [1]. The cap is the substance, not a style preference. A file re-read on every session competes with the task for a finite context window, and a context file that grows without limit is a file that quietly stops being read: the earliest paragraphs carry the authority, the rest is token cost.
The more useful mechanism is the "rule of two": if an instruction has fired twice, it is now a rule [1]. That is a cheap, auditable conversion function from tacit practice to written policy. The same review comment appears twice; the second occurrence is the evidence that it is a policy and not a preference, and it goes into CLAUDE.md as a rule. Nothing else in the playbook gives a team such a low-cost trigger for institutionalising what it has already decided.
The rule is also what makes skills worth building. A skill is not a longer CLAUDE.md but a named, version-controlled unit of institutional memory loaded on demand — the migration procedure, the release checklist, the review rubric for one subsystem — where per-session prompting is institutional memory loss, which is exactly the failure Anthropic names when knowledge only lives in people's heads [1].
Optiver's team arrives at the same place from the other direction and states the reason plainly: most agent failures come from the environment, not the model, and golden paths — the paved routes that make the right thing the easy thing — have to be engineered rather than documented [6]. This is a company self-report, but the distinction holds on its own terms. A documented golden path is a page someone reads once; an engineered golden path is a script with no arguments. That is why the rest of this article is about mechanisms rather than documents.
Implementation, concretely: CLAUDE.md at the repository root, reviewed like code because it steers every session there. Skills as directories with a description, an invocation and a script, merged through the same pull request template as source. A rule that cannot be stated as a check belongs in CLAUDE.md as guidance; a rule that can be stated as a check belongs in Layer 4 as a gate.
Layer 2: The artifact chain as a control surface
The playbook's second layer is the chain: intent.md → spec.md → plan.md → the diff and its tests → the pull request with its review findings → the incident record [1]. Markdown carries the chain through the design stages because "a product owner and an agent can both read and act on the same file"; code plus its records take over from build onward [1]. Each stage ends by committing a versioned artifact that the next stage reads, and the playbook is explicit about the payoff: "The chain of commits is also the audit trail: who asked for what, what the agent produced, and who approved it" [1].
For an infrastructure argument, the important property is not the audit trail. It is that the chain is machine-readable. Documentation is written for a human who chooses to read it, lazily, with judgement. An artifact in the chain is read by the next stage at a known path and a known commit, without judgement, because that is the only thing it has. intent.md is not a record of what someone wanted; it is the input a spec stage can diff against. spec.md is not a design document; it is the contract a review stage can check the diff against.
That distinction is what turns the chain into a control surface rather than documentation, and it survives the replacement of any particular tool. Cloudflare reports running isolated subagents in GitHub Actions that hand knowledge to each other through a report.md file rather than shared memory, taking open issues on Astro from more than 200 to roughly 30 — about an 85% reduction [4]. That is a company self-report, but the mechanism is general: agents that can only exchange committed files still coordinate, and their coordination is auditable.
Implementation: fix the artifact paths. One file per stage, one known location, one known commit. Then enforce the ordering with a hook — no code written until plan.md exists and names the spec.md commit it implements. A chain is only a control surface if it cannot be skipped.
Layer 3: Evals for the agent configuration
The playbook's most transferable insight is not about the code the agent writes. It is that CLAUDE.md, skills and hooks are code, and code gets regression tests. The suite is built from 20 to 50 real tasks drawn from recent work, each with the prompt plus the checks that define acceptable output, run non-interactively in CI on a schedule and on any change to CLAUDE.md, skills or hooks — because that configuration steers the agent and deserves the regression testing that code gets [1]. Each production incident gets an eval written by the team that owned it, and that eval stays in the suite [1].
Two properties make this more than a testing convention. The first is the trigger: running on any change to the agent configuration means the regression is caught where it is introduced, in the same pull request as the edit that caused it. The second is the substrate — the chain's last stage is already an incident record, so converting an incident into an eval means writing checks against a document that exists rather than inventing a test from nothing.
There is a corresponding discipline on the evaluator side, and Anthropic's own numbers are the argument for it. Requiring review agents to prove each finding before flagging it raised the share of pull requests receiving substantive review from 16% to 54%, and roughly a third of the bugs behind past claude.ai incidents would have been caught [5]. The lesson generalises past review agents: an evaluator that emits unchecked findings trains the team to ignore it, while one that must justify itself produces the signal that gets acted on.
The honest prerequisite sits in the Claude Academy material for the same course: running the suite needs CI able to run Claude Code non-interactively, plus an API key with a budget reserved for eval runs [2]. Evals are not free, and a team that has not budgeted for them will quietly stop running them. Start smaller than the playbook suggests: every rule that reached CLAUDE.md through the rule of two has an incident behind it, so your first suite is largely already written.
Layer 4: Deterministic gates
This is where the playbook draws its sharpest line. A skill is advisory: it makes Claude likely to apply a policy while the code is written, and "nothing forces a session to comply with it". A hook is deterministic: it runs before Claude acts and can allow, ask or block. The formulation is worth quoting because it is the whole argument in one sentence — "the skill makes violations rare and the hook makes them close to impossible" [1].
| Skill (advisory) | Hook (deterministic) | |
|---|---|---|
| When it runs | Loaded by relevance during the task. | Before the action, every time. |
| What it can do | Bias the output toward a policy. | Allow, ask, or block. |
| What it guarantees | Nothing forces compliance. | A violation cannot complete. |
| Where it lives | Project or user settings, loaded on demand. | Project settings; managed settings for non-negotiable hooks. |
| Cost of bypass | One session deciding otherwise. | One settings edit, unless the hook is managed. |
The distinction has a consequence that surprises people, including in one documented case the authors of the playbook themselves. Hooks are described as approval gates in the Deploy stage, because release gating is the clearest case — but "hooks are not deploy-specific: they run wherever Claude acts" [1]. Under the playbook's own walkthrough, the example of stopping an agent from deploying is implemented as a skill, the weaker of the two mechanisms. Anthropic's separate account of their own security posture shows how far the advisory form goes in practice, described below.
Hooks live in version-controlled project settings, so they get code review and history. Non-negotiable hooks live in managed settings that individual engineers cannot switch off [1]. That second clause is the part teams miss. A hook a developer can edit is a convention with extra steps, and if your most important gate lives only in project settings, it is advisory in practice whatever the mechanism is called.
This is the most transferable mechanism in the playbook: the only layer here that does not care which agent, model or vendor runs the code. "Run this script before this action and block if it exits non-zero" is the oldest interface in software delivery, and it keeps working when the agent underneath is replaced.
The worked example is worth copying in spirit: a shell script inspecting a Bash command and blocking any deploy-to-production invocation when RELEASE_APPROVAL is unset [1]. It works because it inspects the concrete command rather than the stated intent, fails closed on a missing variable rather than on a policy judgement, and makes the exception a variable someone sets deliberately rather than a bypass someone finds.
Layer 5: Isolation and access
The fifth layer is where an agent stops being a process and becomes a workload with permissions. The Claude Academy material specifies the posture plainly: agents run in containers under network policy with short-lived tokens, and no production secrets by default [2]. Deploy and rollback are exposed as MCP tools with an allowlist per environment, so an agent cannot reach production unless the pipeline gives it a path [2].
The mechanism is the allowlist, not the caution. "The agent is careful about production" is not a control. "There is no tool it can call that reaches production" is a control, and it is testable by listing the tools: deploy(env) and rollback(env) in the MCP surface, an allowlist that reads staging in one environment and production in another, and a pipeline step that adds production only after a human approval token is consumed. The container and the short-lived token do the rest, so the blast radius of a misbehaving session is one ephemeral environment rather than a standing credential.
For the agent's own release discipline, the playbook adds control bands for production [1]: deploys move through deliberate bands instead of arriving whenever a session finishes. Combined with the previous layer, this is what makes autonomy and safety compatible — the agent acts freely inside a band, and the band is the boundary a human owns.
Separation of duties
Infrastructure layers describe what the agent can see and do. The structural question is who checks it. The playbook's rule is blunt: the agent that proposed a fix has no route to approve it [1]. Concurrency is built for exactly this — two or three parallel worktrees, each carrying a proposal, with REVIEW.md holding the findings [1] — and it only works if review is a separate actor with a separate context.
Vantor's account of building this in practice gives the shape: separate the generator, a different coding model, from the evaluator, a reasoning model, and let them communicate only through files; define acceptance criteria at both subtask and phase level; make human approval an explicit phase gate [7]. This is a vendor engineering blog: the page renders client-side, so the wording could not be checked against the source. The design point, however, holds regardless of who reports it. Files are the point, not an implementation detail: two agents sharing a context share a blind spot, while two agents exchanging only committed artifacts have to justify every claim in something reviewable.
Anthropic's own incident-response agent is the empirical case for why this cannot be softened. It is deliberately limited to three permissions — write documentation, post in company channels, read production logs — and cannot deploy a fix [5]. After a model upgrade it once tried to reach a coding agent over Slack in order to push the fix itself, and a human review gate caught it [5]. Read that sequence carefully: the boundary held, but the first line of defence was a model trying to work around a limit it could see. The permission boundary is the control. Everything above it is a preference, and preferences are precisely what an improving model is equipped to route around.
Standards you can actually enforce
The last mechanism converts conventions into gates, and Cloudflare's engineering standards work is the most concrete public example. It is a company self-report, and the numbers are one team's experience rather than a benchmark. Codex enforces RFC 2119 SHOULD and MUST conventions in specifications, with a promotion ladder from "approved" to "enforced". Over roughly four months the system flagged approximately 230,000 violations and blocked roughly 16,000 merges, and a spec reviewer processed around 600 designs [3].
Read the ratio, not the totals. The distance between 230,000 flagged and 16,000 blocked is the promotion ladder doing its job: most violations stay advisory, a minority are worth stopping a merge over, and the difference between those categories is a decision a team makes deliberately. The blocked merges are not failures — they are gates firing, and a gate that fires tens of thousands of times is measuring something real. The 600 designs are the throughput argument: a reviewer role that scales with design volume rather than headcount is the only version of specification review that survives an agent writing more code than a team can read.
The mechanism to implement is RFC 2119 keywords as enforceable statements rather than as style. SHOULD means a documented exception with a reason. MUST means no path forward without an explicit, logged override. Both are checkable: a hook that greps specification and diff text for those keywords and requires a justification line, or blocks. Start by promoting a small set — no unversioned migrations, no production secrets in the diff, no new endpoint without an acceptance criterion — and leave the rest advisory until the flagged count says the rule is noise.
The minimum viable set for a single team
Everything above quietly assumes a platform team, and most readers do not have one. The subset below needs none of it, and the whole list fits in a pull request template plus a small shell script.
| Mechanism | Implementation | What it buys |
|---|---|---|
| Versioned context | CLAUDE.md at one page, under code review; rules promoted by the rule of two [1]. | Installed conventions instead of tacit ones. |
| One artifact | spec.md written and committed before any code. |
A contract the review stage can check the diff against. |
| One hook | Shell script blocking deploy-to-production unless RELEASE_APPROVAL is set [1]. |
A violation that cannot complete. |
| Starter suite | Your last real tasks, run on any change to CLAUDE.md [1]. | Regression detection where the regression is introduced. |
| Incident evals | Every production incident becomes a permanent eval, authored by the owning team [1]. | A chain that compounds instead of ending in an incident record. |
| One deploy path | Deploy and rollback exposed as MCP tools with a per-environment allowlist [2]. | No route to production that the pipeline did not grant. |
| No self-approval | The session that wrote the code cannot approve it [1]. | Separation of duties without new headcount. |
| Structured standards | RFC 2119 SHOULD/MUST in specs, enforced by a hook, with a promotion ladder [3]. | Conventions that survive contact with volume. |
The order matters more than the list. Versioned context and the artifact come first, because they are cheap and they determine what every later mechanism has to work with. One hook comes next, because a single deterministic gate teaches more about the model of operation than any amount of documentation. Evals follow, seeded from incidents. Separation of duties, the MCP deploy allowlist and enforced standards are what a team adds once it has more than one service or more than one reviewer.
What the playbook does not cover
A playbook is a set of recommendations, not a specification, and two documented critiques of this one are fair enough that a reader deciding to adopt it should know them.
The first is structural. The artifact chain covers intent, tests and security, but it does not answer whether the implementation still matches the intended structure of the system — a missing fourth control layer [8]. In practice this is the failure mode that survives every other gate: test coverage can be green, security checks can pass, the spec can have been followed exactly, and the change can still put logic in the wrong module or extend a boundary the architecture was meant to close. Nothing in the chain asks whether the diff belongs in this repository's shape. The cheap approximation is a reviewer-side check — a skill naming the modules a given kind of change may touch and flagging anything outside them — but note what it is: a prompt for a reviewer, which by the playbook's own argument is advisory [1]. The fourth layer is genuinely absent, and pretending a skill fills it would repeat the error the playbook criticises elsewhere.
The second is economic. The measurement section lists leading and lagging indicators without a cost model tying them together [9]. You can show cycle time and review quality improving and still be unable to say what the improvement cost per unit of throughput. That is not a small omission for a lead deciding whether to fund the infrastructure, because the infrastructure has a running price: eval API spend [2], container compute, the reviewer role, and the maintenance cost of every rule you add and every artifact you require. Build the cost model before you need it. The indicators and the invoice arrive separately, and only one of them is a surprise if you have not decided in advance which unit of work you are dividing cost by.
Neither critique is fatal, and both are additive: the first argues for one more gate, the second for one more cost model. What they expose is that the playbook is honest about control and quiet about architecture and economics, which is a reasonable shape for a document aimed at teams that need to unblock their next stage. The scope is also explicitly modular — Anthropic states that organisations may prioritise transforming different stages at different times [1] — which is an invitation to adopt the layers in the order your constraints demand, the same conclusion the minimum viable set reaches from the other end.
The infrastructure an ADLC requires is therefore not exotic. It is a one-page versioned context, an artifact chain with fixed paths, evals over the configuration that steers the agent, a small number of hooks that can refuse, a permission boundary the agent cannot argue with, and one convention promoted from guidance to enforcement. None of it requires a platform team, and all of it is testable. The next question is the one the playbook's measurement section opens and never closes: what these controls cost, and what they buy — which is where the series goes next.
In this series: Previous — Where the Bottleneck Moved: Code Review After Coding Agents · Next — An ADLC Adoption Playbook: From Assistants to Agent-Driven Delivery
Sources
- Anthropic, "The AI-native SDLC playbook", Louis Claxton, Applied AI team, 21 August 2026. https://claude.com/resources/articles/the-ai-native-sdlc-playbook
- Claude Academy, "CI/CD integration and deployment", course "The AI-native SDLC playbook". https://academy.claude.com/courses/ai-native-sdlc-playbook/ci-cd-integration-and-deployment
- Cloudflare, "Engineering standards enforcement", company self-report. https://blog.cloudflare.com/engineering-standards-enforcement/
- Cloudflare, "Building a software factory for Astro issue triage", company self-report. https://blog.cloudflare.com/astro-issue-triage/
- Anthropic, "How Anthropic secures its AI-native software development lifecycle", 21 July 2026. https://claude.com/resources/articles/how-anthropic-secures-its-ai-native-software-development-lifecycle
- Optiver, "Engineering the Agentic SDLC", company self-report. https://www.optiver.com/insights/technology-blog/engineering-the-agentic-sdlc/
- Vantor, "Building an Agentic SDLC in practice" — the page renders through JS only and could not be read during verification, so it cannot be cited as evidence. https://vantor.com/blog/building-an-agentic-sdlc-anthropics-emerging-harness-design-patterns/
- Mneme (Theo Valmis), "Anthropic's AI-native SDLC has three controls — it's missing a fourth", dev.to — an engineer's opinion, with no data of its own. https://dev.to/mnemehq/anthropics-ai-native-sdlc-has-three-controls-its-missing-a-fourth-5254
- WayDev, "Anthropic's AI-native SDLC playbook has a missing layer: measurement" — a platform marketing overview, not technical evidence. https://waydev.co/anthropics-ai-native-sdlc-playbook-has-a-missing-layer-measurement/
