Ich wollte mein Kanban-Board nachts abarbeiten lassen. 20 Issues ins Ready-Feld, ein Kommando, schlafen gehen. Der erste Versuch scheiterte nicht an der KI, sondern am Kontextfenster.

20 Issues in einer Session heißt: Issue 17 wird mit dem komprimierten Sediment von 16 Vorgängern gebaut. Irgendwann ist der Kontext zu voll, das Modell komprimiert, wird langsamer, verliert, was am Anfang wichtig war. Die Qualität sinkt genau dann, wenn niemand zuschaut.

Der naheliegende Ausweg wäre Parallelität, mehrere Sessions gleichzeitig. Das verschiebt das Problem nur. Fünf Sessions im selben Arbeitsverzeichnis committen sich gegenseitig in die Quere. Und den Merge-Konflikt um drei Uhr nachts löst keiner auf.

Die Lösung: nicht erinnern, sondern herausziehen

Ich habe meinem claude-workflow-kit einen Skill hinzugefügt: /implement-night. Er macht etwas Einfaches, immer wieder, für jedes Issue. Er nimmt das oberste Issue aus Ready, öffnet eine frische Session, implementiert genau dieses eine Issue, schiebt es nach In review, schreibt einen Abschlussbericht und beendet die Session. Dann das nächste. Bei null Kontext.

Jedes Issue ist das erste und einzige seiner Session. Kein Kompressions-Verfall, kein Vergessen mittendrin.

Das klingt nach einem Widerspruch: eine neue Session pro Issue, und trotzdem geht nichts verloren. Die Auflösung ist der Kern meiner Arbeit mit KI. Das Gedächtnis liegt nicht im Modell, es liegt in Dateien. Jede Session beginnt bei null, wie Henry Molaison, der Mann, der keine neuen Erinnerungen mehr bilden konnte (eine Metapher, die zwischen Sessions trägt, nicht innerhalb einer). Was zwischen den Sessions bestehen bleibt, ist das Board. Der Zustand jedes Issues, die Kommentare, die Abschlussberichte. Das CLAUDE.md mit den Konventionen. Die Übergabe läuft über das Issue, nicht über den Chatverlauf. Das Issue ist die Quelle der Wahrheit.

Deshalb vergisst der Runner nichts, obwohl das Modell alles vergisst. Ich habe die Erinnerung aus dem Modell herausgezogen, bevor die Nacht anfing.

Warum das keine Automatik ohne Bremse ist

Je autonomer die KI arbeitet, desto strenger müssen die Kontrollpunkte sein. Ein Nacht-Runner ohne Stop-Punkte ist kein Fortschritt, sondern ein Risiko, das nur größer skaliert. Drei Leitplanken machen den Unterschied.

Stop bei Rot. Schlägt ein Pflicht-Check fehl, stoppt die Session, und das Issue wandert zurück ins Backlog, nicht nach In review. Der Lauf geht weiter, aber nicht blind. Was mit den nächsten Issues passiert, hängt an ihren Abhängigkeiten.

Ein Limit pro Nacht. Nicht weil die KI müde wird, sondern weil ich am Morgen jedes Ergebnis reviewen muss. Der Takt wird vom langsamsten menschlichen Schritt bestimmt, nicht vom schnellsten der Maschine.

Crash-Erkennung. Hängt beim Start ein Issue in In progress, stoppt der Runner, statt zu raten, wo der vorige Lauf abgebrochen ist.

Und der wichtigste Punkt: nachts wird nichts gepusht. Der Runner baut lokale Commits, mehr nicht. Meine Freigabe ist kein nächtlicher Automatismus. Sie bleibt ein bewusster Akt am Morgen.

Abhängigkeiten gehören ins Issue

Ein roter Check bricht nicht die ganze Nacht ab. Der Runner geht chirurgischer damit um. Das gescheiterte Issue wandert zurück ins Backlog, dann nimmt der Runner das nächste. Bevor er es anfasst, prüft er die Abhängigkeiten. Liegt eine davon jetzt im Backlog, weil sie gerade gescheitert ist, wandert auch dieses Issue ins Backlog. Es wird gar nicht erst versucht.

Das steht und fällt mit einer Sache: Jedes Issue muss seine Abhängigkeiten sauber beschreiben. Was muss vorher stehen, und was hängt umgekehrt an ihm. Fehlt das, kann der Runner nicht entscheiden, ob das Fundament noch trägt, und baut auf Sand weiter.

Im schlimmsten Fall reißt das erste Issue alles mit. Es scheitert, und weil zehn andere darauf aufbauen, landen sie alle wieder im Backlog. Das sieht nach einer verlorenen Nacht aus. Es ist das Gegenteil. Der Runner hat zehn Issues davor bewahrt, auf einem kaputten Fundament gebaut zu werden. Am Morgen repariere ich das erste. Der Rest folgt in der nächsten Nacht.

Diese Abhängigkeiten kann das Modell nicht raten. Sie gehören vorher geklärt und ins Issue geschrieben, bevor die Nacht anfängt. Es ist dieselbe Denkarbeit, die nach vorn wandert.

Was die Nacht wirklich billig macht

Der Reiz an so einem Runner ist nicht die Ausdauer der Maschine. Er ist, dass die Denkarbeit vorher stattgefunden hat. Abends ziehe ich die Karten, sortiere sie, setze die Leitplanken, schneide die Issues sauber. Nachts wird nur gebaut. Die Implementierung ist so billig geworden, dass sie in den Schlaf passt. Genau deshalb wird die Vorbereitung teurer.

Morgens finde ich einen Stapel lokaler Commits, alle Issues in Review, dazu ein Nachtprotokoll. Dann kommt mein Teil: reviewen, testen, freigeben. Der Mensch bleibt am Steuer. Auch wenn er schläft.