Guardrails für KI-Coding-Agenten: Anweisungen und Prüfungen

Wie Anvil Coder Projektregeln in Prompts und ausführbare Prüfungen überführt — und warum eine Anweisung allein keine Einhaltung beweist.

Guardrails beschreiben Regeln für die Arbeit eines KI-Coding-Agenten. In Anvil Coder verbinden sie Anweisungen für das Modell mit konfigurierbaren Prüfungen. Beides hat unterschiedliche Grenzen: Eine Anweisung lenkt die Umsetzung, eine Prüfung erkennt nur die Fälle, die sie abdeckt.

Eine Regel ist hier ein Objekt, kein Absatz

Ein Guardrail hat eine Instruktion, eine Kategorie und eine Geltungsebene: global, Organisation oder Projekt. Kategorien sind Sicherheit, Code-Qualität, Architektur und Compliance. Neben eigenen Regeln gibt es einen versionierten Grundstock mit Leitlinien wie OWASP Top 10, SOLID, KISS, DRY und Clean Code.

Diese Leitlinien sind Vorgaben, keine Zertifizierung. Ihre Aufnahme in den Kontext beweist weder vollständige Sicherheitsabdeckung noch die Einhaltung aller Architekturprinzipien. Die Guardrails-Seite erläutert den Mechanismus und seine Grenzen.

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

Die Instruktion eines Guardrails ist zunächst freier Text für die KI. Eine solche Anweisung beweist noch keine Einhaltung. Maschinenlesbare Muster ermöglichen zusätzliche Prüfungen:

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

forbid markiert einen Treffer als Verstoss — etwa kein console.log im Produktivcode. require verlangt einen Treffer im geprüften Inhalt. Ein Muster allein kann nicht beweisen, dass ein Test fachlich korrekt ist oder erfolgreich ausgeführt wurde. Optional gilt eine Regel nur für bestimmte Dateipfade. Ein erkannter Verstoss wird je nach Schweregrad blockiert oder gemeldet. 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.