AI-Native Entwicklung

Jede Anforderung einer Spezifikation trägt eine Nummer: Funktionale Anforderungen, Qualitätsanforderungen, Randfälle. Diese 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 die härtere Regel: Wenn Code etwas tut, was die Spec nicht hergibt, wird zuerst die Spec korrigiert - dann der 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 jederzeit neu erzeugt werden kann.

Das ist 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 - und lässt sich beim nächsten Mal 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 - Spezifikation, Architekturentscheidung, fertiger Code - durchläuft mindestens drei davon, und mindestens eine 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 genau 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. Erst wenn es aus einer festgelegten Rolle heraus prüft, mit dem ausdrücklichen Auftrag, Schwächen zu finden, werden die Befunde brauchbar.

Pro Aufgabe gelten fünf Selbstheilungsrunden und dreißig Minuten ohne sichtbaren Fortschritt. Danach ist Schluss: Strukturierte Zusammenfassung, Ü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 eine Regel technisch erzwingbar war, haben wir sie erzwungen statt sie aufzuschreiben. 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 schlicht nicht committen.

Der teure Fehlermodus agentischer Systeme ist nämlich nicht der falsche Code. Falscher Code fällt im Test auf. Teuer wird der Agent, der eine Sackgasse nicht als Sackgasse erkennt und weiter iteriert - 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, die messen, ob der Agent sich an die eigenen Regeln hält. Schreibt er die Spezifikation, bevor er codet? Führt er den Prüfpass aus? Nutzt er das bestehende Design-System, statt eine eigene Komponente zu erfinden? Bleibt er der festgelegten Anredeform treu?

Dazu kommen Post-Mortems, wenn die Pipeline versagt - dreimal dokumentiert. In einem Fall wurde ein Code-Review übersprungen, weil ein Hook fehlte. Die Konsequenz war nicht „künftig besser aufpassen“, sondern der Hook.

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, wird unter Druck genauso übergangen wie von einem Menschen.

Die internen Wissenssysteme des Kunden sind bewusst nicht an die AI-Werkzeuge angeschlossen. Stattdessen 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. Es kauft dafür zweierlei: Keine unkontrollierten Abflüsse aus Kundensystemen - bei personenbezogenen Daten keine Feinheit, sondern die Grundbedingung - und eine Wissensbasis, in der nur steht, was jemand geprüft hat und für den Produkt-Case relevant ist. Das spart Token.

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

Über 245 Läufe hinweg ist es genau das, was verhindert, dass ein Agent stundenlang an einer Fehlannahme weiterarbeitet. Der Abbruch ist kein Scheitern, sondern die Übergabe an die Instanz, die die Fehlannahme erkennen kann: Einen Menschen mit Kontext.

Wenn die Pipeline versagt hat, haben wir das Versagen analysiert statt es zu umgehen - mit Ursachenanalyse und einer 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 gingen fast nie in Richtung „mehr Anweisung“, sondern in Richtung „weniger Möglichkeit“. Was ein System technisch nicht zulässt, muss niemand disziplinieren.