The architecture layer the AI-native SDLC needs

On August 21, Anthropic published the AI-Native SDLC playbook, a stage-by-stage guide to rebuilding the software development lifecycle around agentic coding. It is the most detailed vendor description yet of what we have called the AI SDLC: build time collapsing, process rebuilt as a loop of committed artifacts, and governance moving from human-speed review into the agent's execution loop.

The playbook is right, and teams should extend it rather than argue with it. But read closely, it describes execution primitives and leaves one layer open. Architecture is present in the playbook as knowledge: conventions live in CLAUDE.md, API design standards become skills. What the playbook does not yet describe is architecture as its own governance layer: recorded architectural decisions, compiled into machine-readable constraints, resolved against each proposed change before it lands.

That distinction is the subject of this article. Documentation tells the agent what the architecture is. Guidance helps the agent follow it. Enforcement determines what the agent is actually allowed to do. Anthropic provides the first two and the primitive for the third. The policy layer that decides, deterministically, which architectural rule applies to a given action is still missing from the picture, and building it is the natural next step for any team following the playbook.

The control model has to change

Anthropic's opening argument deserves a short summary because it matches what we have argued all year. Code generation is no longer the slow part of delivery. The stages around it still run at human speed: planning rituals, review queues, security sign-off, release committees. Controls sized for human output stop matching reality once agents write most of the diff. Either review queues grow until the gains evaporate, or code ships under-reviewed, and regulated organizations cannot accept either outcome.

Their answer is structural. Each stage of the lifecycle ends by committing an artifact the next stage reads: intent.md, spec.md, plan.md, the diff and its tests, the PR with its review findings, the incident record. The chain of commits is the audit trail. Human attention concentrates at the gates between stages instead of being spent starting each stage from scratch.

This is the right model, and it is worth saying plainly: a major lab publishing an enterprise playbook that treats governance-as-artifacts and enforcement-in-the-loop as the default posture is validation of the category, not competition for it. The interesting question is what the model still needs.

From instructions to controls

The most useful part of the playbook is a progression it presents almost casually. Institutional knowledge moves through four mechanisms, in increasing order of strength:

1. CLAUDE.md. Versioned, reviewed in PRs, read at the start of every session. Conventions, commands, known mistakes. We have argued before that an instruction surface is not a governance layer; the playbook agrees implicitly, keeping the file under a page and framing it as context, not control.
2. Skills. Policy written once, applied broadly, updated centrally. The playbook's own words: "A skill is a control, though an advisory one." Skills make violations rare. Nothing forces a session to comply.
3. Hooks. The deterministic layer. Again quoting: "A policy that must always hold needs something deterministic behind the skill, such as a hook that blocks the action." The skill makes violations rare; the hook makes them close to impossible.
4. Evals and CI. Configuration itself gets regression-tested, and heavier checks run at commit or PR time where latency does not matter.

Advisory versus deterministic is the exact distinction our whole category rests on. Retrieval and guidance raise the probability that an agent does the right thing. Deterministic checks decide, before the action lands, whether it is permitted. When the largest vendor in the space tells enterprises that anything that must always hold needs a deterministic backstop, the argument for deterministic enforcement stops being ours to make alone.

Architecture creates a harder control problem

The playbook's hook examples are operational, and they map cleanly onto file-scoped logic:

• Block edits to protected paths such as generated classes or a frozen package.
• Run formatters and linters after edits so drift never accumulates.
• Keep credentials out of the diff.

These share a property: the rule and the trigger coincide. "Never edit this directory" is a predicate over a path. A fast, scoped hook evaluates it perfectly.

Architectural decisions do not reduce to paths. Consider the constraints that actually govern a mature system:

• This service must use PostgreSQL, not SQLite, because of its concurrency profile.
• Domain code must not depend on adapters; dependencies point inward only.
• Authentication flows through one boundary module; nothing else may issue tokens.
• This deprecation decision applies to the checkout subsystem but not yet to billing, which migrates next quarter.

Each of these is contextual. Whether a rule applies depends on three things at once: the decision, its applicability scope, and the proposed action. A rule can be absolute inside one subsystem and irrelevant in another. A superseding decision may reverse an older one for part of the codebase. The control problem stops being instruction-following and becomes evaluation: given this change, which recorded decisions apply, and what do they require?

Nothing in the playbook contradicts this. Its examples simply start where the mapping is easy. The hard and valuable case is the one where the predicate lives in a decision corpus rather than in a glob pattern.

From ADRs to executable architecture policy

Teams already record these decisions, usually as architecture decision records. The artifact chain in the playbook gives ADRs a natural home: they are committed artifacts like everything else. What turns them from documentation into governance is compilation into a form a machine can evaluate:

Two properties of this pipeline matter more than its steps.

Retrieval helps the agent, but retrieval does not decide. Delivering the relevant architectural guidance to the agent before generation is genuinely useful, and the playbook's skill-and-context machinery is good at it. But similarity is the wrong arbiter of applicability. If two decisions touch the same subsystem and one supersedes the other, the newer one must win every time, not just when its embedding happens to rank higher. Applicability resolution has to be deterministic and precedence-aware, with retrieval feeding context rather than casting the deciding vote. We have covered this failure mode in depth for governance-by-retrieval; the same argument applies inside an otherwise well-designed SDLC loop.

Every verdict produces evidence. Because the check ran before the action, the record shows which decision was evaluated, what the proposed change was, and why the gate allowed or blocked it. That evidence slots directly into the audit trail the playbook builds from committed artifacts. This pre-generation discipline is what turns architectural drift prevention from aspiration into mechanism: drift is prevented at the proposal, not discovered in the postmortem.

Hooks are the enforcement point, not the policy model

The playbook identifies the right execution primitive. Hooks fire before actions complete, can allow, ask, or block, and are correctly specified as fast and scoped to the action being taken. For the enforcement point in the diagram above, a hook is exactly the right place to stand.

A hook answers whether the action is permitted. Something still has to answer which rule applies, and why.

An enterprise running hundreds of parallel agent sessions needs a persistent answer to that question, and the answer cannot live in any single prompt, session, or agent product. Three reasons:

• Persistence. Architectural authority must outlive individual sessions. A rule encoded in a prompt dies with the session; the same rule encoded as structured policy survives every session that comes after it.
• Harness independence. Teams do not run one agent forever. Today Claude Code, tomorrow a mix that includes other agents. If the architectural policy model is coupled to one harness's hook format, every migration silently orphans your decisions. The policy layer should sit above the harness and feed verdicts down, whatever the harness is.
• Governance semantics. Supersession, scoping, exceptions with expiry, and a queryable record of which decision produced which verdict are governance concerns. They deserve a real model, not string matching in a shell script.

This is the practical difference between a rules file and a decision system, and it is why ADRs become guardrails only when machines can evaluate them. The hook stays thin and fast, exactly as the playbook specifies. The policy layer does the evaluation and hands down a verdict. CLAUDE.md tells the agent the rules; this layer enforces the ones that must hold.

The architecture control plane

Assemble the pieces and the AI-native SDLC acquires its fourth control surface:

• Intent controls what should be built (intent.md, spec.md, plans).
• Tests control whether the change works (feedback loops, evals, CI).
• Security controls whether the change is safe (permission modes, sandboxing, secrets policy).
• Architecture controls whether the implementation remains consistent with the system's intended structure.

The playbook itself points at why this fourth surface cannot stay informal. In its section on parallel sessions it observes that controls increasingly have to come from shared configuration in the repo, because no engineer can supervise every concurrent stream personally. Shared configuration that expresses operational policy is a great start. Shared configuration that expresses architectural decisions, with deterministic applicability and precedence, is the completion of the same idea.

The strategic point sits in the last line of the diagram. The architectural decision is compiled once and enforced everywhere. Agents change; the architecture survives the change.

Conclusion

Anthropic's playbook is unusually useful evidence for this category because it concedes every premise the enforcement layer needs: some policies must always hold, advisory mechanisms alone cannot guarantee them, deterministic checks must sit in front of the action, and controls must scale through shared configuration rather than individual supervision. Those premises are exactly the foundation an architecture policy layer builds on.

So the move for teams adopting the AI-native SDLC is additive, not adversarial. Keep the artifact loop. Adopt skills for institutional knowledge and hooks for operational guardrails. Then compile your ADR corpus into structured, scoped, precedence-aware constraints, resolve them deterministically against each proposed change, and let the verdict drive whatever enforcement point your harness provides. The playbook rebuilt the lifecycle around committed intent. Architecture is the part of that intent whose enforcement is still waiting to be built.

FAQ

Related reading

• What Is the AI SDLC?
• Spec Kit Defines the Plan. Who Enforces the Architecture?
• Claude Code Skills and Organizational Knowledge
• How AI Coding Agents Use ADRs
• Why CLAUDE.md Stops Scaling
• Concept: AI-Native SDLC
• Concept: Architectural Drift Prevention