Ein Autopilot für den Backlog: Protokoll eines Experiments

Der Loop ist bewusst simpel gehalten und hat eine harte Regel im Zentrum:

Die wichtigsten Entscheidungen dahinter:

Das grüne Gate ist nicht verhandelbar. Formatprüfung, Build und die Unit- und Komponententest-Suite müssen durchlaufen, sonst wird nicht gemergt. Ein rotes Gate heißt: Item wird als blockiert markiert, der Arbeitsstand bleibt zur Analyse liegen, der Loop nimmt das nächste Item. Kein Nachbessern auf main, kein „das fixen wir später". Zwei Dinge deckt das Gate bewusst nicht ab: Der Android-Build und die Ende-zu-Ende-Tests blieben beim Menschen, dafür läuft im Loop kein Emulator.

Jedes Item bekommt einen eigenen Git-Worktree. Die Arbeitsstände sind voneinander isoliert, gemergt wird immer seriell. Parallel arbeiten dürfen die Agenten, parallel mergen nicht.

User Stories brauchen einen Menschen. Technische Aufgaben, Schuldenabbau und Bugfixes laufen durch. Aber bevor eine fachliche Story implementiert wird, stoppt der Loop, fasst zusammen, was er verstanden hat, und wartet auf mein Go. Die Entscheidung, was gebaut wird, bleibt bei mir; die KI entscheidet nur, wie.

Der Loop lastet seine eigenen Funde nicht neu ein. Die Abschlussanalyse erzeugt neue Findings und Vorschläge, aber sie wandern in den Backlog statt direkt in die nächste Runde. Ein System, das sich selbst Arbeit gibt und sie selbst erledigt, war mir eine Rückkopplungsschleife zu viel.

Die Bilanz des großen Laufs Ende Mai: 13 Backlog-Items bearbeitet, 40 Commits, sieben Items eigenständig auf den Hauptzweig gemergt, sechs fachliche Stories bis zur Entscheidungsreife aufbereitet. Darunter war nichts Triviales: Eine der autonom gemergten Aufgaben härtete die PIN-Sicherheit von einfachem Hashing auf PBKDF2 mit Salt und zeitkonstantem Vergleich, inklusive transparenter Migration der Bestandsdaten.

Interessanter als das, was durchlief, ist das, was brach.

Sechs UI-Tests fielen im Gate aus, aber nur manchmal. Isoliert ausgeführt: grün. Unter der parallelen Volllast des Loops: rot, nicht deterministisch, reproduziert über sechs Gate-Durchläufe und fünf unabhängige Agenten. Die Ursache waren echte Wartezeiten im Testcode, die unter Last zu knapp wurden. Ein Mensch hätte an dieser Stelle den Testlauf einfach wiederholt und wäre weitergegangen. Der Loop kann das nicht, für ihn ist ein flackernder Test ein hartes Nein. Die erste Reaktion war Triage: Tests markiert und übersprungen, Schuldenticket angelegt. Im zweiten Lauf kam die strukturelle Lösung, eine Zeitabstraktion im Produktionscode, danach lief die volle Suite dreimal in Folge fehlerfrei durch. Dazu ein eigener Beitrag: Flaky Tests sind ein Architekturproblem.

Schnittstellen-Wahrheit schlägt Komfort. Der Loop spiegelt den Backlog in ein Kanban-Board. Die komfortable Anbindung über das Tool-Protokoll lieferte je nach Prozess unterschiedliche Zustände; erst der Umweg über die nackte REST-API war mit der Oberfläche konsistent. Die Markdown-Dateien im Repository blieben deshalb die einzige Quelle der Wahrheit, das Board ist nur Anzeige.

Prozeduren als Text sind wiederverwendbar. Die Fachprozesse des Projekts liegen als ausführliche Markdown-Anleitungen im Repository. Die Arbeits-Agenten des Loops können diese Anleitungen nicht als Kommando aufrufen, aber sie können sie lesen und den Phasen folgen. Das klingt banal, ist aber der Mechanismus, der den ganzen Fan-out trägt: Ein dokumentierter Prozess, der präzise genug für eine KI ist, ist nebenbei auch für jeden neuen menschlichen Mitarbeiter präzise genug.

Nach diesem Experiment ziehe ich die Grenze so: Autonomie funktioniert dort, wo ein maschinell prüfbares Gate existiert und die Aufgabe klar geschnitten ist. Sie endet dort, wo Urteilsvermögen über das Produkt gefragt ist, und an jeder Stelle, an der das Gate selbst wackelt. Der Autopilot hat in einem Lauf mehr sauber abgeschlossen, als mancher Arbeitstag hergibt, aber jede seiner Schwächen war am Ende eine Schwäche meines Prozesses: unscharfe Tickets, flackernde Tests, Metriken mit zwei Wahrheiten. Die KI hat sie nur schneller und unbarmherziger sichtbar gemacht, als es ein Team getan hätte.

Genau darin liegt für mich der eigentliche Wert solcher Experimente. Man lernt weniger über die KI als über den eigenen Entwicklungsprozess.

Klingt nach deinem Thema? Schreib mir. Im Erstgespräch klären wir unverbindlich, ob und wie ich helfen kann.