2026-09-02

Guardrails für KI-Coding-Agenten: Regeln, die der Lauf bestehen muss

Fast jedes Team, das KI-Agenten Code schreiben lässt, hat Regeln: ein Architektur-Wiki, eine Checkliste fürs Review, ein Dokument mit Namenskonventionen. Und fast jedes Team macht dieselbe Erfahrung: der Agent kennt diese Regeln nicht — oder kennt sie und gewichtet sie weg, sobald der Kontext lang genug ist. Governance, die nicht im Wiki steht, war der Grund, Guardrails bei Anvil Coder als eigenen Mechanismus zu bauen und nicht als Absatz im Prompt.

Eine Regel ist hier ein Objekt, kein Absatz

Ein Guardrail ist eine verbindliche Regel, die in jeden KI-Prompt einfliesst — beim Schreiben von Code genauso wie beim Prüfen eines Ergebnisses. Jede Regel gehört zu einer von vier Kategorien — Sicherheit, Code-Qualität, Architektur, Compliance — und hat eine Geltungsebene: global, Organisation oder ein einzelnes Projekt. Zusätzlich zu den eigenen Regeln bringt der Dienst einen versionierten Grundstock mit: bewährte Sicherheits- und Qualitätsregeln, die für jedes Projekt gelten, ohne dass jemand sie anlegen muss. Fünf Invarianten sind dabei immer gesetzt: die OWASP Top 10, SOLID, KISS, DRY und Clean Code — als ständige Begleiter jedes Laufs, nicht als Empfehlung.

Prosa für die KI, Muster für die Durchsetzung

Der Unterschied zwischen einem Hinweis und einem Gate liegt in einer Zeile. Die Instruktion eines Guardrails ist zunächst freier Text, der der KI mitgegeben wird. Durchsetzbar wird sie mit einem Muster:

#RULE: forbid <Muster>
#RULE: require <Muster>

forbid markiert einen Treffer als Verstoss — etwa kein console.log im Produktivcode. require verlangt einen Treffer — etwa dass jede neue Route einen Test braucht. Optional gilt eine Regel nur für bestimmte Dateipfade. Der Punkt dieser Zweiteilung: die Prosa macht die KI besser, das Muster macht das Ergebnis prüfbar. Ein Verstoss ist dann kein Review-Kommentar, sondern ein Befund im Lauf selbst — bevor ein Mensch Zeit investiert. Wie Vorgaben als Bedingungen in jeden Arbeitsschritt einfliessen, beschreibt auch der Artikel über Architekturvorgaben im Prompt.

Lernen ja — aber nichts wirkt ungeprüft

Guardrails sind kein statisches Regelwerk. Der Dienst lernt aus abgeschlossenen Läufen: zeigt sich wiederholt derselbe Stolperstein, schlägt er ein neues Guardrail vor, ein bestehendes zu schärfen oder eines stillzulegen, das seinen Zweck erfüllt hat — jeweils mit der Beobachtung, auf der der Vorschlag beruht. Diese Vorschläge landen in einer Inbox, und dort bleiben sie, bis ein Mensch entscheidet: Übernehmen macht daraus eine aktive Regel, Ablehnen verwirft sie. Ungeprüft wirkt kein Vorschlag. Das ist dieselbe Haltung wie beim Merge: Aufsicht ist eine Einstellung, keine Alles-oder-nichts-Frage.

Was Guardrails nicht sind

Zwei ehrliche Grenzen. Erstens: Guardrails prüfen gegen benannte Regeln — sie ersetzen kein Review. Ob eine fachliche Entscheidung richtig ist, ob ein Schnitt sinnvoll ist, bleibt Urteilsarbeit des Teams; die Guardrails-Seite sagt das ausdrücklich. Zweitens: eine Regel wirkt ab dem nächsten Lauf — rückwirkend heilt sie nichts. Wer den Mechanismus selbst einrichten will: das Kapitel Guardrails in der Dokumentation führt durch Editor, Regel-Muster und die Vorschlags-Inbox.