Sind Coding-Agenten reif für unser Team?
Wie ein guter erster Auftrag aussieht und was du sehen willst, bevor du mergst.
Der Unterschied
Das Rules-File war da. Der Agent hat genickt und daran vorbei gebaut. Bei Anvil Coder stehen deine Regeln in jedem einzelnen Prompt, und was maschinenlesbar ist, wird am Ergebnis geprüft: ein Verstoss ist ein Befund im Lauf, kein Kommentar im Review.
Freitag, 11:00, Review vor dem Release. Der Agent hat die Schichtung umgangen und direkt aus dem Controller in die Datenbank geschrieben. Die Regel stand im Rules-File. Sie stand dort auch beim letzten Mal.
Der übliche Weg ist: erst generieren, dann prüfen. Ein Linter, ein Scanner, ein Review, und was durchfällt, wird nachgebessert. Das trägt bei einzelnen Dateien. Bei einem Projekt aus hunderten parallelen Arbeitsschritten hat sich ein struktureller Fehler aus Schritt 12 bis Schritt 200 fortgepflanzt. Ihn dann zu finden ist kein Nachbessern mehr, sondern Umbauen, und der Kontext, in dem er entstand, ist längst weg. Darum prüft Anvil Coder bei jedem Schritt, nicht am Ende.
Die Invarianten stehen nicht in einer Dokumentation, die ein Modell gelesen haben könnte. Sie stehen in jedem Prompt, bei jedem Schritt, für jeden Stack.
Die mitgelieferten Invarianten sind die Grundausstattung, nicht die Grenze. Eine bestimmte Schichtung, ein Namensschema, ein Verbot bestimmter Bibliotheken: du hinterlegst sie als eigene Guardrails, und sie werden genauso in jeden Prompt geladen wie die mitgelieferten. Hinterlegst du eine Regel maschinenlesbar, wird sie zusätzlich am Ergebnis geprüft; als Prosa wirkt sie im Prompt.
Aus dem laufenden Betrieb sammelt das System ausserdem Vorschläge für neue Guardrails. Angewandt wird davon nichts von selbst: der einzige Weg in den Katalog führt über deine 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.
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 nicht zu einem Projekt, schwächst du sie mit einer Begründung ab oder schaltest sie befristet aus, wo die Regel das zulässt. Manche Regeln sind strukturell geschützt und bleiben in Kraft.
Sie ersetzen kein Review. Ein System, das jeden Schritt gegen dieselben Invarianten prüft, erzeugt konsistenten Code, nicht zwangsläufig richtigen. Ob die Anforderung stimmt, ob der fachliche Zuschnitt trägt, ob die Lösung zum Problem passt: das bleibt deine Entscheidung, und Anvil Coder ist so gebaut, dass sie bei dir bleibt. Welche Aktionen eine Freigabe brauchen, stellst du je Projekt ein.
Wie aus einer Regel im Wiki eine Regel im Lauf wird, mit Kategorien, dem#RULE-Muster und der Vorschlags-Inbox, beschreibt der ArtikelGuardrails für KI-Coding-Agenten.
Wer den Katalog prüfen muss, bevor er ihn einem Team gibt, findet hier die Fakten.
Wie ein guter erster Auftrag aussieht und was du sehen willst, bevor du mergst.
Einen Auftrag vom Tracker bis zum Draft-Pull-Request in deinem Repository verfolgen.
Aus einem Anforderungstext Epics und Stories machen, die dein Team priorisieren kann.