KI-gestützte Entwicklung mit Quality Gates

Jede Anforderung einer Spezifikation trägt eine Nummer. Das gilt für funktionale Anforderungen, Qualitätsanforderungen und Randfälle. Die Nummern ziehen sich durch alles, was daraus entsteht: Tests, Commit-Messages, Pull-Request-Beschreibungen, Laufprotokolle. Code, der sich auf keine ID zurückführen lässt, gehört nicht ins Feature und wird entfernt.

Dahinter steht eine härtere Regel. Tut der Code etwas, was die Spec nicht hergibt, korrigieren wir zuerst die Spec und dann den Code. Andernfalls reproduziert die nächste Generierung denselben Fehler, weil die Vorlage ihn immer noch enthält. Die Spec ist der Vertrag, an dem korrigiert wird. Der Code ist Output, der sich jederzeit neu erzeugen lässt.

Darin liegt der praktische Unterschied zwischen einem Prompt und einer Spezifikation. Ein Prompt ist vergessen, sobald die Antwort da ist. Eine Spezifikation überlebt die Generierung, die aus ihr entstanden ist. Beim nächsten Mal lässt sie sich wiederverwenden, prüfen und gegen das Ergebnis halten.

Wir haben eine Bibliothek fester Prüfrollen aufgebaut: Pragmatismus, Architektur, Risiko, Datenschutz, Sicherheit, Nutzerführung, Gestaltung. Jede substanzielle Entscheidung durchläuft mindestens drei davon, ob Spezifikation, Architekturentscheidung oder fertiger Code. Mindestens eine Rolle muss kritisch besetzt sein. Welche Rollen greifen, folgt festen Regeln: Alles mit Authentifizierung zieht Sicherheit, alles mit personenbezogenen Daten zieht Datenschutz.

Diese Prüfer widersprechen sich, und das ist ihr Zweck. 57-mal war der Widerspruch so ausgeprägt, dass ein eigener Konsolidierungsschritt nötig war. Er bündelt Übereinstimmungen, Konflikte und offene Fragen zu einer Entscheidungsvorlage und entscheidet ausdrücklich nicht selbst. Entschieden hat ein Mensch.

Ein Modell, das seinen eigenen Output bewertet, bestätigt ihn. Es hat den Text gerade selbst erzeugt und hält ihn folgerichtig für plausibel. Brauchbar werden die Befunde erst, wenn es aus einer festgelegten Rolle heraus prüft und den ausdrücklichen Auftrag hat, Schwächen zu finden.

Pro Aufgabe gelten fünf Selbstheilungsrunden und dreißig Minuten ohne sichtbaren Fortschritt. Danach ist Schluss. Es folgen eine strukturierte Zusammenfassung und die Übergabe an den Menschen. Ausdrücklich untersagt ist, sich selbst neues Budget zuzuweisen oder Schleifen so zu verschachteln, dass die Zählung umgangen wird.

Wo sich eine Regel technisch erzwingen ließ, haben wir sie erzwungen und es nicht beim Aufschreiben belassen. Force-Push, das Umgehen der Commit-Hooks und der Direkt-Push auf den Hauptzweig sind auf Werkzeugebene gesperrt. Ein Pre-Commit-Hook blockiert jeden Commit an Code, zu dem kein frisches Laufprotokoll vorliegt. Wer den Prüfpass nicht dokumentiert, kann nicht committen.

Falscher Code ist bei agentischen Systemen der billigere Fehler, denn er fällt im Test auf. Teuer wird der Agent, der eine Sackgasse nicht als Sackgasse erkennt und weiter iteriert. Er tut das plausibel begründet, unermüdlich und auf Kosten, die niemand bemerkt, solange niemand hinschaut.

Für die Pipeline selbst gibt es eine eigene Prüfstrecke. Sechs Aufgaben mit automatischen Judges messen, ob der Agent sich an die eigenen Regeln hält. Sie prüfen, ob er die Spezifikation schreibt, bevor er codet, und ob er den Prüfpass ausführt. Sie prüfen außerdem, ob er das bestehende Design-System nutzt, statt eine eigene Komponente zu erfinden, und ob er der festgelegten Anredeform treu bleibt.

Dazu kommen Post-Mortems, wenn die Pipeline versagt. Dreimal haben wir eines dokumentiert. In einem Fall wurde ein Code-Review übersprungen, weil ein Hook fehlte. Als Konsequenz haben wir den Hook ergänzt und es nicht bei „künftig besser aufpassen“ belassen.

Regeln, die man einem Agenten gibt, sind Behauptungen, bis man sie prüft. Das gilt umso mehr, je länger die Anweisungsdatei wird. Was in Absatz vierzig steht, übergeht ein Agent unter Druck genauso wie ein Mensch.

Die internen Wissenssysteme des Kunden sind bewusst nicht an die AI-Werkzeuge angeschlossen. Es gilt ein Pull-Prinzip: Fehlt dem Agenten Kontext, fragt er ausdrücklich danach, und ein Mensch liefert den geprüften Auszug in die Wissensbasis des Projekts.

Das kostet Zeit, in jeder einzelnen Sitzung, und es ist die unbequemere Variante. Dafür bekommen wir zweierlei. Aus den Kundensystemen fließt nichts unkontrolliert ab, und das ist bei personenbezogenen Daten die Grundbedingung. Und in der Wissensbasis steht nur, was jemand geprüft hat und was für den Produkt-Case relevant ist. Das spart Token.

Das Iterationsbudget bricht auch Läufe ab, die kurz vor dem Ziel zu stehen scheinen. Im Einzelfall fühlt sich das jedes Mal falsch an, denn der nächste Versuch wirkt immer wie der, der es löst.

Über 245 Läufe hinweg verhindert genau das, dass ein Agent stundenlang an einer Fehlannahme weiterarbeitet. Der Abbruch übergibt an die Instanz, die die Fehlannahme erkennen kann: einen Menschen mit Kontext. Ein Scheitern ist er deshalb nicht.

Wenn die Pipeline versagt hat, haben wir das Versagen analysiert und nicht umgangen. Dazu gehörten eine Ursachenanalyse und eine Maßnahme, die den Fehler strukturell unmöglich macht. Aus einem übersprungenen Code-Review wurde ein Hook, aus einem ignorierten Pfad eine Prüfung vor dem Commit.

Bemerkenswert ist die Richtung dieser Korrekturen. Sie liefen fast nie auf „mehr Anweisung“ hinaus, in aller Regel auf „weniger Möglichkeit“. Was ein System technisch nicht zulässt, muss niemand disziplinieren.