Am 11. September hat ein Plan-Review im KI-Leitstand 252 Züge, 14,7 Minuten und rechnerisch 22 Dollar gebraucht. Am Ende stand aber kein Ergebnis. Fünf Funde „zur Entscheidung“, kein Marker, die Nacht war vorbei. Drei der fünf Funde betrafen die Form des Dokuments: eine veraltete Zeilenangabe, das Wort „grün“ in der Verifizierung, ein Satz über Mocks. Die anderen zwei waren kleine technische Entscheidungen, die ich beim Lesen in drei Sekunden treffe.

Das war leider der Normalfall, bis dahin war kein Nachtlauf der Planerzeugung einfach nur so durchgelaufen, die Implementierung aber schon. Deshalb baue ich das claude-workflow-kit gerade von Grund auf neu.

Was im Whitepaper stand

Mein Whitepaper beschreibt neun Schritte und drei Stop-Punkte. Ein Modell-Review kommt darin genau einmal vor: Modell A implementiert, Modell B reviewt den Code. Für den Nachtlauf gilt ein einziges Schnittkriterium, ein Issue muss ohne Rückfrage umsetzbar sein. Das Papier kennt keinen Review von Plänen durch fremde Modelle, keine zwei Reviewer je Dokument und keine Synthese durch ein drittes Modell.

Gebaut habe ich über den Sommer trotzdem genau das. Zwei Reviewer am Fachplan, zwei am technischen Plan, einer je Arbeitspaket. Danach eine Synthese der Befunde durch die Session, danach ein Beleg-Abgleich per Kommando, danach eine Prüfung der Synthese durch ein viertes Modell. Dazu fünf Zustandslabels, vier Routing-Labels, drei Register mit Prüfregeln und eine Rundengrenze. Der Skill für den Issue-Review hatte zuletzt 1.032 Zeilen. Eine Prüf-Session lädt rund 135 KB Regeln, bevor sie das erste Zeichen des Dokuments sieht, das sie prüfen soll.

Jede dieser Schichten hatte einen Anlass. Am 12. August hatten neun Synthesen Schärfungen behauptet, die nirgends standen. Also kam der Beleg-Abgleich. Am 31. August lieferten vier von vier Sessions keinen Body. Also kam die nächste Regel. Der Skill wurde zu einem Vorfallsprotokoll in Regelform, mit 27 Verweisen auf Issues und fünf Datumsangaben als Begründung. Keine Regel wurde je wieder entfernt, weil der Vorfall ja da war.

Was die Protokolle sagen

Ich habe die Nachtläufe vom 5. bis 12. September ausgewertet. Die Implementierung lief in 44 von 46 Sessions im Kit und in 25 von 30 im KI-Leitstand bis zum Commit durch. Sie läuft, weil am Ende ein Werkzeug entscheidet: Tests grün, Coverage 100, Mutation 100, Build grün. Das Modell kann sich nicht herausreden.

Alles davor, also Plan erzeugen, Plan prüfen, Pakete erzeugen, Pakete prüfen, ist in der ganzen Woche kein einziges Mal ohne mich bis zum Ende gekommen. Von acht Versuchen, nachts einen Plan zu erzeugen, endete keiner mit einem freigegebenen Plan. Von fünf Prüf-Nächten endete eine mit Marker, und das war ein Task, das Dokument mit dem kleinsten Prüfumfang.

Der Grund liegt in der Bauart. Jeder Reviewer muss jeden Fund klassifizieren, und zwei der drei Klassen rufen zwingend einen Menschen. Ein Fund ohne Klasse gilt wie ein Stopp. Ein roter Beleg-Abgleich ebenfalls, ein ausgefallener Reviewer ebenfalls. Die Register bitten außerdem darum, Alternativen zu benennen. In Software gibt es immer mehr als einen gangbaren Weg, und ein Sprachmodell, das man nach Alternativen fragt, liefert welche. Bei einem Fachplan im KI-Leitstand fanden beide Reviewer unabhängig voneinander dieselbe Frage: Ob ein ausgeblendetes Vorhaben nach dem Wiederherstellen aus dem Papierkorb sichtbar ist oder ausgeblendet bleibt. Ein Randfall aus zwei Nebenfunktionen. Er hat die Nacht angehalten.

Ich hatte einen Apparat gebaut, der nie eine falsche Entscheidung trifft, weil er gar keine trifft.

Meine eigenen Regeln, gegen mich gewendet

Das Unangenehme daran: Ich habe gegen drei meiner eigenen Thesen verstoßen. Leitplanken müssen scheitern können, nicht argumentieren. Meine Prüfkette hat ausschließlich argumentiert. Anti-Pattern 9 im Whitepaper sagt, ein Modell ist kein Gate, die Entscheidung trifft ein Werkzeug oder ein Mensch. Bei mir haben Modell-Marker Stufen freigegeben. Und zur These, dass die Denkarbeit nach vorn wandert, gehört die Abgrenzung „nicht mehr Dokument, sondern mehr Klärung“. Jeder meiner Reviews erzeugte vier neue Dokumente und gab die Klärung an mich zurück.

Auf einem Max-Plan merkt man so etwas übrigens nicht am Geld. Man merkt es nur an der Zeit und daran, dass die Nacht ohne Ergebnis endet. Genau deshalb fällt so ein Apparat lange nicht auf.

Was ich jetzt anders mache

Ein Reviewer je Stufe, keine Synthese, kein Abgleich, keine Prüfung der Prüfung. Die Formregeln, die ein Modell bisher für Minuten und Dollar geprüft hat, prüft jetzt ein Kommando in Millisekunden. Ein Modell-Befund ist ein Vorschlag an den Autor der Stufe, kein Gate. Ob eine Stufe fertig ist, sagt ein Werkzeug.

Und die Nacht fragt nicht mehr, sie trifft Annahmen und schreibt sie auf: gewählter Weg, verworfene Alternative, Grund, Rückbaukosten. Nur eine kurze, geschlossene Liste hält die Kette an, Datenverlust, Sicherheit, Verträge nach außen, Widersprüche im Fachplan, Änderungen am Prozess selbst. Alles andere wird entschieden. Verbindlich wird nachts nichts, verbindlich wird es beim Push am Morgen, wenn ich die Entscheidungsliste lese. Was sich verschiebt, ist der Zeitpunkt des bewussten Akts. Das Kippen einer Entscheidung ist ein Satz am Fachplan und eine neue Nacht.

Die Kennzahl, die alles trägt: Wie viele Entscheidungen der Nacht habe ich morgens gekippt. Bleibt die Quote nahe null, ist der Prozess bewiesen. Steigt sie, weiß ich, welche Entscheidungsklasse auf die Stopp-Liste gehört.

Zurückrudern gehört dazu

Wir sind in einem neuen Feld. Es gibt viele Ideen, Konzepte und Implementierungen, von Spec Kit über Kiro bis zu Schleifen, die gar keine Stelle mehr haben, an der man eine Rückfrage stellen könnte. Was sich davon durchsetzt, muss sich erst noch zeigen. Meine eigenen Prämissen gehören da ausdrücklich dazu.