Was unser Coding-Agent je angenommener Änderung kostet
Wir betreiben einen Agenten lange genug auf unseren eigenen Repositories, um echte Kosten je angenommenem Pull Request zu haben. Sie liegen höher, als die Tokenrechnung nahelegt, und niedriger als die ersetzte Stunde — und im Abstand dieser beiden Zahlen wohnt jede Diskussion darüber.
Die Zahl, mit der wir angefangen haben
Tokenkosten je Pull Request, den der Agent öffnet. Sie ist leicht zu messen, steht auf einer Rechnung und macht rund ein Fünftel dessen aus, was der Agent uns tatsächlich kostet. Sie zu nennen ist der Weg, auf dem ein Business Case für einen Agenten genehmigt wird und danach still nicht liefert.
Der Rest ist Prüfung. Jeder Vorschlag wird von einem Entwickler gelesen, auch die abgelehnten, und ein abgelehnter Vorschlag kostet eine Prüfung ohne Ergebnis. Unsere Annahmequote liegt knapp unter einem Drittel, die meisten Prüfungen erbringen also nichts.
Was wir heute messen
Vier Zahlen: Token je Vorschlag, Prüfminuten je Vorschlag, Annahmequote und die Entwicklerzeit, die die angenommene Änderung sonst gekostet hätte. Die vierte ist eine Schätzung, vom Prüfenden bei der Annahme abgegeben, und die einzige, die den Agenten mit Wert verbindet.
Die Kosten je angenommener Änderung sind dann Token plus Prüfung geteilt durch die Annahmequote — was ausdrücklich macht, dass abgelehnte Vorschläge von den angenommenen bezahlt werden. Bei einem Drittel Annahme trägt jede angenommene Änderung rund drei Prüfungen.
Die Forschung zum selben Handel
Peng und Kollegen veröffentlichten 2026 eine Arbeit zur Inferenzökonomie von Coding-Agenten im Unternehmen, die über Schnittstellen genutzte Spitzenmodelle gegen quantisierte Modelle mit offenen Gewichten im Eigenbetrieb stellt und die Wahl als wirtschaftliche Frage behandelt statt als Leistungsfrage.
Das ist dieselbe Rahmung, zu der wir von der Rechnung her gekommen sind. Ihr Vergleich ergänzt das Grenzkostenargument für Eigenbetrieb bei Menge — bedeutsam für ein Team, das Agenten durchgängig betreibt, und für unsere Antwort ohne Folge, weil unser Volumen überschaubar ist.
| Kostenbestandteil | Anteil an der Summe |
|---|---|
| Token für angenommene Vorschläge | Etwa ein Fünftel |
| Token für abgelehnte Vorschläge | Etwa ein Zehntel |
| Prüfung angenommener Vorschläge | Etwa ein Viertel |
| Prüfung abgelehnter Vorschläge | Der größte Einzelanteil |
Was sich durch das Messen geändert hat
Wir haben eingeengt, was der Agent überhaupt versucht. Früher versuchte er jeden fehlschlagenden Test; heute nur Fehlschläge, die Mustern entsprechen, bei denen unsere Annahmequote über der Hälfte lag — rund ein Drittel der Fehlschläge und die meisten der ohnehin angenommenen.
Die Vorschläge fielen um etwa sechzig Prozent, die angenommenen Änderungen um rund fünfzehn, und die Kosten je angenommener Änderung fielen um fast die Hälfte. Der Agent tut weniger und liefert fast ebenso viel — die Gestalt der meisten ehrlichen Optimierungen und nicht das, was jemand zu finden hoffte.
Die Zahl, die es entscheidet
Prüfminuten je abgelehntem Vorschlag. Unsere liegen bei etwa vier, denn ein abgelehnter Vorschlag ist meist offensichtlich falsch und ein Prüfender sieht es schnell. Wären es zwölf, würde der Agent bei unserer Annahmequote mehr kosten, als er spart, und wir würden ihn abschalten.
Diese Schwelle gehört genannt, weil sie an der Erfahrung der Prüfenden mit der Codebasis hängt und nicht am Modell. Ein Team mit langsamen Prüfungen bekommt weniger von einem Agenten, und keine Modellverbesserung ändert diese Rechnung.
Was wir nicht als Ersparnis zählen
Zeit, die der Agent aufwendet und auf die niemand wartete. Er arbeitet nachts an Fehlschlägen, und dass um neun Uhr eine Behebung vorliegt, ist bequem und keine Ersparnis — es sei denn, jemand hätte sie sonst gemacht.
Wir zählen auch die Änderungen nicht, die nie gemacht worden wären. Rund ein Fünftel der angenommenen Vorschläge behebt Dinge, die niemand priorisiert hatte; das ist echter Wert und keine Kostenersparnis, und ihn in die Sparspalte zu schreiben ist der Weg, auf dem solche Zahlen zur Erfindung werden.
Cloud oder Eigenbetrieb für diese Last
Cloud, bei uns, und die Begründung ist dieselbe wie überall sonst in diesem Blog. Unser Volumen liegt bei einigen hundert Vorschlägen im Monat, weit unter der Grenze, ab der feste Infrastruktur gewinnt — und die Betriebslast fiele demselben kleinen Team zu, das die Vorschläge prüft.
Bei Menge kippt die Rechnung, und genau das untersucht die Arbeit. Ein Team mit Tausenden Vorschlägen im Monat hat eine andere Antwort, und wir würden den Vergleich rechnen, statt anzunehmen, unser Ergebnis übertrage sich.
Was wir nicht behaupten
Wir behaupten nicht, unsere Kosten je angenommener Änderung seien übertragbar. Es sind unsere Codebasis, unsere Testsuite, unsere Prüfenden und unsere Annahmekriterien — und der größte Posten ist die Prüfzeit, die teamspezifischste Größe in der Rechnung.
Wir behaupten auch nicht, der Agent lohne sich eindeutig. Bei unseren Zahlen lohnt er sich mit einem Abstand, den eine schlechtere Annahmequote oder langsamere Prüfungen umkehren würden — wir rechnen quartalsweise nach, statt die Entscheidung für erledigt zu halten.