Der KI-Leitstand 1.0 war ein mehr oder weniger einfaches Task-Board. Eine schlanke Trello-Alternative, selbst gehostet, mit Projekten, Boards, Karten und Vorhaben. Irgendwann hing an diesem Board der Nachtrunner, über den ich in „Die dritte Nacht“ schon geschrieben habe. Claude arbeitet selbstständig die Ready-Spalte ab, plant Fachpläne durch und schneidet Arbeitspakete. Das Task-Board war plötzlich nicht mehr der Kern der Sache.
Morgens interessiert mich kaum noch, was in welcher Spalte steht. Ich will wissen, was heute Nacht passiert ist, was es gekostet hat, wo etwas liegen geblieben ist und warum. Deshalb heißt das, was ich gerade ausgeliefert habe, KI-Leitstand 2.0. Das Board bleibt wichtig, aber der Kern ist jetzt der Leitstand.
Der Leitstand als Hauptansicht
Wer ein Board öffnet, landet zuerst im Leitstand. Oben steht der jüngste Lauf mit Status, Stufen, Zeit und Kosten. Darunter folgen Kennzahlen mit ihrem Verlauf, der Durchsatz, die Abbruchgründe und die laufenden Vorhaben. Die Oberfläche hat dazu ein neues Aussehen bekommen und sieht jetzt aus wie ein Instrument und nicht mehr wie ein Formular.
Bewusst rausgeflogen ist die Verweildauer je Spalte aus dem alten Dashboard. Für ein Team, das Tickets von Hand schiebt, mag die interessant sein. Für einen Leitstand, der KI-Arbeit beobachtet, ist sie Rauschen.
Alle Projekte in einer Ansicht
Der Leitstand eines Boards zeigt ein Projekt. Wenn ich nachts mehrere Läufe in mehreren Projekten gestartet habe, will ich morgens sehr schnell drei Dinge wissen. Welcher Lauf ist durchgelaufen und welcher nicht? Welcher läuft vielleicht sogar noch? Und an welchen Karten ist es gescheitert?
Dafür habe ich eine zweite Ansicht gebaut, die mir das über alle Projekte hinweg auf einen Blick zeigt. Eine Störung ist dort eine Zeile, zum Beispiel:
ki-workflow-kit, 21.09., 09:17, Lauf #80, Karte #766 gescheitert.
Von dieser Zeile klicke ich in den Lauf und sehe, was passiert ist. In diesem Fall sollte die Karte doppelte Spec-IDs auflösen. Die Session hat sich nach sieben Minuten beendet, ohne ein Ergebnis für den Review abzuliefern. Der Runner hat das als „unerwarteten Zustand“ eingeordnet, die Karte zurückgestellt und mit der nächsten weitergemacht. Der Versuch hat 4,15 Dollar gekostet, und ich sehe auch, dass diese Fehlerklasse in 2 der 30 aufbewahrten Läufe aufgetreten ist.
Erst kommt der Überblick, dann gehe ich ins Detail. Wenn ich mich um eine Störung gekümmert habe, lösche ich sie, und sie verschwindet aus der Liste. So arbeite ich die Störungen nach und nach ab, und was noch in der Liste steht, ist tatsächlich noch offen.
Verbrauch und Kosten werden erfasst
Das war die größte fachliche Lücke. Ich wusste, dass der Nachtrunner arbeitet. Ich wusste nicht, wo er genau durchgelaufen ist und wo nicht und vor allem: Warum er stehen geblieben ist. Außerdem wird später einmal wichtig sein: Was hast das Ganze gekostet.
Jeder Nachtlauf meldet jetzt Token und Kosten, für den ganzen Lauf und für jedes einzelne Arbeitspaket. Die Summe des Laufs liegt über der Summe seiner Pakete, weil es Arbeit gibt, die keinem Paket gehört. Dieser Rest wird sichtbar ausgewiesen statt verschluckt.
Ausgewertet wird nach Nacht, nach Zeitraum und nach Vorhaben. Damit kann ich zum ersten Mal sagen, was ein Vorhaben tatsächlich gekostet hat. Abgebrochene Läufe erscheinen mit ihrem Grund, etwa einem überschrittenen Zeitbudget. Was nicht gemessen wurde, steht als „nicht gemessen“ da und nicht als Null.
Ein kleines Lehrstück am Rand: Was ist eigentlich eine Nacht? Der Plan hatte ursprünglich nach Kalendertag gruppiert. Ein Lauf um 23:10 und einer um 03:22 waren damit zwei Nächte, fachlich natürlich Unsinn. Die Lösung war eine Entscheidung, keine Technik. Die Tagesgrenze liegt jetzt bei zwölf Uhr mittags, und was davor läuft, gehört zur Vornacht.
Die Karte kennt ihre Geschichte
Auf jeder Karte steht jetzt, wie oft der Nachtrunner an ihr gearbeitet hat, jeder Anlauf mit Ergebnis und Verbrauch. Wenn eine Karte dreimal angefasst wurde, bevor sie durchging, sehe ich das, und ich sehe, was es gekostet hat.
Das Protokoll des Nachtlaufs habe ich früher morgens selbst hochgeladen. Jetzt liefert der Runner es ohne Login ab, über ein Token, das an das Projekt gebunden ist. Der Leitstand zeigt, woher ein Laufergebnis kam und ob es vollständig ist.
Was noch fehlt
Die Kostensicht ist nicht vollständig. Sie zählt bislang nur die Nachtläufe. Alles, was ich tagsüber im Gespräch mit Claude mache, Fachpläne, Reviews, Retros, interaktives Umsetzen, taucht dort nicht auf. An Tagen ohne Nachtlauf steht im Leitstand „kein Lauf“, obwohl an diesem Tag viel gearbeitet und verbraucht wurde.
Für die Frage, ob sich das lohnt, ist die Zahl damit noch nicht zu gebrauchen. Die Anforderung dafür ist geschrieben und gerade im Review. Die spannendste offene Frage darin: Welche Kosten sind überhaupt gemeint? Mit einem Abo gibt es keine Kosten je Token, Claude Code meldet trotzdem einen rechnerischen Betrag nach API-Preisen.
Ein Board zeigt, wo die Arbeit steht. Ein Leitstand zeigt, was die Arbeit getan hat.

Schreibe einen Kommentar