# Anthropic's AI-Native SDLC Has Three Controls. It's Missing a Fourth. > Source: > Published: 2026-08-29 11:28:02+00:00 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. 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: `CLAUDE.md` 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. 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: 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? 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. 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: Line it up next to the other three and the AI-native SDLC gets a control surface it's currently missing: 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](https://mnemehq.com/insights/ai-native-sdlc-architecture-layer/?utm_source=devto&utm_medium=post&utm_campaign=mneme_devto&utm_content=ai-native-sdlc-architecture-layer)