Anthropic's AI-Native SDLC Has Three Controls. It's Missing a Fourth.

Anthropic published an AI-Native SDLC playbook last week. Its central claim: code generation is no longer the slow part of delivery. The stages around it, planning, review, security sign-off, release, still run at human speed. Once agents write most of the diff, that mismatch has to break one of two ways: review queues grow until the speed gains disappear, or code ships under-reviewed. Neither is acceptable if you're regulated, and neither is great even if you're not.

Their fix is structural, not procedural. Every stage commits an artifact the next stage reads: intent.md, spec.md, plan.md, the diff and its tests, the PR with review findings, the incident record. The chain of commits becomes the audit trail. Human attention concentrates at the gates between stages instead of getting spent re-deriving context at the start of every one.

I think this is the right model. I also think it's missing a control surface, and the playbook's own logic points straight at the gap.

Advisory vs. deterministic

The most useful part of the playbook is a progression it lays out almost in passing. Institutional knowledge moves through four mechanisms, each stronger than the last:

1. CLAUDE.md — versioned, reviewed in PRs, read every session. Conventions, commands, known failure modes.
2. Skills — policy written once, applied broadly. In the playbook's own words: "A skill is a control, though an advisory one."
3. Hooks — the deterministic layer. "A policy that must always hold needs something deterministic behind the skill, such as a hook that blocks the action."
4. Evals and CI — configuration itself gets regression-tested; heavier checks run where latency doesn't matter.

Skills make violations rare. Hooks make them close to impossible. That's the whole distinction, and it's exactly the line a lot of "governance" tooling blurs. Retrieval and guidance raise the probability an agent does the right thing. Deterministic checks decide, before the action lands, whether it's allowed at all. When the largest agent vendor in the space tells enterprises that anything that must always hold needs a deterministic backstop, that's not a controversial claim anymore.

Where the hook model runs out

The playbook's hook examples are all path-scoped: block edits to a generated-code directory, run formatters after edits, keep credentials out of the diff. These work because the rule and the trigger are the same thing. "Never edit this directory" is a predicate over a path. A fast hook evaluates it perfectly.

Architectural decisions don't reduce to paths. A few examples of the kind of thing that actually governs a mature codebase:

• This service uses PostgreSQL, not SQLite, because of its concurrency profile.
• Domain code doesn't depend on adapters; dependencies point inward only.
• Auth flows through one boundary module; nothing else issues tokens.
• This deprecation applies to checkout, not billing yet, billing migrates next quarter.

Every one of these depends on three things at once: the decision, its scope, and the proposed action. A rule can be absolute in one subsystem and irrelevant in another. A newer decision can supersede an older one for part of the codebase but not all of it. That's not instruction-following anymore, it's evaluation: given this change, which recorded decisions apply, and what do they require?

ADRs are already the right artifact

Most teams already write these decisions down as ADRs. The playbook's artifact chain gives them a natural home, they're committed artifacts like everything else in the loop. What turns an ADR from documentation into governance is compiling it into something a machine can evaluate against a proposed change.

Two things matter more than the pipeline steps themselves:

Retrieval helps the agent. Retrieval doesn't decide. Surfacing the relevant architectural guidance before generation is genuinely useful, and skills are good at it. But similarity search is the wrong arbiter of applicability. If two ADRs touch the same subsystem and one supersedes the other, the newer one has to win every time, not just when its embedding happens to rank higher. Applicability has to be resolved deterministically, with precedence, and retrieval feeds context into that resolution rather than casting the deciding vote.

Every verdict produces evidence. Because the check runs before the action, not after, the record shows which decision was evaluated, what the change proposed, and why it was allowed or blocked. That's what turns drift prevention from an aspiration into a mechanism: drift gets caught at the proposal, not discovered in a postmortem three sprints later.

Hooks are the enforcement point, not the policy

The playbook gets the execution primitive right. Hooks fire before an action completes, can allow, ask, or block, and should stay fast and scoped. That's exactly where enforcement belongs. But a hook answering "is this allowed" still needs something upstream answering "which rule applies, and why."

That upstream layer can't live in a single prompt, session, or agent product, for three reasons:

• Persistence. A rule encoded in a prompt dies with the session. The same rule encoded as structured policy survives every session after it.
• Harness independence. Nobody runs one agent forever. If your architectural policy is coupled to one harness's hook format, every migration silently orphans your decisions.
• Governance semantics. Supersession, scoping, exceptions with expiry, a queryable record of which decision produced which verdict, these are real modeling problems, not string matching in a shell script.

The fourth control

Line it up next to the other three and the AI-native SDLC gets a control surface it's currently missing:

• Intent controls what should be built.
• Tests control whether the change works.
• Security controls whether the change is safe.
• Architecture controls whether the implementation still matches the system's intended structure.

The playbook even gestures at why this can't stay informal: in its section on parallel sessions, it notes that controls increasingly have to come from shared configuration in the repo, because no engineer can personally supervise every concurrent agent stream. That's a great start for operational policy. Architectural policy, with deterministic applicability and precedence, is the same idea finished.

This isn't a knock on the playbook, it's about as strong an endorsement of the enforcement-in-the-loop model as you'll find from outside the category. It concedes every premise an architecture control needs: some policies must always hold, advisory mechanisms can't guarantee that alone, deterministic checks belong in front of the action, and controls have to scale through shared configuration instead of individual supervision.

So the move for teams adopting this model is additive, not adversarial. Keep the artifact loop. Use skills for institutional knowledge and hooks for operational guardrails. Then compile your ADR corpus into structured, scoped, precedence-aware constraints, resolve them deterministically against every proposed change, and let the verdict drive whichever enforcement point your harness gives you. The lifecycle got rebuilt around committed intent. Architecture is the part of that intent nobody's finished enforcing yet, we're building Mneme around closing that specific gap.

Full writeup with the diagrams: The Architecture Layer the AI-Native SDLC Needs