Die Arbeit, die nach dem Merge beginnt

Früher war der Merge die Ziellinie. Sie öffneten einen Pull Request, jemand überprüfte ihn, er wurde übernommen, und die Änderung war erledigt. Coding-Agenten haben diese Linie leise verschoben. Wenn ein Agent ein Linear-Issue übernimmt, den Code schreibt und einen Merge Request öffnet, während Sie in einem Meeting sitzen, ist der Merge nicht mehr das Ende der Arbeit – er ist der Anfang von allem, was der Merge berührt.

Der Merge war nicht mehr die Ziellinie

Ein Merge ist nie nur ein Merge. Jede Änderung stützt sich auf die Systeme darum herum: das Issue, das jetzt geschlossen werden sollte, die Dokumentation, die seit heute Morgen etwas beschreibt, das nicht mehr ganz stimmt, die CI, die etwas röter ist als gestern, die Release Notes, die noch niemand geschrieben hat, das Support-Gespräch, das immer noch auf einen Fix wartet, der eigentlich schon vor Stunden ausgeliefert wurde.

Als eine einzelne Ingenieurin oder ein Ingenieur eine Handvoll Änderungen pro Woche auslieferte, passte diese Nacharbeit in die Lücken dazwischen. Man schloss das Issue, während der Pull Request noch offen war; man erinnerte sich an die Dokumentation, weil man gerade erst den Code angefasst hatte. Wenn ein Agent – oder eine ganze Flotte davon – viele Änderungen am Tag ausliefert, laufen diese Lücken über. Der Code ist nicht mehr der Engpass. Alles, was dem Code nachgelagert ist, ist es.

Das Wartungsmodell hat sich nicht verändert

Die Entwicklung wurde schneller. Die Wartung nicht. Die Werkzeuge, mit denen wir ein Projekt konsistent halten, sind größtenteils immer noch manuell und hängen weiterhin davon ab, dass sich jemand im richtigen Moment daran erinnert, sie zu nutzen:

• Ein Merge Request wird übernommen, aber das Linear-Issue, das er löst, bleibt offen.
• Die Dokumentation beschreibt weiterhin das alte Verhalten, und niemand ist sich ganz sicher, auf welcher Seite.
• Die CI schlägt seit einer Woche zeitweise fehl, und alle haben gelernt, darüber hinwegzulesen.
• Ein Feature Flag von vor drei Monaten hat weder einen Verantwortlichen noch ein Entfernungsdatum.
• Der Support beantwortet ein Ticket mit einem Workaround für einen Bug, der am Dienstag bereits behoben wurde.
• Jemand fragt, was in diesem Release enthalten war, und die ehrliche Antwort lautet: „Lassen Sie mich kurz das Git-Log lesen.“

Nichts davon ist neu, und nichts davon ist wirklich ein Agenten-Problem. Es ist die gewöhnliche Entropie eines Softwareprojekts. Der Agent erhöht lediglich das Tempo, bis das informelle System, das dies früher abgefedert hat, nicht mehr mithält.

Aufgeforderte Aufräumarbeiten skalieren nicht

Die naheliegende Lösung ist, den Agenten auch um das Aufräumen zu bitten – und das können Sie. Erwähnen Sie @taskgoblin im Merge Request und weisen Sie ihn an, die Dokumentation zu aktualisieren, das Issue zu schließen, die Release Notes zu entwerfen. Es funktioniert. Aber es hängt von der knappsten Ressource in der gesamten Schleife ab: einem Menschen, der sich jedes Mal, im richtigen Moment, daran erinnert, danach zu fragen.

Wartung ist keine einmalige Aufgabe, sondern eine Schleife. „Prüfen, ob die Dokumentation aktuell ist“ ist nichts, das man einmal erledigt. „Sicherstellen, dass gemergte Issues geschlossen werden“ ist nichts, das man einmal erledigt. Alles, was darauf wartet, dass eine Person bemerkt, dass es Zeit ist, die Schleife auszuführen, wird inkonsistent ausgeführt – weil Menschen inkonsistent darin sind, etwas zu bemerken, besonders wenn der ganze Sinn des Agenten darin bestand, all das nicht mehr im Kopf behalten zu müssen. Aufgeforderte Aufräumarbeiten verlagern die Arbeit auf den Agenten, belassen die Terminierung dieser Arbeit aber genau dort, wo sie war: bei Ihnen.

Warum wir Loops gebaut haben

Ein normaler Agenten-Lauf wird durch ein Ereignis ausgelöst – eine Issue-Zuweisung, eine Erwähnung, einen neuen Pull Request. Ein Loop wird durch Zeit ausgelöst. Sie geben dem Agenten eine feste Anweisung und einen Rhythmus – jeden Wochentagmorgen, jeden Montag, am Ersten des Monats – und er läuft von selbst, in einer Sandbox, mit denselben Werkzeugen und demselben Zugriff wie jeder andere Lauf.

Die Anweisung ist die gesamte Aufgabe, und gute Anweisungen lesen sich eher wie eine Stellenbeschreibung als wie ein Wunsch: worauf zu achten ist, welches Repository, was zu tun ist, was nicht zu tun ist, und – der Teil, der es sicher macht, unbeaufsichtigt zu laufen – was zu tun ist, wenn es nichts zu tun gibt, nämlich nichts.

Prüfen Sie jeden Wochentag um 09:00 Uhr die im letzten Tag in group/repo gemergten Merge Requests und schließen Sie jedes Linear-Issue, das sie lösen und das noch offen ist. Gibt es keine, tun Sie nichts.

Das ist eine Wartungsschleife mit einem Verantwortlichen. Sie wartet nicht darauf, dass Sie sich erinnern. Da ein geplanter Lauf ein vollständiger Agenten-Lauf ist, kann er den ganzen Weg gehen: nicht nur veraltete Dokumentation markieren, sondern den Merge Request öffnen, der sie korrigiert; nicht nur bemerken, dass gemergte Issues offen geblieben sind, sondern sie schließen – und dann dort berichten, wo Sie es tatsächlich sehen: als Kommentar im Linear-Issue, als Nachricht im von Ihnen genannten Slack-Kanal oder per E-Mail, wenn es keinen besseren Ort gibt.

Und weil er alles wiederverwendet, was ein normaler Lauf ohnehin tut, sind die kniffligen Fälle bereits abgedeckt. Verpasste Zeitpunkte werden übersprungen statt nachgeholt, sodass ein Scheduler, der eine Stunde lang nicht lief, nicht aufwacht und Ihnen hundert Nachholläufe auf einmal beschert. Jeder Lauf hat sein eigenes Budget und seine eigenen Leitplanken. Wir liefern eine Reihe von Start-Vorlagen für genau diese Schleifen mit – Issues und Merges synchron halten, eine zu lange rote CI im Blick behalten, Feature Flags aufspüren, die ihren Verantwortlichen überlebt haben, Release Notes entwerfen, sobald Dinge ausgeliefert werden – weil die nützlichen Schleifen in den meisten Teams dieselben sind. Sie tragen nur Ihr Repository und Ihren Kanal ein; die Leitplanken sind bereits geschrieben.

Die Rolle der Ingenieurin oder des Ingenieurs steigt eine Ebene auf

All dem liegt eine Sorge zugrunde: dass die Automatisierung der Wartung bedeutet, das Urteilsvermögen mit zu automatisieren. Das stimmt nicht. Sie hebt das Urteilsvermögen eine Ebene höher. Wenn die Schleifen sich selbst ausführen, hören Sie auf, die Person zu sein, die sich daran erinnert, Issues zu schließen, und werden zu der Person, die entscheidet, welche Schleifen existieren sollen, welche Leitplanken sie haben und was „fertig“ für jede von ihnen bedeutet. Sie überprüfen die feste Anweisung, statt den Botengang selbst zu erledigen.

Das ist ohnehin die erfahrenere Version dieser Rolle. Der Agent hat das Schreiben von Code billig gemacht; was übrig bleibt, ist zu entscheiden, was über das System wahr sein sollte, und dafür zu sorgen, dass es wahr bleibt. Loops sind der Weg, dies wahr zu halten, ohne alles im Kopf zu behalten – der Agent erschafft die Arbeit, und eine feste Schleife pflegt sie.