--- titel: "Guardrails" adresse: https://anvil-coder.tech/guardrails beschreibung: "Guardrails sind Invarianten, die Anvil Coder bei jedem einzelnen AI-Prompt als System-Prompt injiziert — OWASP, SOLID, KISS, DRY und Clean Code gelten damit für jeden Arbeitsschritt, nicht als Prüfung am Ende." sprache: de --- Der Unterschied # Qualität als Bedingung, nicht als Kontrolle Guardrails sind Invarianten, die bei jedem einzelnen AI-Prompt als System-Prompt injiziert werden. Sie sind damit keine Richtlinie, die jemand nachträglich prüft, sondern eine Bedingung, unter der jeder Arbeitsschritt überhaupt erst entsteht. Was gegen sie verstösst, wird nicht erst am Ende gefunden, sondern bei dem Schritt, in dem es entsteht. ## 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. ## Eigene Regeln durchsetzen? Wenn ihr bestehende Architekturvorgaben habt, ist ein Gespräch der schnellste Weg zu klären, wie sie sich als Guardrails abbilden lassen. [Kostenlos starten](https://app.anvil-coder.tech/register)[Demo vereinbaren](https://anvil-coder.tech/demo)