Die Agenten absichtlich gedrosselt

Schnellere Agenten bauen keine bessere Software — disziplinierte schon. Die Drosselung, die RakuAI kohärent hält, ist genau die Disziplin, die unserer Meinung nach jedes ernsthafte agentengetriebene Team braucht.

Diesen Samstag ein anderer Plan als in den letzten Wochen. Die letzten Wochenenden waren Durchsatz-Wochenenden. Achtzig Commits, siebzig Commits, zweihundertzweiundachtzig davor. Der Trend zeigte nach oben. Ich ließ die Agenten-Warteschlange voll aufgedreht laufen und sah zu, wie sich die Codezeilen auftürmten.

Dieses Wochenende habe ich absichtlich auf siebenunddreißig Commits gedrosselt. Der Trend in dieser Grafik zeigt jetzt nach unten, und das mit Absicht, und ich möchte aufschreiben, warum, denn ich glaube nicht, dass das der Trend ist, den die meisten Leute erwarten würden, die mit KI-Agenten bauen.

Was an dem Workflow stimmt

Die Agenten werden nicht müde. Der Durchsatz der Implementierungsebene ist begrenzt durch die Token-Kosten und dadurch, wie viele Issues in der Warteschlange offen sind. Wenn ich um sechs Uhr morgens hundert Issues anlege, leert und füllt sich die Warteschlange den ganzen Tag über, und ich bekomme hundert PRs zurück. Das macht der Workflow, wenn man ihn voll aufgedreht laufen lässt.

Was er dabei nicht tut, wenn er voll aufgedreht läuft, ist eine kohärente Codebasis zu erzeugen. Jeder PR landet isoliert betrachtet sauber. Aber die Schnittmenge von vierzig PRs, die an einem Tag landen, beginnt zu driften. Namenskonventionen laufen auseinander. Subsystemgrenzen werden unscharf. Der Agent, der an einem Issue gearbeitet hat, hat etwas über die Runtime-Schicht angenommen, das der Agent an einem parallelen Issue nicht angenommen hat. Bis Samstagabend sind die beiden Annahmen in einem dritten PR kollidiert, der sie in Einklang bringen muss, und dieser Ausgleich ist Murks.

Der Engpass in diesem Workflow ist nicht der Agent. Es ist der Mensch, der liest, was die Agenten produzieren, und die Architektur kohärent hält.

Was ich geändert habe

Zwei Dinge, beide im Commit-Muster dieses Wochenendes sichtbar.

Ich habe die Warteschlangentiefe gekürzt. Statt jederzeit fünfzehn offener Agenten-Queue-Issues habe ich auf sechs reduziert. Die Agenten laufen nicht mehr voll aufgedreht. Sie laufen in einem Tempo, das mir erlaubt, ihre Ausgabe tatsächlich zu lesen, bevor die nächste Charge landet.

Ich habe das Review nach vorne verlegt. Statt Agenten-PRs liegen zu lassen, bis ich eine Charge zum Durcharbeiten hatte, habe ich umgestellt und jeden Einzelnen sofort bei der Eröffnung reviewt. Das klingt langsamer, und das ist es auch. Es fängt aber auch Drift ab, bevor sie sich fortpflanzt. Eine schlechte Annahme, die früh am Samstag korrigiert wird, muss nicht bis Samstagabend über sechs PRs hinweg zurückgedreht werden.

Die Kombination dieser beiden Änderungen ergibt das Siebenunddreißig-Commit-Wochenende statt eines Achtzig-Commit-Wochenendes. Die Kombination ergibt außerdem eine Codebasis, die in besserer Verfassung ist als letzten Samstag, und darum geht es.

Was trotzdem gelandet ist

Eine Multi-Repo-Disziplin hat sich dieses Wochenende gefestigt. Die Runtime, das SDK und das Docs-Repo haben sich alle gemeinsam bewegt. Die Runtime bekam die Dokumentationsverzeichnis-Übersicht im README. Das SDK bekam die entsprechenden Querverweise. Die Docs sind gewachsen. Keines der drei Repos ist den anderen vorausgeeilt.

Das ist wichtig, weil in einem agentengetriebenen Workflow die Docs nicht nur Docs sind. Die Docs sind die Eingabe, die der Agent liest, wenn er das nächste Issue aufgreift. Wenn die Docs darüber lügen, was die Runtime unterstützt, wird der Agent gewissenhaft Code für die lügende Version der Runtime schreiben, und dieser Code wird nicht gegen die Realität kompilieren. Die Abhilfe besteht darin, alle drei Repos jederzeit ehrlich zu halten, auch wenn eines davon dasjenige ist, an dem man von Natur aus arbeiten würde.

Die andere, still wichtige Sache dieses Wochenendes war das Aufräumen der API-Oberfläche. Ein paar APIs, die im September-Ansturm hinzugefügt worden waren, gehörten offenbar nicht auf die öffentliche Oberfläche. Sie wurden zu intern degradiert. Die Agenten haben die Degradierung über das gesamte SDK in einem PR abgewickelt. Das ist die Art von Refactoring, die, von einem einzelnen Menschen erledigt, einen ganzen Tag dauert. In diesem Workflow erledigt, braucht es ein Issue, einen PR und ein sorgfältiges Review.

Was “Best Practices” in diesem Workflow bedeuten

Eine kurze Liste, geschärft durch die Erfahrung dieses Wochenendes, das Tempo zu drosseln.

Dokumentation ist Dev-Input, nicht Dev-Output. Wenn die Docs schlecht sind, ist die Arbeit schlecht. Pflegt sie wie Code. Reviewt sie wie Code. Verweigert das Merge eines Features, dessen Docs ausgelassen wurden.

Grenzen zwischen Subsystemen sind heilig. Der Agent wird keine Grenzen erfinden, die die Codebasis nicht bereits hatte. Wenn ihr eine Grenze wollt, müsst ihr sie ziehen, benennen und die PRs verweigern, die sie verletzen.

Cross-Repo-Synchronisation ist eine Aufgabe erster Klasse. Wenn Runtime und SDK sich gemeinsam bewegen müssen, muss die PR-Beschreibung das sagen, und das Merge des einen ist an das Merge des anderen gekoppelt. Zustandsdivergenz zwischen zwei Repos ist einer der leichter zu vermeidenden Fehlerzustände und einer der schmerzhafteren, von denen man sich erholen muss.

Bewusst langsamer werden. Der Agent tut das nicht. Ihr müsst es. Das Wochenende, an dem der Agent hundert PRs ausliefert, ist nicht dasselbe Wochenende, an dem sich die Codebasis um hundert PRs an Wert verbessert. Das Wochenende, an dem der Agent siebenunddreißig gut reviewte PRs ausliefert, könnte es sein.

Was Partner nützlich finden könnten

Wenn ihr irgendetwas mit autonomen Coding-Agenten baut und in die “die Agenten arbeiten schnell und die Codebasis ist ein Chaos”-Variante dieses Workflows hineinlauft, ist die Antwort nicht bessere Agenten. Die Antwort ist eine kleinere Warteschlange, ein früherer Review-Durchgang und Dokumentation, die die Agenten als Eingabe lesen.

Wenn ihr in einem KI-Labor einen Coding-Agenten für autonome PR-Workflows wie diesen abstimmt: Die Metrik, die ich in der Praxis am nützlichsten finde, ist nicht ausgelieferte Codezeilen pro Tag. Es ist, wie oft ein PR, der früh in einer Woche gelandet ist, später im selben Wochenende umgeschrieben werden muss, weil sich die Codebasis darunter bewegt hat. Je niedriger diese Zahl, desto besser ist der Agent bei der eigentlichen Aufgabe.

Siebenunddreißig Commits. Eine bessere Codebasis als letzten Samstag. Samstagnachmittag, und ich gehe jetzt spazieren.