Coding-Agenten liefern. Kannst du das System noch erklären?

Das Feature ist fertig, bevor du dir richtig überlegt hast, wie du es selbst gebaut hättest.

Der Agent hat den Code geschrieben, Tests ergänzt und seine Entscheidungen erklärt. Du liest den Diff, fragst bei einem Sonderfall nach und korrigierst eine Kleinigkeit. Sieht gut aus. Es bleibt sogar noch Zeit für ein weiteres Ticket.

Ein guter Nachmittag. Bis ein paar Tage später jemand fragt, warum der Hintergrundjob sich so verhält. Und du merkst: An die Erklärung des Agenten erinnerst du dich besser, als du den Job selbst verstehst.

Du könntest die Antwort herausfinden. Natürlich. Trotzdem liegt zwischen «Das kann ich nachfragen» und «Hier kenne ich mich aus» eine Lücke, die sich nicht besonders gut anfühlt.

Solange die Arbeit vorankommt, fällt sie kaum auf.

Was früher nebenbei hängen blieb

Denk an den letzten Bug, dessen Suche viel zu lange gedauert hat. Die Korrektur war vermutlich klein. Bis dahin bist du einer falschen Spur gefolgt, hast ein Modul gelesen, um das du lieber einen Bogen gemacht hättest, und festgestellt, dass eine vertraute Funktion etwas anderes tut, als ihr Name vermuten lässt.

So einen Nachmittag würdest du nicht freiwillig wiederholen. Aber hinterher kanntest du diese Ecke des Systems. Als dort das nächste Mal etwas schiefging, wusstest du immerhin, wo du anfangen konntest.

Mit einem Agenten lässt sich ein grosser Teil dieser Sucherei abkürzen. Du beschreibst das Symptom und bekommst eine plausible Diagnose, oft gleich mit einem Patch. Das ist ein Gewinn. Nur hast du beim Suchen manchmal auch etwas gelernt, wonach du nie gefragt hättest.

Daraus würde ich keine Sehnsucht nach Handarbeit ableiten. Zum fünften Mal an derselben Build-Konfiguration zu verzweifeln hat keinen besonderen Bildungswert. Interessanter ist, wohin die gesparte Zeit geht. Bleibt davon etwas übrig, um einen schwierigen Teil des Produkts zu verstehen? Oder wird daraus vollständig die nächste Aufgabe?

Das Ticketboard bekommt beide Nachmittage voll. Welcher dich besser auf morgen vorbereitet hat, zeigt es dir nicht.

Die Frage hinter einer kleinen Korrektur

Stell dir einen Dienst vor, der Dokumente an einen externen Signaturanbieter schickt. Gelegentlich läuft ein Request in einen Timeout. Die naheliegende Verbesserung ist ein Retry: Schlägt der Aufruf fehl, versuchen wir es noch einmal.

Ein Agent könnte das sauber implementieren. Der Code wäre gut lesbar, und die Tests würden genau das zeigen, was du bestellt hast.

Nur: Was passiert, wenn der Signaturanbieter das Dokument schon angenommen hatte, bevor die Verbindung abbrach? Dein Dienst hat die Bestätigung nie erhalten. Für den Aufrufer ist der Request gescheitert. Beim Anbieter liegt bereits ein Dokument zur Unterschrift bereit.

Der Retry könnte jetzt einen weiteren Signaturauftrag erzeugen.

Entscheidend ist also, was der Timeout überhaupt aussagt. Ist der Vorgang fehlgeschlagen? Oder weisst du lediglich nicht, ob er erfolgreich war? Sobald dir dieser Unterschied auffällt, suchst du nach einer Möglichkeit, wiederholte Übermittlungen zu erkennen oder den ersten Auftrag abzufragen. Dieselbe Überlegung steckt hinter Idempotenz in Zahlungs-APIs.

Das Beispiel ist ausgedacht. Es zeigt aber gut, welches Verständnis ein Review braucht. Du kannst jede Zeile des Retries lesen und trotzdem die Annahme dahinter übersehen. Dazu musst du genug vom Ablauf ausserhalb dieser Funktion kennen, um zu merken, dass noch etwas offen ist.

Ein Agent kann dir helfen, das alles zu untersuchen. Die Stelle, an der du nachhaken solltest, musst du erst einmal bemerken.

Einen Moment bei der Frage bleiben

Eine kleine Gewohnheit ist den Aufwand wert: Überlege dir vor der Erklärung des Agenten, was deiner Meinung nach passiert.

Ganz unspektakulär. Ein Satz reicht. «Wenn der Worker hier die Verbindung verliert, bleibt das Dokument vermutlich auf pending, und der nächste Durchlauf übernimmt es.»

Dann geht ihr gemeinsam durch den Code. Lass dir zeigen, auf welche Funktionen sich der Agent stützt, und öffne die entscheidenden Stellen. Hängt die Erklärung vom Verhalten des externen Anbieters ab, lies dessen Schnittstellenbeschreibung. Auch «Das wissen wir noch nicht» darf als Antwort stehen bleiben.

Mit deiner eigenen Vermutung gibt es jetzt etwas zu korrigieren. Vielleicht umfasst «pending» mehr Zustände, als du dachtest. Vielleicht kann der nächste Durchlauf gar nicht unterscheiden, ob ein Dokument noch nicht versendet oder bereits angenommen wurde. Die Erklärung trifft auf eine Frage, mit der du dich schon beschäftigt hast.

Verändere danach die Situation ein wenig. Was passiert, wenn der Benutzer storniert, während der Job wartet? Dabei merkst du recht schnell, ob du den Ablauf verstanden hast oder nur die Erklärung wiedergeben kannst.

Das kostet Zeit. Und es braucht Augenmass. Ein geänderter Abstand verdient selten dieselbe Aufmerksamkeit wie eine Berechtigungsprüfung oder ein Retry. Bleib dort länger, wo du zögerst. Besonders dann, wenn sich ein Fehler schwer rückgängig machen liesse.

Manche umständliche Stelle hat eine Vorgeschichte

Gelegentlich lohnt sich das langsamere Lesen noch aus einem anderen Grund: Code, der sich besonders leicht vereinfachen lässt, schützt vielleicht vor einem Fehler, den du noch nie erlebt hast.

Eine zusätzliche Prüfung. Ein Schreibzugriff an einer merkwürdigen Stelle. Ein Kommentar, der besorgter klingt, als es der umgebende Code rechtfertigt. Da möchte man gerne aufräumen, besonders wenn ein Agent eine kürzere Variante samt überzeugender Erklärung anbietet.

Schau vorher nach, wann die umständliche Stelle entstanden ist. Folge dem Commit in die damalige Diskussion, sofern es eine gibt. Vielleicht findest du eine Störung, die den heutigen Aufbau verständlich macht. Vielleicht stellst du auch fest, dass die Einschränkung längst weggefallen und die Vereinfachung überfällig ist.

Beides hilft weiter. Schwierig wird es, wenn eine fehlende Vorgeschichte durch eine Geschichte ersetzt wird, die bloss gut klingt. Hat niemand den Grund festgehalten, bleibt er zunächst unbekannt. Dann muss man das Verhalten untersuchen.

Genau deshalb hilft es dem nächsten Menschen, Architekturentscheidungen aufzuschreiben. Eine kurze Notiz über den Fehler, den du verhindern wolltest, gibt ihm einen besseren Einstieg als noch ein Absatz darüber, was ohnehin im Code steht.

Deinem zukünftigen Ich hilft sie ebenfalls. Du wirst von diesem Nachmittag mehr vergessen, als du jetzt glaubst.

Etwas mitnehmen, das nach dem Merge bleibt

Der Einwand liegt nahe: Wir benutzen diese Werkzeuge doch, um Arbeit zu erledigen. Niemand möchte aus jedem Pull Request eine Hausaufgabe machen.

Sehe ich auch so. Ein Lernritual, das nach jeder Änderung einen Aufsatz und eine Prüfung verlangt, wird in einer vollen Woche bald als Erstes gestrichen.

Ein kleinerer Anspruch bringt mehr. Nimm dir eine Stelle vor, bei der du unsicher warst, und bleib dabei, bis du sie einem Kollegen erklären kannst. Vielleicht verstehst du danach endlich, was mit einem unterbrochenen Job passiert. Vielleicht weisst du, warum eine Berechtigung bei der Ausführung erneut geprüft werden muss. Für eine Arbeitssitzung reicht das.

Im Team braucht es dafür Platz. Jemand darf einen Request verfolgen, ohne am Ende einen weiteren Commit vorzuweisen. Und man sollte sagen können: «Ich habe das freigegeben, möchte es aber noch besser verstehen», ohne dass es wie ein Geständnis klingt.

Zum Schönen am Programmieren gehört der Moment, in dem ein rätselhaftes Verhalten plötzlich Sinn ergibt. Agenten können uns helfen, mit weniger Frust dorthin zu kommen. Es wäre schade, die gesamte gesparte Zeit dafür zu verwenden, an diesem Moment vorbeizueilen.

Wenn die nächste Änderung früher fertig ist als erwartet, öffne die Stelle, auf die du noch neugierig bist. Vielleicht gibt es für den Rest des Nachmittags etwas Besseres als ein weiteres Ticket.