Quality as a condition, not as inspection

Why checking at the end is too late

The usual way is the other way around: generate first, check afterwards. A linter, a scanner, a review — and whatever fails gets reworked. That works for individual files.

For a project that emerges from hundreds of parallel work steps, it stops working. A structural mistake that arises in step 12 has propagated by step 200. Finding it then is no longer rework but rebuilding — and the context in which it arose is long gone.

What gets injected

The invariants do not live in documentation a model might have read. They live in every prompt.

OWASP Top 10

The ten most common security mistakes in web applications — as a rule up front, not as a checklist at the end.

SOLID

Five principles of object-oriented design that keep a class from serving too many masters.

KISS

The simplest solution that solves the problem — not the most elegant one somebody could build.

DRY

The same decision lives in one place. Copies drift apart, and they do so silently.

Clean Code

Names that say what they mean; functions that do one thing; comments that explain the why.

Your own guardrails

The invariants that ship with the system are the baseline, not the limit. A team that wants to enforce its own architecture rules — a particular layering, a naming scheme, a ban on certain libraries — stores them as its own guardrails. They are injected exactly like the built-in ones. Whoever wants one of them additionally validated by machine stores it as a machine-readable rule; as mere prose it acts in the prompt, but not in validation.

In the hosted service the system also collects suggestions for new guardrails from live operation. None of them is applied by itself: the only way into the catalogue is a human approval.

This is the point where architecture governance stops being a document nobody reads and starts being a property of the system.

What guardrails do not do

They do not replace review. A system that checks every step against the same invariants produces consistent code — not necessarily correct code. Whether the requirement itself is right, whether the domain slicing holds, whether the solution fits the problem: that remains a human decision. Anvil Coder is built so that it stays possible: which actions need an approval is something you configure per project — without a configured level, the order runs straight through.