Ein Pilotprojekt für Coding-Agenten, das Tools an derselben Arbeit vergleicht

Warum ein Team pro Tool wenig aussagt

Der naheliegende Pilot gibt Tool A dem Payments-Team und Tool B dem Plattform-Team und vergleicht nach einem Monat die gemergten Pull Requests. Die Teams unterscheiden sich aber in Codebasis, Testabdeckung, Erfahrung, Aufgabenmix und Strenge im Review, und jeder dieser Faktoren kann die Zahlen stärker bewegen als das Tool.

GitHub weist bei seinem eigenen Copilot-Impact-Dashboard auf dasselbe hin: Der Adoption Multiplier vergleicht unterschiedliche Nutzergruppen, sodass Teamzusammensetzung, Projektkomplexität und Erfahrung ihn ebenso stark beeinflussen können wie die Nutzung. Wer Tools nach Teams verteilt, übernimmt dieses Problem.

Zwei Designs, bei denen die Arbeit gleich bleibt

Zufällige Zuteilung laufender Aufgaben

Jedes Team stellt einen Pool von Aufgaben zusammen, die ohnehin anstehen, und jede Aufgabe wird vor Arbeitsbeginn zufällig einem Tool zugeteilt, am besten getrennt nach Aufgabentyp. METR hat dieses Design 2025 in einer Studie mit erfahrenen Open-Source-Entwicklern genutzt und jedes echte Issue zufällig der Bedingung mit oder ohne KI-Tools zugeordnet, sodass beide Bedingungen dieselben Menschen und dieselbe Art von Arbeit hatten.

Replay gemergter Änderungen

Parallel zu den laufenden Aufgaben spielen Sie kürzlich gemergte Änderungen nach. Jeder Lauf arbeitet in einer isolierten Kopie des Repositorys, deren Historie beim Commit vor der Änderung endet, ohne spätere Commits, Remote-Refs, Caches oder Dateien aus früheren Versuchen und ohne Netzwerkweg zum gemergten Pull Request. Der Agent bekommt die Aufgabenbeschreibung und die vorhandene Testsuite; die Akzeptanztests, die mit der Änderung hinzukamen, werden zurückgehalten und erst danach ausgeführt. Das Replay vergleicht Korrektheit und Kosten bei identischen Eingaben, sagt aber nichts über den Review-Aufwand bei neuer Arbeit.

Störfaktoren, die vor dem ersten Tag geklärt sein müssen

Die folgenden Quellen für Unfairness sind vorhersehbar. Halten Sie fest, wie der Pilot mit jeder davon umgeht, bevor Ergebnisse vorliegen.

• Aufgabenauswahl: In METRs Folgestudie von 2026 gaben 30 bis 50 Prozent der befragten Entwickler an, Aufgaben zurückgehalten zu haben, die sie nicht ohne KI erledigen wollten. Legen Sie den Pool vor der Zuteilung fest und protokollieren Sie jede zurückgezogene Aufgabe mit Begründung.
• Ungleiches Setup: Bekommt ein Tool sorgfältige Repository-Anweisungen und einen funktionierenden Testbefehl und das andere nicht, vergleichen Sie Setups. Geben Sie jedem Kandidaten dieselben Anweisungen, Befehle und Berechtigungen und protokollieren Sie für jeden Lauf Tool-Version, Modell und Einstellungen.
• Selbst eingeschätztes Tempo: Die Teilnehmenden der METR-Studie von 2025 erwarteten, mit KI 24 Prozent schneller zu sein, und glaubten danach, 20 Prozent schneller gewesen zu sein, während die Messung 19 Prozent langsamer ergab. METR bezeichnet diese Ergebnisse inzwischen als veraltet, die Lücke zwischen Wahrnehmung und Messung gilt aber für jeden Pilot.
• Parallele Sitzungen: Wer mehrere Agenten gleichzeitig laufen lässt, macht die Zeit pro Aufgabe unzuverlässig, wie METR ebenfalls berichtet. Im Live-Teil sind Kosten pro angenommener Änderung und Review-Minuten die wichtigsten Effizienzmaße.

Ein ausgearbeiteter Plan für den Vergleich zweier Tools

Dieser Plan ist hypothetisch: Zwei Produktteams vergleichen sechs Wochen lang zwei Coding-Agenten. Die Zahlen sind Planungsannahmen, keine Ergebnisse.

1. 1

   Pools zusammenstellen

   Jedes Team listet 24 Aufgaben aus dem Backlog: acht Bugfixes, acht Aufgaben zur Testabdeckung und acht kleine Features, jede mit schriftlicher Beschreibung und einem Weg zur Überprüfung.

2. 2

   Zufällig zuteilen

   Innerhalb jedes Teams und Aufgabentyps teilt ein Skript vier Aufgaben Tool A und vier Tool B zu, und die Zuteilung wird committet, bevor jemand anfängt.

3. 3

   Setup angleichen

   Beide Tools bekommen dieselben Build- und Testbefehle, Review-Konventionen, Berechtigungen und denselben Netzwerkzugang, jeweils im eigenen Anweisungsformat.

4. 4

   Replay durchführen

   Dreißig im letzten Quartal gemergte Änderungen werden pro Tool dreimal nachgespielt, jeder Lauf in einer frischen, bereinigten Kopie des Repositorys, wobei die mit jeder Änderung hinzugefügten Tests für die Bewertung zurückgehalten werden. Berichtet werden pro Aufgabentyp die Erfolgsquote auf diesen zurückgehaltenen Tests und die Kosten pro bestandener Replay-Aufgabe, gescheiterte Versuche eingeschlossen.

5. 5

   Review wie gewohnt

   Pull Requests der Agenten laufen durch das normale Review und die erforderlichen Checks. Reviewer notieren Review-Minuten und Nacharbeit und ob die Änderung die Definition einer angenommenen Live-Änderung erfüllt.

Die Entscheidungsregel vor dem ersten Lauf festhalten

GitHubs Leitfaden für Pilotprojekte mit einer Copilot-Funktion oder einem Modell empfiehlt, vor dem Start festzulegen, wie ein Go aussieht, und mindestens einen vollen Abrechnungszyklus zu testen, typischerweise vier bis sechs Wochen. Ein Vergleich zwischen Tools braucht dieselbe Disziplin.

• Zwei Erfolgsdefinitionen: Eine Replay-Aufgabe besteht, wenn die zurückgehaltenen Tests und die vorhandene Suite bestehen und der Diff im Umfang bleibt; eine Live-Änderung gilt als angenommen, wenn sie die Pflicht-Checks und das Review besteht und innerhalb eines vereinbarten Zeitfensters ohne Nacharbeit gemergt wird.
• Getrennte Maße: Kosten pro bestandener Replay-Aufgabe sowie Kosten pro angenommener Live-Änderung einschließlich Review-Minuten und Nacharbeit. Die beiden werden nie zusammengerechnet.
• Eine praktische Schwelle: der kleinste Unterschied, der Ihre Entscheidung ändern würde, zum Beispiel zehn Prozentpunkte Erfolgsquote, eine hypothetische Zahl. Vergleichen Sie die Tools Fall für Fall auf denselben Replay-Aufgaben, führen Sie jede mehrmals aus, und wenn die Streuung über Fälle und Durchläufe so groß ist wie die Schwelle, halten Sie das Ergebnis als nicht eindeutig fest.

Nicht eindeutig ist ein legitimes Ergebnis, weil die Ergebnisse eines Agenten von Lauf zu Lauf schwanken; Anthropics Leitfaden zur Evaluierung behandelt wiederholte Durchläufe als normale Messmethode für Agenten. Ein Gleichstand unterhalb Ihrer Schwelle heißt, nach anderen Kriterien zu entscheiden, etwa Kosten oder Passung zu Ihren Kontrollen.

Wo dieses Design an Grenzen stößt

Zufällige Zuteilung braucht genug vergleichbare Aufgaben pro Typ. Kommen während des Pilots zu wenige zusammen, ist der Live-Vergleich nicht eindeutig, und der Bericht sollte das sagen. Replay und Live-Teil beantworten unterschiedliche Fragen: Das Replay deckt Korrektheit und Kosten bei bekannten Änderungen ab, der Live-Teil Review-Aufwand und Passung bei neuer Arbeit. Reviewer wissen unter Umständen, welches Tool einen Pull Request geschrieben hat, deshalb sollte die Definition für Live-Änderungen mechanisch sein.

Lassen Sicherheitsanforderungen, Datenresidenz oder Ihr Git-Host nur ein Tool zu, verzichten Sie auf den Vergleich und pilotieren Sie dieses Tool gegen die eigene Ausgangslage des Teams. Ein erstes Gespräch von 30 Minuten mit einem unserer Engineers zu beiden Designs braucht keinen Systemzugang und keine Produktionsdaten.

Copilot-Pilotmetriken richtig lesenEvaluierungen auf Ihren Repositories