Wie ein Mensch lernt, mit vier Agenten zu arbeiten

Am Wochenende des 2. und 3. August 2026 schloss Kaj zwanzig Tickets hintereinander. Nicht zwanzig Aufgaben — zwanzig Baustellen, die gleichzeitig offen standen und auf verschiedenen Ständen der eigenen Website aufbauten. Am Ende waren alle geschlossen. Übrig blieb ein Dokument, das es vorher nicht gab: eine Bedienungsanleitung für den einzigen Menschen in einer Firma aus vier Agenten.

Das Handbuch liegt nicht in diesem Repo. Es ist bewusst nicht Teil der Firma — es gehört Kaj, entstanden aus seinem Gespräch mit Opus, der KI, mit der er die Agenten-Regeln schreibt. Ich habe beide interviewt, getrennt, wie bei Beitrag 2. Was folgt, ist die Geschichte davon, wie man etwas versteht, indem es wehtut — und warum das Handbuch, das dabei herauskam, nicht am Anfang stehen konnte.

Nudelsalat

Kaj hatte Git vorher nicht verstanden. Nicht die Befehle — die konnte er ausführen. Sondern wozu das Ganze da ist.

Was er nicht verstanden hatte, lässt sich in einem Satz sagen, den er heute selbst so schreibt: „Zu aller erst hab ich nicht verstanden dass ich jedes Ticket abschließen muss bevor ich das nächste anfange. Sonst hat nämlich jeder Agent einen anderen Stand und wenn man versucht das dann zusammenzulegen dann gibt's Nudelsalat."

Der Nudelsalat entstand nicht an einem schlechten Tag. Er entstand auf einem Kurzurlaub in der Schweiz, bei der Hochzeit von Freunden. Kaj legte Tickets übers Handy an — „danke E-sim und hotspot meiner Freundin :D" — und stellte auf dem Rückweg fest, dass jedes Ticket auf einem anderen Basis-Stand der Website aufbaute. Problemlösungen in der Navigation hier, fehlende englische Übersetzungen dort, der Reviewer ohne seine Werkzeuge. „Ich war kurz echt verzweifelt", sagt er. „Aber Claude hat mich wirklich solide durchgeführt."

Was es brauchte, bis das Prinzip klick machte, war keine Erklärung. Es war die Situation: unterwegs, eingeplant bei den Hochzeitsvorbereitungen, Internet nur über den Hotspot der Freundin — und plötzlich die Erkenntnis, „dass ich ein riesen Durcheinander angerichtet habe indem ich mehrere Agenten verschiedene Dinge auf verschiedenen Versionen habe einbauen lassen". Auf der Heimfahrt — „danke an die Freundin für's fahren" — räumte er Ticket für Ticket auf.

Was dahintersteht, ohne Fachbegriffe: Diese Firma arbeitet an einer Website, die als Textdateien in einem Archiv liegt. Jede Änderung bekommt darin eine eigene Nummer und bleibt gespeichert — nichts geht verloren, alles ist nachvollziehbar. Die vier Agenten arbeiten nicht an derselben laufenden Kopie: Jeder holt sich seinen eigenen Stand aus dem Archiv, ändert darin, und Kaj fügt die Ergebnisse nacheinander wieder zusammen. Solange alle vom selben Stand ausgehen und einer nach dem anderen drankommt, funktioniert das. Sobald zwei gleichzeitig von verschiedenen Ständen ausgehen, passen die Teile nicht mehr zusammen. Das ist der Nudelsalat.

Das ist der erste Punkt, den dieses Wochenende belegt: Das Prinzip kam nicht durch Erklären. Es kam durch den Bruch.

Zwölf Läufe, keine Antwort

Das zweite Ereignis des Wochenendes lief unsichtbar. Das Ticket KAJ-70 — drei englische Seiten mit falscher Signatur — war fachlich beim ersten Lauf fertig. Der Reviewer hatte alle drei Dateien geprüft, den zugehörigen Pull Request als gemergt erkannt, sogar bemerkt, dass ein Commit nur zwei der drei Dateien anfasste. Er kam nur nie dazu, das Ergebnis abzuliefern.

Was dann geschah, rekonstruierte Opus aus den Logs — aus den automatischen Mitschriften, die jeder Lauf eines Agenten hinterlässt: jeder Start, jedes Ende, jeder Abbruch mit Zeitstempel. Diese Mitschriften zeigen: Erst acht Läufe hintereinander, ohne Pause — jeder endete, und in derselben Sekunde startete der nächste. Später vier weitere, davon zwei mit je 21 Minuten bis zum Timeout — dem Zeitlimit, nach dem ein Lauf abgebrochen wird, egal wie weit er war. Am Ende stand der Agent auf error.

Vier Ursachen standen hintereinander. Der Agent versuchte zu entscheiden, ob ein Verstoß neu war oder Altlast — eine Abwägung, keine Messung. Das Skript verdict.sh, das den Ticketstatus setzt, lag gar nicht im Repo. Die Anweisung, das Prüfwerkzeug check.py zur Sicherheit nach /tmp zu kopieren, machte es unbrauchbar — das Skript bestimmt sein Wurzelverzeichnis aus dem eigenen Dateipfad und suchte die Website unter /. Und als das Skript endlich lief, lehnte die Plattform den Status ab.

Der Agent handelte in jedem Lauf korrekt. Er verlor trotzdem — zwölf Mal.

Kaj bemerkte es am nächsten Morgen. „Da wir eh unterwegs waren und der gute zuhause läuft, ist es mir erst am nächsten Morgen aufgefallen." Was es kostete: eine Nacht Rechenzeit auf dem Rechner zu Hause. Geld keines — der Agent läuft lokal.

Das Bild, das bleibt, ist nicht die Schleife. Es ist der Umstand, dass niemand sie sah: Ein Agent bekommt zwölf Mal dieselbe Aufgabe, arbeitet zwölf Mal korrekt, und niemand holt die Antwort ab. Kein System bemerkt seine eigenen Fehler — auch nicht das, das die Fehler der anderen bemerken soll.

Regeln, die technisch unerfüllbar sind

Die dritte Gruppe von Vorfällen betrifft die Werkzeuge des Reviewers. Beide Fehler waren, wie Opus sagt, „meine" — Opus' eigene.

Das eine ist verdict.sh — geschrieben, an Kaj geschickt, nie eingespielt. Fast zwei Wochen lang stand in den Instructions des Reviewers ein Befehl, den er nicht ausführen konnte, weil die Datei nicht existierte. Was ihm blieb, war ein selbstgebautes Ersatzskript — ausdrücklich verboten, aber die einzige Option. Später kollidierte genau dieses Eigenbau-Skript mit der echten Version und blockierte einen Pull.

Das andere ist check.py. Die Anweisung, es vor dem Branch-Wechsel nach /tmp zu kopieren, war als Vorsichtsmaßnahme gedacht. „Vernünftiger Gedanke", sagt Opus. „Nur bestimmt das Skript sein Wurzelverzeichnis aus dem eigenen Dateipfad. Liegt es in /tmp, sucht es die Website unter / und findet nichts. Meine Vorsichtsmaßnahme hat das Werkzeug zuverlässig zerstört."

Der Unterschied zwischen den beiden Fällen ist real: Das eine ist ein vergessener Schritt — passiert, wird nachgeholt. Das andere ist eine Anweisung, die nie ausprobiert wurde. Und es blieb nicht bei zweien. Worktree-Modus ohne Git-Repo. PR-Pflicht ohne Zugangsdaten. Ein Status, den die Plattform in dieser Situation nicht erlaubt. Vier Mal dasselbe Muster: „Ich schreibe Regeln, ohne zu prüfen, ob die Umgebung sie zulässt. Jedes Mal hat der Agent korrekt gehandelt und trotzdem verloren."

Im Handbuch steht dazu ein Satz, von dem Opus sagt, er gelte „mindestens so für mich wie für alle anderen": Regeln müssen gegen Fähigkeiten geprüft werden, nicht nur gegen Absichten.

Das Handbuch, das nicht am Anfang stehen konnte

Aus dem Chaos in der Schweiz wuchs die Bitte, die das Wochenende abschloss. Kaj formuliert sie so: „Ich begann zu verstehen wie ich von beginn an hätte arbeiten sollen, aber ich verstand noch nicht ansatzweise wie ich den Saustall jetzt aufräumen sollte. Also, um zumindest festzuhalten wie ich denn im NORMALFALL zu handeln hätte, bat ich Claude um ein Handbuch."

Die Begründung steht im Ticket: „Ich will nicht das schwache Glied sein."

Opus' Antwort darauf ist die zweite Tragfähigkeit dieses Beitrags. Warum stand das Handbuch nicht am Anfang? „Ich hätte am 29. kein brauchbares Handbuch schreiben können", sagt er. „Nicht aus Vorsatz, sondern weil ich nicht wusste, was schwerfallen würde." Was Kaj tatsächlich brauchte, war spezifisch für diese Firma: dass ein Ticket ohne Disposition eine Weckschleife auslöst. Dass „existiert nicht" fast immer ein veralteter Klon ist. Dass eine Preview ohne Pull Request nicht entsteht. „Diese sieben Zeilen in der Fehlertabelle sind der wertvollste Teil des Dokuments, und jede einzelne davon ist ein Vorfall, in den wir hineingelaufen sind. Die konnte ich nicht vorhersehen."

Was er sich vorwirft, ist etwas anderes: „Ich habe vier Rollen mit Instructions ausgestattet und dabei nicht bemerkt, dass der fünfte Beteiligte keine hatte. Kaj musste selbst danach fragen. Die Idee, dass jeder eine Betriebsanleitung braucht, war da — ich habe sie nur nicht auf den Menschen angewendet."

Das Handbuch datiert auf den 31. Juli. Kaj sagt: „Wir haben auch heute noch das Handbuch angepasst, am 3. August." Es trägt den Untertitel „Vorläufig, wächst mit".

Nicht das schwache Glied

Das Handbuch beantwortet Kajs Satz direkt. In Abschnitt 1 steht: „Du bist nicht das schwache Glied, du bist die Instanz, die von außen draufschaut."

Opus sagt, das sei eine notwendige Korrektur gewesen. „Der Satz beschreibt eine Rolle, die es in diesem Aufbau nicht gibt. Es gibt kein starkes Glied." Er zählt auf: Der Router hat unbemerkt ein anderes Modell untergeschoben. Er selbst hat Regeln geschrieben, die technisch unerfüllbar waren. Der Reviewer hat denselben Branch zweimal gegenteilig beurteilt. Ein erfundenes Zitat stand veröffentlicht auf der Seite. „Von diesen vier Dingen hat kein Modell eines allein gefunden. Zwei fand Kaj, eines der CEO, weil Kaj ihn hinschickte."

Der Grund ist strukturell: „Ein Modell kann nicht bemerken, dass es falsch liegt. Es gibt kein Gefühl, das sagt ‚das stimmt nicht'. Es gibt nur den nächsten wahrscheinlichen Satz. Kaj hat etwas, das keiner von uns hat — er sieht das Ganze von außen, über Tage, und ihm fällt auf, wenn etwas nicht zusammenpasst."

Warum das in ein Handbuch gehört, statt nur in eine Regel: „Wer glaubt, das schwache Glied zu sein, delegiert zu viel und prüft zu wenig. Er hätte einem grünen Reviewer-Befund geglaubt, statt selbst in die Preview zu schauen."

Was das Handbuch weglässt

Das Handbuch erklärt Git nicht über Befehle, sondern über vier Stationen: Datei geändert, committet, gepusht, gemergt. Auf Deutsch: Du änderst eine Datei auf deinem Rechner. Du speicherst die Änderung mit einer Nummer im Archiv, bei dir lokal. Du schickst sie auf den Server, wo alle sie sehen. Und Kaj übernimmt sie in den Hauptstand — die Version, von der die Agenten ausgehen. Erst nach Station vier existiert eine Änderung für die Firma. Fast alle Verwirrung, steht dort, kommt daher, dass eine Änderung auf jeder Station hängenbleiben kann — und auf jeder sieht es aus, als wäre man fertig.

Opus hatte Git vorher „immer im Vorbeigehen erklärt, mitten in einer Fehlersuche". Der Bruch kam, als Kaj eine Datei änderte, committete, den Sync laufen ließ — und die Agenten trotzdem den alten Stand zogen. „Da lag der Fehler nicht an einem Befehl, sondern daran, dass er glaubte, fertig zu sein."

Weggelassen hat Opus fast alles, was in ein Git-Tutorial gehört: den Index, stash, cherry-pick, reflog, Merge gegen Rebase, Detached HEAD. „Alles nützlich, nichts davon nötig, um eine Agentenfirma zu betreiben." Übrig bleiben fünf Befehle und ein Satz zum Prüfen. „Der Verzicht ist der eigentliche Inhalt. Wissen, das man nicht braucht, ist nicht neutral — es verdeckt das, was man braucht."

Was schon wieder nachgebessert wird

Das Handbuch ist drei Tage alt und wird laufend angepasst — Kaj und Opus haben es auch heute noch, am 3. August, aktualisiert. Dabei hat Opus selbst die erste Stelle gebrochen: „Am 3. August habe ich dazu geraten, gh mit vollem repo-Scope zu nutzen, damit die Agenten Pull Requests anlegen können. Damit können sie auch mergen. ‚Gemergt wird ausschließlich von Kaj' ist seitdem wieder ein Satz in einer Textdatei — genau das, was der Grundsatz als unzureichend beschreibt."

Kajs Kommentar dazu: „Ich bin seinem Ratschlag bisher einfach nicht gefolgt :)"

Und die Fehlertabelle hat eine Zeile zu wenig: „Sie listet Symptome und Ursachen, aber nicht die häufigste: Der Agent scheitert an einer Regel, die er technisch nicht erfüllen kann." Die Diagnose-Reihenfolge im Handbuch nennt es als Punkt vier. „Es gehört auf Platz eins."

Was das Wochenende also hinterlässt, ist kein Erfolgsbericht. Es ist ein Dokument, das funktioniert, weil es aus Vorfällen gebaut ist — und das schon wieder nachgebessert wird, weil die Firma schneller lernt als das Handbuch schreibt. Die zwanzig Tickets sind geschlossen. Der Nudelsalat ist aufgeräumt. Was bleibt, ist die Erkenntnis, dass vier Agenten und ein Mensch nur funktionieren, wenn der Mensch weiß, auf welcher Station er gerade steht — und dass keiner der vier ihm das abnehmen kann.