2026-09-02

Guardrails for AI coding agents: rules the run must pass, not advice it may ignore

Almost every team that lets AI coding agents write code has rules: an architecture wiki, a review checklist, a document full of naming conventions. And almost every team makes the same discovery: the agent does not know those rules — or knows them and weighs them away once the context grows long enough. Governance that does not live in a wiki is the reason guardrails at Anvil Coder are a mechanism of their own, not a paragraph in a prompt.

A rule is an object here, not a paragraph

A guardrail is a binding rule that flows into every AI prompt — when code is written and when a result is checked. Each rule belongs to one of four categories — security, code quality, architecture, compliance — and has a scope: global, organisation, or a single project. On top of your own rules the service ships a versioned base set: proven security and quality rules that apply to every project without anyone creating them. Five invariants are always on: the OWASP Top 10, SOLID, KISS, DRY and Clean Code — constant companions of every run, not recommendations.

Prose for the AI, patterns for enforcement

The difference between a hint and a gate is one line. A guardrail’s instruction starts as free text handed to the AI. It becomes enforceable with a pattern:

#RULE: forbid <pattern>
#RULE: require <pattern>

forbid marks a match as a violation — say, no console.log in production code. require demands a match — say, every new route needs a test. Optionally a rule applies only to certain file paths. The point of this split: the prose makes the AI better, the pattern makes the result checkable. A violation then is not a review comment but a finding inside the run itself — before a human spends time on it. How constraints travel into every single work step is also the subject of the article on architecture constraints in the prompt.

Learning, yes — but nothing takes effect unreviewed

Guardrails are not a static rulebook. The service learns from finished runs: when the same stumbling block shows up repeatedly, it proposes a new guardrail, a sharpened one, or retiring one that has done its job — each proposal carrying the observation it is based on. Proposals land in an inbox and stay there until a person decides: accept turns one into an active rule, reject discards it. Nothing takes effect unreviewed. It is the same stance as with merging: oversight is a setting, not an all-or-nothing question.

What guardrails are not

Two honest limits. First: guardrails check against named rules — they do not replace review. Whether a domain decision is right, whether a cut makes sense, remains the team’s judgement; the guardrails page says so explicitly. Second: a rule takes effect from the next run on — it heals nothing retroactively. To set the mechanism up yourself, the guardrails chapter in the documentation (in German) walks through the editor, the rule patterns and the proposal inbox.