Der Flaschenhals war nie das Tippen

KI hat nicht nur das Tippen schneller gemacht — sie hat den Flaschenhals komplett verschoben. Die Teams, die lernen, Agenten parallel laufen zu lassen, werden für die Teams, die noch immer auf einen Diff nach dem anderen warten, unwiedererkennbar wirken.

Die erste Version meines Entwicklungs-Loops mit KI war einfach. Den Assistenten bitten, Ding A zu erledigen. Warten. Den Diff reviewen. Zu Ding B übergehen. Der Assistent war ein schnellerer Pair-Programming-Partner. Immer noch ein Paar. Immer noch eine Sache nach der anderen.

Dieses Modell hielt etwa drei Monate. So arbeite ich jetzt nicht mehr.

Was ich jetzt mache, ist mehrere KI-Coding-Assistenten parallel gegen dieselbe Codebasis laufen zu lassen, jeder in seinem eigenen Git-Worktree, jeder auf seinem eigenen Branch, jeder gleichzeitig an einem anderen Problem arbeitend. Zu jedem gegebenen Zeitpunkt gibt es fünf bis zehn aktive Branches über die Repos hinweg. Verschiedene Agenten drücken gleichzeitig an verschiedenen Stellen der Engine. Ich reviewe und merge, statt zu schreiben und zu warten.

Diese Verschiebung in meinem Job ist der Post.

Wie ein echtes Wochenende aussieht

Ein Wochenende Mitte März. Über die fünf Repos hinweg landeten zwischen dem Samstagsfrühstück und dem Sonntagsabendessen 112 Commits. 66 hatten eine KI als Autor. 47 hatten mich. Der Rest waren Merges und review-getriebene Aufräumarbeiten.

Die Arbeit war nicht ein Projekt. Es waren fünf. WASM-Ports für neun Genres. iOS-Metal-Renderer-Integration. Ein Content-Pack-Runner mit einundzwanzig Assets durch eine siebenstufige Pipeline. Card-Battle-Genre-Stufen fünf bis sieben. Performance-Optimierungen für den Web-Build. All das geschah über dieselben zwei Tage hinweg in parallelen Branches, die über jeden Nachmittag und Abend hinweg landeten.

Kein einzelner Mensch tippt 112 Commits an einem Wochenende an einem Küchentisch-Schreibtisch. Kein einzelner Mensch kann fünf parallele Arbeitsstränge in einem Kopf halten und den Code für jeden davon schreiben. Das Modell, das ich drei Monate zuvor hatte, hätte dieses Wochenende nicht produzieren können.

Das Modell, das ich jetzt habe, tut es.

Der Flaschenhals verschiebt sich

Wenn Arbeit sequentiell ist, ist der Flaschenhals das Tippen. Die nächste Codezeile existiert nicht, bis sie jemand schreibt. KI hat diese Zeile schneller gemacht. Sie hat nicht geändert, welcher Schritt der langsame war.

Wenn Arbeit parallel ist, ist der Flaschenhals die Auswahl. Vier Agenten kommen mit vier Diffs zurück. Zwei davon sind gut. Einer geht in die richtige Richtung, braucht aber noch Arbeit. Einer hätte nicht geschrieben werden sollen. Der langsame Schritt ist zu entscheiden, welcher welcher ist, und die zwei zu mergen, die überleben.

Das ist ein völlig anderer Job als der, für den ich trainiert wurde. Weniger Tippen. Mehr Triage. Weniger Synthese. Mehr Auswahl.

Die Form des Wochenendes:

• Samstagmorgen: Rahmen setzen. Welche vier Probleme vier parallele Versuche wert sind. Was das Erfolgskriterium für jedes ist. Was die grobe Form einer akzeptablen Antwort ist.
• An beiden Tagen durchgehend: Stichproben. Sind die Agenten auf Kurs? Hat einer von ihnen in den ersten dreißig Minuten selbstsicher etwas Falsches produziert? Steckt jemand fest?
• Später Nachmittag, an beiden Tagen: Review und Merge. Diffs kommen rein. Jeden mit dem Erfolgskriterium im Hinterkopf lesen. Die mergen, die treffen. Die neu würfeln oder schließen, die nicht getroffen haben. Festhalten, was die gescheiterten Versuche über das Problem gelehrt haben.
• Sonntagabend: aufschreiben, was das Wochenende ausgeliefert hat und was die nächsten vier Probleme sind.

Es ähnelt eher einem Tech Lead mit einem Team aus vier als einem Senior IC mit einem Co-Piloten. Es nutzt andere Muskeln. Die genutzten Muskeln sind ungewöhnlich domänenübergreifend einsetzbar.

Wo das mit .raku-Dateien zusammenkommt

Die Experience-Dateien, die unsere Engine ausführt, sind .raku-Dateien: JSON, schema-versioniert, validierbar, als Code reviewbar. Das Format wurde mit diesem Parallel-Agenten-Workflow im Hinterkopf entworfen.

Wenn ein Agent eine .raku-Datei editiert, erscheint der Diff genauso wie ein Code-Diff. Ein zweiter Agent kann die Arbeit des ersten reviewen. Ich kann einen dritten Agenten beide stichprobenartig prüfen lassen. Die Merge-Entscheidung liegt bei mir. Das Ganze passt in dieselbe Pull-Request-Disziplin, die ich für die Runtime verwende.

Wäre .raku eine Binär-Asset gewesen, würde nichts davon funktionieren. Die Entscheidung fürs Format und die Entscheidung für den Workflow sind derselben architektonischen Entscheidung nachgelagert: Experiences sind Code, Entwicklungsarbeit ist Code-Review, Agenten nehmen am Loop teil, weil der Loop Code akzeptiert.

Das Dateiformat ist tragend. Es ist das, was das Team erlaubt, durch Agenten zu skalieren statt durch Kopfzahl.

Was in der Praxis funktioniert

Drei Muster, in die ich mich eingelebt habe.

Erstens: Agenten paarweise an einem Problem einsetzen. Wenn etwas nicht trivial ist, tendieren zwei Assistenten mit unterschiedlichem Training dazu, produktiv unterschiedlicher Meinung zu sein. Ich lasse sie auf getrennten Branches mit demselben Prompt laufen und diffe dann ihre Antworten. Die Meinungsverschiedenheiten sind der Ort, wo die eigentliche Review-Aufmerksamkeit hingeht.

Zweitens: Einen Agenten fürs Review reservieren. Ich halte einen der vier Assistenten an jedem gegebenen Tag in einer reinen Review-Rolle. Er schreibt nie den ersten Entwurf. Er kritisiert nur Diffs, die die anderen produzieren. Die Kosten für einen dedizierten Reviewer sind gering. Die Trefferquote bei Bugs ist erheblich.

Drittens: den Agenten-Kontext eng halten. Ein einzelner Agent auf einem einzelnen Branch bei einem einzelnen Problem ist schnell. Ein einzelner Agent bei einem ausufernden Problem mit fünf Stunden Kontext driftet ab und produziert minderwertige Arbeit. Der Fix ist, Probleme in kleinere Stücke zu zerlegen und den Kontext häufig zu rotieren.

Was nicht funktioniert

Ehrlich darüber, was nicht funktioniert.

Koordinationsaufwand ist real. Zwei Agenten auf derselben Datei zur selben Zeit erzeugen Merge-Konflikte, die ich auflösen muss. Die Kosten pro Konflikt sind gering, summieren sich aber. Abhilfe: Agenten wo möglich auf unterschiedlichen Dateien halten und akzeptieren, dass der Konvergenz-Schritt Teil des Workflows ist.

Review-Erschöpfung ist real. Vier Diffs am Ende jedes Tages zu reviewen ist schwerer, als vier sequentielle Diffs über vier Tage zu reviewen. Die Entscheidungen sind dichter. Ich beende den Arbeitstag an Parallel-Agenten-Tagen früher, als ich es tat, als die Arbeit sequentiell war.

Die Versuchung, alles zu behalten, ist real. Wenn zwei Agenten beide etwas Vernünftiges produzieren, ist der bequeme Schritt, beides zu mergen. Der disziplinierte Schritt ist, eines auszuwählen. Beides zu mergen verunreinigt die Codebasis mit zwei Wegen, dasselbe zu tun, was mehr kostet, als einfach den Verlierer neu würfeln zu lassen.

Kontextdrift über lang laufende parallele Sessions ist real. Ein Branch, der einen Tag lang offen war, sammelt Annahmen an, die der Agent über die Codebasis in dem Moment gemacht hat, als er startete. Bis zum Abend können diese Annahmen veraltet sein. Der Fix ist, Branches rücksichtslos kurzlebig zu halten.

Nicht alles parallelisiert sich. Übergreifende Refactorings mit subtilen Invarianten wollen einen einzelnen sorgfältigen Durchgang, nicht vier parallele Versuche. Die Fähigkeit besteht darin zu wissen, welche Probleme sich sauber teilen lassen und welche nicht. Manche Tage sind noch immer sequentielle Tage.

Was das für Engineering-Führungskräfte bedeutet

Wenn dein Team das sequentielle Modell mit angeflanschter KI fährt, ist der nächste Schritt nicht „ein besseres Modell benutzen.” Es ist „mehrere Agenten gleichzeitig benutzen.” Die Fähigkeitsobergrenze ist höher. Die Kompetenzobergrenze ist ebenfalls höher, und sie verschiebt die Senior-Rolle von der Produktion zur Rahmensetzung, Validierung und Auswahl. Das ist dieselbe Richtung, die ich in jeder anderen Disziplin sehe, die KI gerade gut einsetzt.

Die Teams, die Parallel-Agenten-Workflows in den nächsten zwei Jahren herausfinden, werden für Teams, die noch das sequentielle Modell fahren, unwiedererkennbar wirken. Die Form der Arbeit ist es, was sich ändert. Nicht das Tooling.

112 Commits über zwei Tage. Am Sonntag den Laptop schließen, mit den meisten davon grün.