LeistungenCoding-Agenten
Evaluierung von Coding-Agenten an Änderungen, die Sie bereits gemergt haben
Bevor Sie sich für ein Tool, ein Modell oder eine Einstellung entscheiden, spielen wir Änderungen aus Ihren eigenen Repositories erneut durch, mit Tests, die der Agent nicht sehen kann. Wir vergleichen Kosten, Akzeptanz und Review-Aufwand. Danach prüfen wir das Ergebnis an laufender Arbeit.
Was bei einem Replay passiert
- 1
Frühere Änderungen auswählen
Aufgaben aus Ihrer Historie, die Ihre übliche Arbeit abbilden
- 2
Repository zurücksetzen
Jeder Kandidat beginnt beim Commit direkt vor dieser Änderung
- 3
Jeden Kandidaten arbeiten lassen
Für jeden dieselbe Aufgabe, protokolliert mit Tool, Modell und Einstellungen
- 4
Tests verborgen halten
Die Tests, die zur Änderung gehören, bekommt der Agent nicht zu sehen
- 5
Ergebnisse vergleichen
Welche Änderungen akzeptiert werden, was Reviewer anmerken und was eine akzeptierte Änderung kostet
Woran wir jeden Lauf messen
Drei Dinge bestimmen einen Lauf: das Tool, das Modell dahinter und deren Konfiguration. Wir protokollieren alle drei. Sofern das Tool es erlaubt, ändern wir jeweils nur eines davon.
Daneben zählen wir Wiederholungen, Reverts, Nacharbeit und Anmerkungen aus dem Review. Ergebnisse weisen wir je Aufgabentyp aus. So wird sichtbar, falls bei Bugfixes ein anderer Kandidat vorn liegt als beim Refactoring.
Wie wir eine akzeptierte Änderung definieren
Die Kriterien für Akzeptanz legen wir mit Ihnen fest, bevor irgendetwas läuft. Eine Änderung zählt, wenn sie die zurückgehaltenen Tests besteht, im Umfang der Aufgabe bleibt und von einem Reviewer so gemergt werden könnte, wie sie ist. Den Review-Aufwand messen wir als die Zeit, die ein Reviewer für jede Änderung aufwendet. In die Kosten einer akzeptierten Änderung fließen jeder Wiederholungsversuch und jeder abgebrochene Lauf ein. Einem Kandidaten, der pro Lauf günstig ist, aber drei Anläufe braucht, werden also alle drei angerechnet.
Ergebnisse an laufender Arbeit bestätigen
Ein Replay allein entscheidet nie. Eine Gruppe von Aufgaben bleibt aus jedem Tuning heraus, und jedes Ergebnis bestätigen wir an Aufgaben, an denen Ihre Engineers gerade arbeiten, bevor sich jemand darauf stützt. Damit sind die zwei Fälle abgedeckt, in denen ein Replay täuschen kann: künftige Arbeit, die anders aussieht als frühere Aufgaben, und Änderungen, die jeden Test bestehen und trotzdem falsch sind.
Entscheidungen über neue Modelle und Harness-Änderungen
Wenn ein neues Modell erscheint oder sich Ihr Harness ändert, liefert dasselbe Setup die Belege für die Entscheidung, ob Sie die Änderung breiter ausrollen. Weil wir jede Änderung einzeln testen und jeden Lauf festhalten, kann Ihr Team die Evaluierung selbst wiederholen.
Änderungen an einem Workflow testen
Die Methode greift auch dann, wenn sich nicht das Tool ändert, sondern die Art, wie es genutzt wird. Sie können einen angepassten pstack-Skill oder ein angepasstes Playbook neben Ihrem Basis-Setup laufen lassen, mit einem gemeinsamen Satz abgegrenzter Aufgaben für beide. Dasselbe gilt für zwei Kilo-Konfigurationen, die sich im Provider oder im Modell unterscheiden. Sessions in Devin Desktop lassen sich nur dann mit Arbeit vergleichen, die an die Cloud übergeben wurde, wenn das Produkt auf einem wiederhergestellten Checkout beginnen kann. Die Tests müssen außerhalb dieses Checkouts bleiben. Kann das Produkt das nicht, liefert ein Pilot an Ihrer laufenden Arbeit fairere Belege. Für jeden Aufgabentyp zeigt der Bericht Korrektheit, Wiederholungen, Review-Aufwand und Kosten.
pstack in Cursor nutzen · Kilo einrichten · Aufgaben an Devin übergeben
Was Sie aus einer Evaluierung mitnehmen
- Ein Aufgabenset aus Ihrer Historie gemergter Änderungen, mit einem separaten Holdout-Set
- Ergebnisse nach Aufgabentyp, mit Kosten pro akzeptierter Änderung
- Aufzeichnungen aller Läufe, mit denen Ihr Team jedes Ergebnis reproduzieren kann
- Eine kurze schriftliche Empfehlung, die auch die Lücken in den Belegen benennt
Was die Evaluierung klärt
- Was jede akzeptierte Änderung kostet, gerechnet in Ausgaben und in Review-Zeit
- Akzeptierte Änderungen je Tool, Modell und Einstellung, gezählt auf Ihrer Codebasis
- Eine festgehaltene Entscheidung samt ihrer Datengrundlage
Fragen
Wohin gelangt unser Quellcode während einer Evaluierung?
Nur zu den Modell-Endpunkten, die Sie freigeben. Umfang, Zugriffe und jeden Datenfluss klären wir vorab mit Ihnen.
Wie groß muss das Aufgabenset sein?
Groß genug, um die Kandidaten voneinander zu unterscheiden. Ein deutlicher Abstand zwischen zwei Kandidaten zeigt sich schon nach wenigen Aufgaben. Ein knapper Abstand braucht mehr Aufgaben und mehrere Läufe pro Aufgabe, weil ein Agent nicht bei jedem Lauf dasselbe liefert. Die Größe bestimmen wir beim Scoping. Sie richtet sich nach dieser Schwankung und danach, wie viele passende Änderungen Ihre Historie enthält.
Lässt sich der Einfluss des Tools von dem des Modells trennen?
Ja, sofern das Tool die Wahl des Modells erlaubt. Ein Beispiel ist der Terminal-Agent OpenCode: Das Modell kann gleich bleiben, während das Tool wechselt, oder das Tool bleibt, während das Modell wechselt. Bringt ein Tool nur eigene Modelle mit, lassen sich Tool und Modell nur gemeinsam vergleichen.
Können wir weitere Tools in den Vergleich aufnehmen?
Ja, wenn Ihre Organisation das Tool erlaubt und es von einem wiederhergestellten Checkout aus arbeiten kann, ohne Zugriff auf die Tests. Cline, Google Antigravity, Kiro und Devin Desktop (früher Windsurf) kommen infrage. Wir prüfen jedes davon, wenn wir den Umfang festlegen.
Warum nicht einfach öffentliche Benchmarks nutzen?
Um eine Shortlist einzugrenzen, sind sie nützlich. Benchmarks wie SWE-bench beziehen ihre Aufgaben aber aus anderen Repositories, nicht aus Ihren. Ein Replay der gemergten Arbeit Ihres Teams zeigt Ihnen, wie gut ein Kandidat mit Ihrem Code und Ihren Tests umgeht und ob er die Messlatte Ihrer Reviewer erreicht.
Verwandte Leistungen
LLM-Kostenoptimierung
Agentenkosten, aufgeschlüsselt nach Team und Aufgabe und gesenkt durch Voreinstellungen, Budgets und Routing, die Ihr Plattformteam selbst betreiben kann.
Harness Engineering
Das Setup, das einem Agenten sagt, wie er Ihren Code baut, testet und ändert, abgelegt in der Versionskontrolle.
Einführung von Coding-Agenten
Der Einsatz von Agenten, ausgeweitet von wenigen Pilotteams auf die gesamte Entwicklung, mit Schulungen und einem gemeinsamen Setup.
Aus dem Blog
Design eines Coding-Agent-Piloten
Wie Sie Coding-Agenten an derselben Arbeit vergleichen: zufällige Zuteilung der Aufgaben, ein Replay gemergter Änderungen und eine vorab vereinbarte Entscheidungsregel.
Upgrades von Coding-Agenten testen
Wie Sie prüfen, ob ein neues Modell oder eine neue Agentenversion auf Ihren Repositories besser ist, bevor sie Teamstandard wird, mit fixierten Versionen und einem paarweisen Vergleich.
Mit einem Engineer sprechen
Bringen Sie eine Aufgabe mit, die Sie verbessern möchten. Das Gespräch dauert 30 Minuten und braucht keinen Zugriff auf Ihre Systeme oder Ihre Daten.
Die Buchung läuft über Google Kalender.
Lieber zuerst schreiben? Hinterlassen Sie Ihre E-Mail-Adresse und ein paar Zeilen, dann antworten wir mit Terminvorschlägen.
Sehen Sie in Ihrem E-Mail-Programm nach dem Entwurf
Senden Sie ihn von dort ab, und ein Engineer antwortet Ihnen persönlich mit Terminvorschlägen für ein 30-minütiges Gespräch. Hat sich kein Entwurf geöffnet, schreiben Sie uns an miki@cloudsail.com.