Zwei Ebenen: Projekt-Regeln und übertragbarer Kern

Die meisten Regel-Dateien für KI-Coding-Agenten leben auf der Projekt-Ebene: eine Datei je Repository, die den Tech-Stack, die Testbefehle und die Konventionen genau dieses Projekts beschreibt. Das ist sinnvoll und inzwischen Standard. Es hat aber einen blinden Fleck — alles wird pro Projekt neu erfunden. Diese Seite handelt von der Ebene darüber.

Die Projekt-Ebene

Eine Datei je Projekt. Sie hält fest, womit gebaut und getestet wird und welche Konventionen gelten. Sie ist an dieses eine Projekt gebunden: Beim nächsten Projekt beginnt man wieder bei null. In der verbreiteten Praxis stehen eine Risikoeinstufung, eine FMEA-Pflicht oder ein Format fürs Risikoregister hier gar nicht erst zur Debatte — sie kommen schlicht nicht vor.

Die Kern-Ebene

Darüber liegt ein projektunabhängiger Qualitätskern: die Risikoeinstufung, die Pflicht zur Mini-FMEA, das Format des Risikoregisters, die Abschluss- und Abnahmeprüfung, das Verbot unbelegter Erfolgsmeldungen. Einmal geschrieben, projektneutral formuliert. Hier ist auch der Ursprung: industrielles Qualitätsmanagement — FMEA, QFD, Risikoregister — einmal auf die Arbeit mit KI-Coding-Agenten übertragen, statt in jedem Projekt neu.

Der Unterschied ist die Vererbung

Der entscheidende Punkt ist nicht das Aussehen, sondern die Herkunft. Eine Projekt-Datei leitet die Disziplin nicht jedes Mal neu her — sie erbt den Kern und ergänzt nur, was wirklich projektspezifisch ist: Stack, Testbefehl, Ablageorte. Ohne den Kern gäbe es auf der Projekt-Ebene keine Risikostufen, kein Pflichtformat fürs Register, keine FMEA-Regel. Genau das ist der Unterschied zwischen „für jedes Projekt neu ausgedacht“ und „einmal definiert, überall geerbt“.

Zwei Ebenen der Durchsetzung

Der Kern schreibt außerdem fest, wie Regeln überhaupt wirken — auf zwei Wegen. Textuell: Anweisungen, die der Agent liest und befolgen soll. Mechanisch: Prüfungen, die unabhängig vom Willen des Agenten laufen — ein Gate, das im Zweifel sperrt (fail-closed). Die Projekt-Ebene setzt beides konkret um; der Kern definiert die Zweiteilung als Prinzip. Mehr dazu im ausführlichen Hintergrund →

Warum das zählt

Weil die Disziplin mitreist. Neue Projekte starten nicht mit einem leeren Blatt, sondern mit den Leitplanken, die schon da sind. Es gibt keine Abweichung von Projekt zu Projekt, weil die Grundlage dieselbe bleibt. Und die Sprache, die der Markt für all das sucht — Audit-Trail, Eskalationspfad bei Unklarheit, deterministisches Gate, Risikoregister — beschreibt genau das, was auf der Kern-Ebene ohnehin definiert ist: eine projektunabhängige, laufende Disziplin, kein einmaliges Audit.

Am Rande: „Feuerfest“ ist der Name, den die Projekt-Ebene dem Bestehen der Abnahmeprüfung gibt. Die Prüfung selbst ist im Kern definiert; benannt und mit Nachweis versehen wird sie erst im Projekt.