Nicht der Agent macht die Arbeit schwer, sondern das Repository

Wer wissen will, ob ein Programmier-Agent taugt, lässt ihn Aufgaben lösen und zählt die gelösten. Das ist die Logik hinter jeder Bestenliste in diesem Feld, und sie unterstellt, dass die Eigenschaft, um die es geht, im Agenten sitzt. Eine Auswertung offener Repositories, in denen fünf verbreitete Agenten tatsächlich mitarbeiten, legt etwas anderes nahe.

Gemessen wurde nicht Erfolg, sondern Reibung: wie lange ein Änderungsvorschlag bis zur Erledigung braucht, wie viele Prüfrunden er durchläuft, wie oft Änderungen verlangt werden, wie oft er im Konflikt endet. Diese Reibung lässt sich statistisch aufteilen – in den Anteil, der zwischen verschiedenen Projekten schwankt, und den Anteil, der innerhalb eines Projekts von Vorschlag zu Vorschlag schwankt.

Nach Kontrolle für Änderungsgröße, Aufgabentyp, Sprache, Beliebtheit, Alter und Größe der Codebasis bleiben rund vierzig Prozent der Schwankung am Projekt hängen. Nicht am Agenten, nicht an der einzelnen Änderung: am Ort. Gemeint ist damit nicht, wie viel Reibung ein Projekt verursacht, sondern wie viel des Unterschieds zwischen den Fällen sich durch das Projekt erklärt.

Der eigentliche Befund ist der Vergleich. Auf denselben Projekten und unter einem für beide Seiten identischen Kontrollsatz – ohne die Agenten-Kennung – liegt dieser Ortsanteil bei menschlichen Beiträgen bei 0,16, bei Agenten-Beiträgen bei 0,30; der Agentenwert fällt unter diesen Bedingungen niedriger aus als in der Haupttabelle. Wo Menschen Reibung breit streuen, konzentrieren Agenten sie in denselben Projekten – dieselben Repositories bremsen sie immer wieder, während andere sie durchwinken. Uneingeschränkt gilt das für vier der sechs vergleichbaren Reibungsgrößen; bei zweien liegt der Unterschied auf dem Niveau, das der Autor auch dort findet, wo es um gar keine Reibung geht.

Und die Erwartung, dass mehrere Agenten sich gegenseitig ins Gehege kommen, hält nicht. Die Konfliktrate liegt bei einem Agenten wie bei mehreren praktisch gleich (31,2 gegen 30,8 Prozent), und der Ortsanteil ist in Projekten mit mehreren Agenten sogar niedriger als in solchen mit einem. Der Autor erklärt das nicht mit vorhandener Ordnung, sondern mit Mischung: Mehrere Verfasser ziehen den Projektwert nach unten, statt Reibung hinzuzufügen.

Was dagegen spricht¶

Die im Abstract genannten 930.000 Änderungsvorschläge tragen den Befund nicht: Der Kernvergleich zwischen Mensch und Agent läuft auf 282 gepaarten Projekten; erhoben wurde er über 404 kuratierte Repositories, von denen 314 genug menschliche Beiträge haben. Der große Satz dient der Gegenprobe, und das steht offen im Text.

Der ernsthafte Einwand ist die Vergleichsgruppe. Drei der fünf Agenten arbeiten über das Konto ihres Betreibers; der Autor nennt das als Grund, warum die Interaktion zwischen Agenten nur teilweise beobachtbar ist. Dass dadurch auch der menschliche Arm mit Agentenbeiträgen verunreinigt wäre und die gemessene Lücke deshalb eher zu klein ausfiele, steht so nicht in der Arbeit – es wäre eine Herleitung, und der Datensatz kennzeichnet jeden Vorschlag nach Urheber. Der naheliegendere Verdacht dagegen, die Gruppen seien schlicht verschieden schnell – Agenten führen gut ein Drittel ihrer Vorschläge selbst zusammen, Menschen praktisch nie, der übliche Vorgang ist in einer halben Minute vorbei –, wird vom Autor geprüft und ausgeräumt: Nimmt man den Weg zur Zusammenführung als Kontrollgröße auf, bleibt die Lücke unverändert. Dasselbe gilt für Aufgabenform, Teamgröße und eine vorhandene CI-Strecke; und den Ortsanteil selbst trägt kein einzelnes Projekt.

Was bleibt, benennt der Autor selbst: Die verbliebene Ortsvarianz ist ein notwendiges Kennzeichen, kein Kausalbeweis – eine unbeobachtete, aber stabile Projekteigenschaft könnte sie ebenso erzeugen. Die naheliegendsten – Größe und Alter der Codebasis – hat er gemessen; unkontrolliert bleiben die Regeln der Projektführung und die Anwendungsdomäne. Und die Konfliktzahlen stammen aus einem Teilbestand, der weniger als ein Drittel der Vorschläge abdeckt und zu Konflikten hin verzerrt ist.

Warum das hier steht¶

Weil es eine Frage verschiebt, die gerade viel Geld kostet. Eine Bestenliste sagt, welcher Agent im Durchschnitt fremder Aufgaben gut abschneidet; sie sagt nichts darüber, wie er sich im eigenen Repository schlägt – und dort entscheidet sich ein erheblicher Teil der Unterschiede darin, wie viel Reibung entsteht. Der Vorschlag des Autors ist entsprechend nicht, auf die Agentenwahl zu verzichten, sondern sie am Zielort zu treffen statt auf einer Rangliste. Die praktische Lesart ist unbequem und billig zugleich: Bevor man den Agenten wechselt, lohnt sich der Blick darauf, warum ausgerechnet dieses Repository jeden Beitrag zäh macht – die Antwort betrifft dann auch die Menschen darin.

Ob das für geschlossene Firmen-Repositories ebenso gilt, ist damit nicht gezeigt und wäre die interessantere Messung.

Gegenprüfung

Von drei Modellfamilien gegen den Volltext der Quelle gelesen; Befunde und Korrekturen stehen im Protokoll.claude · gemini · grokPrüfprotokoll zu dieser Notiz →