Heute ist in meinem claude-workflow-kit zum ersten Mal eine Kette vom Fachplan bis auf das Testsystem durchgelaufen, ohne dass ich zwischendurch etwas freigegeben habe. Ich habe an einem Fachplan ein Label gesetzt. Danach hat die Kette den technischen Plan gebaut, ihn in Arbeitspakete zerlegt, die Pakete implementiert, auf main gepusht, die CI-Pipeline abgewartet und das Ergebnis auf das Testsystem deployed.

Drei Stufen

Das Kit ist in Stufen gewachsen. Am Anfang hat es nur implementiert: Ich habe ein Issue geschrieben, das Modell hat es umgesetzt, und ich habe gepusht. In der zweiten Stufe kam die Planung dazu. Aus einem geprüften Fachplan sind der technische Plan und die Arbeitspakete entstanden, und dort hat die Kette angehalten. Ob ein Paket nach READY wandert, habe ich entschieden. Seit heute gibt es die dritte Stufe, in der die Kette bis zum Testsystem weiterläuft.

Wer meine früheren Texte kennt, wird an dieser Stelle stutzen. Ich habe immer drei menschliche Haltepunkte vertreten, nämlich READY, Push und Merge, und im Nachtlauf galt die Regel, dass nachts nicht gepusht wird. Eine durchlaufende Kette habe ich selbst einmal in die Nähe von Vibe-Coding gerückt. Das sehe ich heute anders, und der Grund sind die Gates.

Wo die Kette scheitern kann

Der Fachplan wird von zwei Modellen aus unterschiedlichen Familien geprüft, bei mir sind das Claude Fable und Codex Astra. Alle offenen Fragen müssen beantwortet sein. Kommt das Review zu keinem klaren Ergebnis, bekommt der Fachplan das Label kit:klaeren, die Kette hält an, und ich muss ran. Läuft bei der Implementierung etwas schief, wandert das Arbeitspaket zurück ins Backlog, und alle Pakete, die davon abhängen, wandern mit. Sind die Pakete gebaut, prüft die Kette, ob jedes Akzeptanzkriterium aus dem Fachplan in einem Paket gelandet ist. Danach kommen die CI-Gates (unter anderen Mutation Score, ArchUnit, SonarQube) und eine rote Pipeline deployed nicht.

Keines dieser Gates fragt mich um Erlaubnis. Die Kette wartet nicht mehr auf mich, sie meldet sich, wenn sie mich braucht.

Was mir bleibt

Mir bleiben wieder drei Punkte, nur sind es andere. Ich kläre die Fachlichkeit, ich löse auf, was mit kit:klaeren liegen geblieben ist, und ich teste auf dem Testsystem. Ready, Push und Merge waren Freigaben auf dem Weg des Codes. Die neuen drei Punkte sind inhaltliche Arbeit. Dazu kommt eine Entscheidung, die man auf dem Bild sieht: Unter dem Fachplan #754 liegen zwei weitere, die ihr Review ebenfalls bestanden haben und trotzdem nicht laufen. Das Label kit:durchziehen setze ich von Hand, für jeden Fachplan einzeln.

Ich habe lange geschrieben, dass die menschlichen Kontrollpunkte strenger werden müssen, je autonomer die KI arbeitet. Streng sind bei mir inzwischen vor allem die maschinellen. Die Kette endet deshalb auf dem Testsystem und nicht in der Produktion. Eine grüne Pipeline sagt mir, dass geprüft wurde, was ich ihr beigebracht habe. Ob das Gebaute das Gemeinte ist, sehe ich erst, wenn ich es benutze.

Klein geschnitten, genau beschrieben

Das alles funktioniert nur, weil ein Fachplan bei mir klein ist. Auf dem Bild ist es ein einziges Vorhaben: Der Nachtlauf soll keine Arbeit mehr verlieren, wenn eine Sitzung auf eine lange Arbeit wartet. Daraus sind ein Plan und sechs Arbeitspakete geworden. (Die Kette baut hier übrigens an sich selbst.) Die ganze App zu spezifizieren und in einem Rutsch bauen zu lassen, wäre Vibe-Coding, auch mit Gates.

Größe und Genauigkeit sind zwei verschiedene Dinge. Groß und genau ist das Pflichtenheft, groß und vage ist „bau mir die App“. Klein und vage ist das übliche Ticket, mit dem ein Team zurechtkommt, weil die Entwicklerin oder der Entwickler zwischendurch nachfragt. Nachts fragt niemand nach. Deshalb muss mein Fachplan klein und genau sein, und was ein Team sonst im Lauf der Woche mit dem Product Owner klärt, kläre ich vor dem Lauf.

Zwei Tage

Ich stelle mir daraus einen Takt von zwei Tagen vor. Am ersten Tag wird mit dem Product Owner die Fachlichkeit besprochen, bis sie feststeht. Nachts wird gebaut. Am zweiten Tag wird getestet, und für alles, was im Lauf schiefgegangen ist, liegen Vorschläge auf dem Tisch, wie es sich beheben lässt. Danach beginnt das nächste Grooming. Ein Sprint ist das für mich nicht, weil niemand auf Vorrat plant und niemand etwas zusagt. Der Rhythmus entsteht, weil nachts gebaut wird.

Fehler, die öfter auftreten, sollen mit der Zeit weniger werden, weil die Kette aus ihnen Vorschläge für eine dauerhafte Behebung macht. Es bleiben Vorschläge. Ob daraus eine Regel wird, entscheide ich, denn ein Modell ist gegenüber der eigenen Lösung systematisch unkritisch, und das gilt auch für die eigenen Leitplanken.

Wie gut die Gates sind, messe ich daran, wie wenig ich nach einem Lauf nachbessern muss. Heute ist er vollständig ohne Fehler durchgelaufen.