Guardrails for AI coding agents: instructions and checks

How Anvil Coder turns project rules into prompt instructions and executable checks, and why an instruction alone does not prove compliance.

Guardrails describe rules for an AI coding agent’s work. In Anvil Coder they combine model instructions with configurable checks. These have different limits: an instruction guides implementation, while a check detects only the cases it covers.

A rule is an object here, not a paragraph

A guardrail has an instruction, a category and a scope: global, organisation or project. Categories cover security, code quality, architecture and compliance. Alongside custom rules, a versioned base set includes guidance such as OWASP Top 10, SOLID, KISS, DRY and Clean Code.

These are constraints, not a certification. Including them in context proves neither complete security coverage nor compliance with every architecture principle. The guardrails page explains the mechanism and its limits.

Prose for the AI, patterns for enforcement

A guardrail starts as a text instruction for the AI. An instruction alone does not prove compliance. Machine-readable patterns enable additional checks:

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

forbid marks a match as a violation — say, no console.log in production code. require demands a match in the checked content. A pattern alone cannot establish that a test is meaningful or has run successfully. A rule can apply to selected file paths. A detected violation is blocking or advisory according to its severity. How constraints travel into work steps 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.