Qualität als Bedingung, nicht als Kontrolle

Warum Prüfen am Ende zu spät ist

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.

Was eingespeist wird

Die Invarianten stehen nicht in einer Dokumentation, die ein Modell gelesen haben könnte. Sie stehen in jedem Prompt.

OWASP Top 10

Die zehn häufigsten Sicherheitsfehler in Webanwendungen — als Vorgabe, nicht als Prüfliste am Ende.

SOLID

Fünf Prinzipien objektorientierten Entwurfs, die verhindern, dass eine Klasse zu vielen Herren dient.

KISS

Die einfachste Lösung, die das Problem löst — nicht die eleganteste, die jemand bauen könnte.

DRY

Dieselbe Entscheidung steht an einer Stelle. Kopien laufen auseinander, und zwar still.

Clean Code

Namen, die sagen was sie meinen; Funktionen, die eine Sache tun; Kommentare, die das Warum erklären.

Eigene Guardrails

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.

Was Guardrails nicht leisten

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, stellt ihr je Projekt ein — ohne gesetzte Stufe läuft der Auftrag durch.