Anvil CoderLog in

2026-07-27

Why architecture rules belong in the prompt, not in a wiki

Most architecture rules live in a document. It gets read once during onboarding, less often after that, eventually not at all — and the deviation shows up in review, once the code is already built. Anvil Coder runs that the other way around: a rule can be part of the prompt, not just part of the wiki.

A conveyor of glowing billets passes through five luminous inspection gates — every work step passes the same guard rails

Checking at the end comes too late

The usual approach is generate first, check later — a linter, a scanner, a review, and whatever fails gets patched up. That works for a single file. It stops working for a project assembled from hundreds of parallel steps: a structural error introduced in step 12 has propagated by step 200. Finding it there isn’t a patch anymore, it’s a rebuild — and the context in which it was introduced is long gone. Guardrails invert the order: the rule sits in front of the step, not after it.

What ships by default

Injected as a system prompt are five built-in invariants — the OWASP Top 10, SOLID, KISS, DRY, and Clean Code. They don’t live in documentation a model might have read; they sit in every single prompt, at every single step, freshly.

A team’s own rules become guardrails

That’s exactly where this differs from an architecture document: a rule that only applies to one specific team — a particular layering, a naming scheme, a ban on certain libraries — can be stored as a guardrail of its own and gets injected exactly like the built-in ones. One distinction remains: as plain prose, a custom rule works inside the prompt but not in an additional automated check — for that, it has to be stored as a machine-readable rule instead. In live operation the system also collects suggestions for new guardrails from what actually happens during runs; none of them get applied on their own — the only path into the catalog runs through human approval.

Where the condition stops

None of this replaces review. A step built against the same invariants comes out consistent — not necessarily correct. Whether the requirement itself is right, whether the underlying cut of the problem holds up: that stays a human decision, and the rule in the prompt isn’t a substitute for it, only a stage before it. What it moves is where a mistake gets noticed — from the end of the chain to its beginning.