---
titel: "Guardrails for AI coding agents: rules the run must pass, not advice it may ignore"
adresse: https://anvil-coder.tech/en/blog/guardrails-for-ai-coding-agents
beschreibung: "Governance for AI-generated code rarely fails for lack of rules — it fails because the rules live in a wiki instead of in the run. Guardrails invert that: machine-readable rules that flow into every prompt, where a violation stops a result instead of becoming a review footnote."
sprache: en
---

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](https://anvil-coder.tech/en/guardrails), 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:

```text
#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](https://anvil-coder.tech/en/blog/architekturvorgaben-im-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](https://anvil-coder.tech/en/blog/aufsicht-ist-keine-alles-oder-nichts-frage), 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](https://anvil-coder.tech/en/guardrails) 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](https://docs.anvil-coder.tech/docs/guardrails) (in German) walks through the editor, the rule patterns and the proposal inbox.

## Try it yourself?

The free tier needs no conversation, registration currently goes through a waitlist — create a project, pull an epic, review the result in your own repository.

[Start for free](https://app.anvil-coder.tech/register)[Book a demo](https://anvil-coder.tech/en/demo)