Doctrine Compounds. Models Don't.

---

In six months, I replaced my team's brain eight times. Nobody noticed.

Eight frontier models between February and July — I counted them when I graded the half-year. Each swap took one line of configuration and zero meetings. No onboarding, no knowledge transfer, no goodbye card. And the reason nobody noticed is the whole subject of this post: nothing that makes my team work lives in the model anymore. The briefs, the rules, the guardrails, the context — all of it lives in the repository, versioned, reviewed, and enforced. The model stopped being a miracle. It became a dependency.

The model is a dependency

Treat that sentence literally, not rhetorically. A dependency is something you pin to a version, upgrade deliberately, and expect to be deprecated. Model vendors now guarantee as little as sixty days of deprecation notice; effective lifecycles have compressed to months. Whatever you build that lives inside a specific model's behavior — the prompt tricks, the workaround for last quarter's weakness — depreciates on the same schedule. You are not investing when you tune to a model. You are renting.

A model is replaced with one line of configuration. A doctrine takes years to rebuild.

The Bitter Lesson, taken seriously

There is a serious objection here, and it deserves to be stated at full strength. Richard Sutton's Bitter Lesson, applied to agents, says every scaffold is a bet against the next model: the elaborate orchestration you hand-roll today is exactly what the next release absorbs, and the harness builders themselves have deleted large parts of their scaffolding at each generation. That critique is correct — about procedural scaffolding. Hand-written control flow, orchestration logic, prompt choreography: that layer depreciates with the models, and we have thrown ours away more than once.

But it does not touch the other layer. No model release will ever ship knowing that in our product, a specific field is locked after signature for legal reasons — the same locked field that trapped the generated story in the previous post, and that is no coincidence. That fact is not intelligence; it is our system. The declarative layer — decisions, constraints, domain rules, acceptance criteria — is knowledge no amount of model progress makes obsolete, because no vendor has it. The thesis of this post is deliberately narrow: procedural scaffolding depreciates like models do. What compounds is declarative, machine-checked doctrine.

What agents read before touching code

Concretely, on Solstice*, an agent does not start from a blank prompt. There is an official reading order, written down: the root context file, then the ADRs, then the context file of the subsystem it is about to touch, then the domain rules, the design rules, the security rules. The corpus behind that order, as of late July: 59 ADRs that agents must read before any structural change. 134-plus enforceable rules, each linked to the acceptance criteria of the spec it serves, each enforced by blocking CI — no rule drifts silently. That, at least, is what the method claims about itself; hold that sentence. 23 anti-drift check scripts. 47 packaged skills. 42 context files: one at the root, one per subsystem, each documenting the service's role, its applicable ADRs, its local conventions.

Two details in that list tell you where this is going. The pre-PR gate renders a PASS/FAIL verdict whose JSON output is explicitly written to be parsed by an agent — the machine writes for the machine. And one guardrail watches the context layer itself: when a folder's code changes, it reminds you to update the folder's context file. The doctrine documents the system; a check checks the doctrine. Turtles, but useful turtles.

None of this is a new idea. My regulated industry has run compliance as code for years: policy written as text nobody reads becomes policy written as rules a pipeline enforces. And the ADR revival in the agent era has a one-sentence justification I have watched come true: an agent that cannot see why the code has the shape it does will refactor the reason away. The retry logic that looks redundant, the naming that looks legacy — an agent deletes in seconds what took an incident to learn. The ADR is how the incident stays learned.

I buried the SDLC. Then I wrote 134 rules.

Now the paragraph I owe you. My first post in this series declared the SDLC dead: the process was always waste, ceremony is what you do when you don't trust your tools. A hostile reader writes the tweet in ten seconds: he killed the SDLC and rebuilt it in YAML.

Yes, I rebuilt a process. The promise was never "no process". It was "no process that burns human hours without verifying anything".

Here is the test, and it is falsifiable. A ceremony consumes human time at every occurrence and verifies nothing: the estimation meeting, the sign-off, the status update — hours per week, forever, and none of them ever caught a regression. A compiled constraint consumes zero marginal human time and verifies every time: the rule runs in seconds, blocks deterministically, and never gets tired on a Friday afternoon. The old process taxed humans to produce a feeling of control. The doctrine taxes machines to produce actual control. And the day one of our rules requires a meeting to interpret, it has become a ceremony again — and it must die.

I will even hand over the receipts: the March post already praised the agent that "validates against architectural constraints". The doctrine is that sentence, industrialized. What died was not process. What died was process aimed at people.

One flank stays open, and I would rather name it than have it named for me. A doctrine that only ever accretes is the new waste — 134 rules in four and a half months extrapolates to a number I refuse to type. Pruning has started where it was cheapest: four skills were deleted from the bundle when models made them native. Rules deleted so far: zero. That is the open flank. Quote it back at me.

The inventory that stings

Late July, we inventoried our own method — every file, every script, every claim the method makes about itself. The verdict earns its own section.

Four findings, in full, because a confession only counts itemized:

• agent files still describing the old framework, months after the migration;
• a script documented as "blocking in PR", wired nowhere;
• the context-freshness guardrail: advisory, it never blocks;
• the local gate, a strict subset of CI — a local PASS guarantees nothing.

The honest reading, and I will not spin it: the layer that executes held. The layer that describes rotted, silently, for months — and it was a manual audit, unscheduled and late, that caught it. A smoke detector tested once, after the smell. The files still described the frontend framework we migrated away from mid-flight; one instruction layer got updated, the others did not. Nothing failed, because nothing executes a description. Code that is wrong breaks a test. A context file that is wrong breaks an agent silently, three weeks later, inside a PR that looks plausible.

Doctrine compounds only where it executes.

The audit also put a number on who pays. 85.4% of the commits on Solstice carry my name — a bias the method deck itself acknowledges. The doctrine exists partly to reduce the team's dependency on its tech lead. Today it is written, and maintained, mostly by the tech lead. That is not a paradox; it is a maintenance contract signed with the future team, and it costs real senior time every week. But it means the bus-factor mitigation is half built: if I left tomorrow, the team would inherit a corpus that is mostly right without knowing which parts lie — arguably worse than nothing, because agents execute the stale parts with full confidence. The fix is known and unglamorous: the freshness guardrail must become blocking — it is on the roadmap — and the inventory must become a ritual, not an accident.

Last caveat, against myself. All of this grew on a greenfield platform with one very senior engineer holding most of the pen. On the legacy code most of us maintain, my own measured gain stays at or under 10%, and doctrine there mostly records the archaeology — it compounds slower, because half the decisions were made by people who left. Read this post as a data point from near-ideal conditions, not a method that transfers as-is.

What still belongs to humans

Deciding which rules exist. The machine enforces a decision. It does not make one.

Deleting rules. Pruning is a judgment call, and it is the difference between doctrine and bureaucracy. Nobody automates the courage to remove a gate.

Arbitrating when doctrine and judgment conflict. A rule says no; the person who knows the domain says this case is different. Someone signs that override — the judgment post is about exactly who.

Knowing which document to distrust. Until freshness is enforced, that knowledge is tribal — and tribal knowledge is the thing this whole edifice was supposed to replace.

And the usual clarification, because this series has a rule about it: none of this argues for fewer people — the full argument is in the judgment post. An asset nobody maintains is a liability with good branding.

Monday morning

1. Inventory your doctrine before writing more of it. Every instruction file, every check, every claim your method makes about itself. What you find will reorder the rest of this list.
2. One root context file agents actually read. Current stack, current architecture, one page. Wrong context is worse than no context.
3. Five rules maximum, every one wired to a check that blocks. A rule in prose is a wish with a version number. Zero unwired rules, from day one.
4. ADRs only for decisions someone already re-litigated once. That is the signal the reason needs writing down before an agent refactors it away.
5. Make the freshness gate blocking before the corpus grows. "Context file touched when its folder's code changes" costs nothing at five files and everything at forty-two.
6. The meeting-to-rules pipeline last. The one that turns the weekly workshop into minutes, rules and issues — described in the judgment post. It is the compounding engine, but only once the five points above hold.

Read the rest of the series: The SDLC Is Dead — the post this one partially answers. Coding Was Never the Job — what the engineer becomes when syntax disappears. AI Became a Team Reflex — what an AI-native team looks like on a Tuesday. DORA Just Confirmed What My Team Already Lived — the amplifier, measured. 100% Agent-Written — the six months the eight models span. The Backlog Was Never the Job — who signs when doctrine and judgment disagree. The Tests Passed. Nothing Happened. — the defect that has no symptom, and what catches it instead of reading. The Skill Was Real. The Seat Wasn't. — where the rules live once the role that used to own them merges into another one.

---

Sources

• Anthropic — Effective context engineering for AI agents: the lab's own framing of context as an engineered asset. A vendor with an interest in you investing in its harness — read it as "the lab says so too", not as proof.
• AGENTS.md: the cross-vendor agent-context convention, donated to the Linux Foundation's Agentic AI Foundation in late 2025. Adoption counts come from the spec's promoters.
• actual.ai — Agent-optimized ADRs: the "agent refactors the reason away" failure mode. Practitioner writing, not peer review.
• Context rot in AI-assisted development (preprint): stale references measured in repository config and context artifacts. A preprint — direction, not decimals.
• Richard Sutton — The Bitter Lesson and its agent-framework application: the strongest objection to this post, cited on purpose. It wins against procedural scaffolding; the declarative layer is the rebuttal.
• Policy-as-Prompt (arXiv): policy-as-code extended to agent governance — the lineage this post claims.
• Solstice* — the method deck and the late-July inventory: the counts (59 ADRs, 134+ rules, 23 scripts, 47 skills, 42 context files), the 85.4% commit concentration the deck itself flags as a bias, and the four drift findings. Internal documents, no links: the codename is fictitious and the real project, its products and its vendor are anonymized.