KI-Coding-Agenten beurteilen
Aufgabenumfang, Autonomie und die Nachweise für dein Review verstehen.
Der Unterschied
Guardrails geben den KI-Agenten Regeln für Sicherheit, Architektur und Codequalität vor. Anvil Coder lädt versionierte Regel-Pakete in die Prompts. Ausführbare Prüfungen können Verstösse blockieren oder melden; eine Anweisung im Prompt allein beweist noch keine Einhaltung.
Der übliche Weg ist umgekehrt: erst generieren, dann prüfen. Ein Linter, ein Scanner, ein Review — und was durchfällt, wird nachgebessert. Das funktioniert bei einzelnen Dateien.
Bei einem Projekt, das aus hunderten parallelen Arbeitsschritten entsteht, funktioniert es nicht mehr. Ein struktureller Fehler, der in Schritt 12 entsteht, hat sich bis Schritt 200 fortgepflanzt. Ihn dann zu finden ist nicht mehr Nachbessern, sondern Umbauen — und der Kontext, in dem er entstand, ist längst weg.
Die Invarianten stehen nicht in einer Dokumentation, die ein Modell gelesen haben könnte. Sie stehen in jedem Prompt.
Die fünf Invarianten oben sind ein Ausschnitt aus der Baseline — dem Teil des Katalogs, der für jeden Stack gilt, unabhängig von Sprache und Framework. Darüber hinaus bekommt jedes Projekt automatisch die Stack-Packs, die zu seiner Technologie passen: ein React/Vite-Projekt bekommt andere Regeln als eines mit Spring Boot, ohne dass jemand das von Hand einträgt. Jedes Paket ist versioniert — welche Fassung ein bereits laufender Lauf sieht, ändert sich rückwirkend nie.
Kuratiert veröffentlicht sind heute acht Stacks, von der sprachunabhängigen Baseline bis zu den verbreitetsten Frontend- und Backend-Frameworks:
Jede Regel trägt eine Schwere. Eine blockierende Regel hält den Lauf an, sobald sie verletzt wird; eine meldende erscheint als Hinweis, ohne ihn zu stoppen. Passt eine Regel im Einzelfall nicht zu einem Projekt, lässt sie sich mit einer Begründung abschwächen oder — wo die Regel das zulässt — befristet abschalten. Manche Regeln sind strukturell geschützt und bleiben unabhängig davon in Kraft.
Jede Organisation wählt zwischen zwei Update-Kanälen. Fast, der Standard, übernimmt automatisch die jeweils neueste Fassung jedes Pakets. Stableübernimmt eine neue Fassung erst, wenn wir sie ausdrücklich dafür freigegeben haben — der langsamere, bewusst nachgezogene Weg.
Der Katalog ist mit einem Ed25519-Schlüssel signiert: Jede Regel-Datei trägt einen sha256-Fingerabdruck in einem signierten Manifest, und keine Änderung am Katalog wird ohne neue Signatur wirksam. Die Regeln, die einen Lauf binden, sind damit exakt die freigegebenen — kryptographisch belegt, nicht bloss versprochen.
Die mitgelieferten Invarianten sind die Grundausstattung, nicht die Grenze. Ein Team, das eigene Architekturregeln durchsetzen will — eine bestimmte Schichtung, ein Namensschema, ein Verbot bestimmter Bibliotheken — hinterlegt sie als eigene Guardrails. Sie werden genauso injiziert wie die mitgelieferten. Wer eine davon zusätzlich maschinell validieren lassen will, hinterlegt sie als maschinenlesbare Regel; als blosse Prosa wirkt sie im Prompt, aber nicht in der Validierung.
Im betriebenen Dienst sammelt das System ausserdem Vorschläge für neue Guardrails aus dem laufenden Betrieb. Angewandt wird davon nichts von selbst: der einzige Weg in den Katalog führt über eine menschliche Freigabe.
Das ist der Punkt, an dem Architektur-Governance aufhört, ein Dokument zu sein, das niemand liest, und anfängt, eine Eigenschaft des Systems zu sein.
Sie ersetzen kein Review. Ein System, das jeden Schritt gegen dieselben Invarianten prüft, erzeugt konsistenten Code — nicht zwangsläufig richtigen. Ob die Anforderung selbst stimmt, ob der fachliche Zuschnitt trägt, ob die Lösung zum Problem passt: das bleibt eine menschliche Entscheidung. Anvil Coder ist so gebaut, dass sie möglich bleibt: welche Aktionen eine Freigabe brauchen, stellst du je Projekt ein — ohne gesetzte Stufe läuft der Auftrag durch.
Wie aus einer Regel im Wiki eine Regel im Lauf wird — Kategorien, das#RULE-Muster und die Vorschlags-Inbox — beschreibt der ArtikelGuardrails für KI-Coding-Agenten.
Aufgabenumfang, Autonomie und die Nachweise für dein Review verstehen.
Einen Auftrag durch Planung, Änderungen und die Übergabe ins Review verfolgen.
Anforderungen und Akzeptanzkriterien in bearbeitbare Tickets überführen.