Messen Sie den Durchsatz von Coding-Agenten anhand zweier Zahlen, die zusammen gelesen werden müssen: gemergte Pull Requests und die Ablehnungsrate (Denial Rate), also der Anteil der Pull Requests, die ohne Merge geschlossen wurden. Ergänzen Sie dies um die Zykluszeit vom Plan bis zum Merge und die Kosten pro gemergter Pull Request – schon wissen Sie verlässlich, ob Agenten akzeptierte Arbeit zu einem vertretbaren Preis liefern. Eröffnete Pull Requests, die Kennzahl, die die meisten Teams zuerst heranziehen, reicht für sich allein nicht aus: Ein Agent kann fünfzig Pull Requests am Tag eröffnen, die niemand mergt, und die Zahl sieht dennoch nach Fortschritt aus. Dieser Artikel definiert jede Kennzahl, erklärt, was ein schlechter Wert bedeutet, und zeigt, wie Ivy Tendril und ein kostenloser Rechner von Ivy diese Daten erfassen.

Die Metriken

Metrik	Definition	Was ein schlechter Wert bedeutet
PRs eröffnet	Im Zeitraum erstellte Pull Requests	Für sich genommen nichts. Hoch und steigend bei stagnierenden Merges bedeutet: Die Agenten produzieren Arbeit, die das Team nicht will
PRs gemergt	Im Zeitraum gemergte Pull Requests	Stagnierend oder fallend, während Eröffnungen steigen: Das Review ist der langsamste Schritt oder die Qualität sinkt
Ablehnungsrate	Ohne Merge geschlossene PRs, geteilt durch alle geschlossenen PRs (gemergt plus ungemergt geschlossen)	Hoch: Pläne sind fehlerhaft, Verifikation ist schwach oder Reviewer lehnen spät ab. Nahe null bei geringem Volumen: Es wird nur die risikoärmste Arbeit versucht
Zykluszeit	Zeit von der Planerstellung bis zum Merge	Lang: Arbeit wartet an einem menschlichen Checkpoint. Finden Sie heraus, an welchem
Kosten pro gemergter PR	Gesamte Tokens oder Dollar im Zeitraum, geteilt durch gemergte PRs	Steigend: Wiederholungsversuche (Retries), überdimensionierte Pläne oder ein teures Modell, wo ein günstigeres die Verifikation bestehen würde
Verifikations-Bestehensrate	Anteil der Ausführungen, die Tests, Linting und Build beim ersten Versuch bestehen	Niedrig: Pläne sind unzureichend spezifiziert oder dem Agenten fehlt der Kontext zur Codebasis

Zwei Definitionen erfordern besondere Sorgfalt. Die Ablehnungsrate nutzt geschlossene PRs als Nenner – nicht geöffnete PRs –, damit offene Pull Requests, die sich noch im Review befinden, weder als akzeptiert noch als abgelehnt zählen. Die Kosten pro gemergter PR teilen alle Ausgaben – einschließlich der Ausgaben für abgelehnte oder abgebrochene Pläne – ausschließlich durch die tatsächlich gemergten Pull Requests. Das ist beabsichtigt: Die Kosten der verworfenen Arbeit gehören zu den Kosten der gemergten Arbeit.

Warum gemergte PRs und Ablehnungsrate das ehrliche Kennzahlenpaar sind

Jede einzelne Metrik lässt sich verbessern, indem man eine andere verschlechtert.

Eröffnete PRs steigen, wenn man die Kriterien für die Ausführung lockert. Die Ablehnungsrate steigt parallel dazu.
Gemergte PRs steigen, wenn Reviewer schneller durchwinken. Fehler nach dem Merge nehmen zu, und die Ablehnungsrate sinkt aus dem falschen Grund.
Die Ablehnungsrate sinkt, wenn man nur die sichersten Pläne ausführt. Gemergte PRs sinken parallel dazu.

Derselbe Gedanke liegt den DORA-Metriken zugrunde, bei denen Durchsatz und Stabilität stets als Paar ausgewiesen werden – genau deshalb, weil jede isolierte Zahl manipuliert werden kann, indem man die andere opfert. Gemergte PRs und Ablehnungsrate gemeinsam betrachtet verhindern dies. Um mehr Merges ohne höhere Ablehnungsrate zu erzielen, muss mehr Arbeit produziert werden, die das Team tatsächlich akzeptiert. Um die Ablehnungsrate ohne Merge-Rückgang zu senken, müssen Pläne oder Verifikationsschritte verbessert werden, statt schlicht weniger auszuführen. Keine der beiden Zahlen lässt sich isoliert optimieren, ohne die andere zu beachten.

Eröffnete PRs sind deshalb so verlockend, weil sie das erste greifbare Ergebnis eines Agenten und am einfachsten zu zählen sind. Doch ein eröffneter Pull Request ist zunächst nur eine Bitte um Arbeitszeit eines Menschen. Anträge als Output zu werten belohnt Agenten dafür, Arbeit für Reviewer zu schaffen. Merges zu zählen belohnt sie dafür, Arbeit fertigzustellen.

Ivy veröffentlicht seine eigenen Daten nach diesem Prinzip. Das Diagramm zu PRs pro Tag im Verhältnis zur Ablehnungsrate auf der Seite Warum Ivy basiert auf 1.946 Pull Requests in Ivy-Repositories von Februar bis April 2026. Ivy berichtet, dass sein Team von rund 10 auf mehr als 100 Pull Requests pro Tag skalieren konnte, nachdem der Workflow aus Planen, Ausführen, Verifizieren und Reviewen eingeführt wurde, den das Unternehmen als Software Factory bezeichnet. Das Volumen wird direkt neben der Ablehnungsrate gezeigt, da es isoliert betrachtet nichts beweisen würde.

Kosten pro gemergter PR und Verifikations-Bestehensrate

Sobald gemergte PRs und die Ablehnungsrate etabliert sind, zeigen die Kosten pro gemergter Pull Request, was die akzeptierte Arbeit tatsächlich kostet. Das ist die Zahl, die von einem CTO verlangt wird – und sie muss in Dollar oder Tokens pro gemergter Änderung beziffert werden, nicht pro Plan oder Einzelausführung, damit Retries und verworfene Arbeit enthalten sind.

Kosten pro gemergter Pull Request machen zudem Warteschlangen sichtbar: Nach Littles Gesetz führt ein wachsender Rückstau offener Pull Requests bei gleichbleibender Merge-Rate unweigerlich zu steigenden Zykluszeiten – ganz gleich, ob diese explizit gemessen werden. Drei Faktoren beeinflussen die Kosten pro gemergter PR:

Retries. Jede fehlgeschlagene Verifikation bedeutet einen erneuten Durchlauf. Die Verifikations-Bestehensrate ist hier der Frühindikator: Fällt sie ab, steigen wenige Tage später die Kosten pro gemergter PR. Verifikations-Gates erläutert, was geprüft werden muss und warum das Plan-Gate am wichtigsten ist.
Plangröße. Große Pläne kosten mehr pro Ausführung und werden häufiger abgelehnt, weil Reviewer mehr Ansatzpunkte für Einwände finden. Das Aufteilen eines Plans in kleinere Einheiten senkt meist sowohl die Ablehnungsrate als auch die Kosten pro gemergter PR – um den Preis von mehr Einzel-PRs im Review.
Modellwahl. Ein günstigeres Modell, das die Verifikation mit gleicher Quote besteht, spart unmittelbar Geld. Die einzige Möglichkeit, dies festzustellen, besteht darin, Kosten und Bestehensrate pro Plan zu erfassen und verschiedene Modelle auf derselben Codebasis zu vergleichen.

Zum grundlegenden Wandel von der Messung bloßer Entwickleraktivität hin zu akzeptiertem Output siehe In the loop, out of the loop: der KPI-Wandel hinter Agentic Engineering.

Wie Ivy Tendril diese Kennzahlen erfasst

Ivy Tendril ist eine Local-First-Desktop-Anwendung (macOS, Windows, Linux), die Coding-Agenten vom Plan bis zum geprüften Pull Request orchestriert. Es zeichnet die Daten für jede oben genannte Metrik direkt während des Workflows auf. Es muss nichts separat instrumentiert werden.

Dashboard. Das Dashboard zeigt den Planstatus über den gesamten Lebenszyklus, Kosten-KPIs, Trendkurven im Zeitverlauf und Git-Aktivitäten für die angebundenen Repositories. Der Planstatus liefert eröffnete, gemergte und abgelehnte PRs; die Git-Aktivität dokumentiert die Merge-Historie.
Kosten pro Plan und pro Job. Tokens und Kosten werden für jeden Plan und für jeden Job innerhalb eines Plans erfasst. Ein Plan, der drei Ausführungsjobs benötigte, bevor die Verifikation erfolgreich war, weist alle drei aus – die Kosten pro gemergter PR schließen Retries somit bauartbedingt ein. Die Oberfläche Jobs visualisiert die Streaming-Ausgaben und Tool-Aufrufe jedes Jobs zusammen mit dessen Kosten.
Agenten- und Modellvergleich. Tendril steuert Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode und beliebige andere CLI-Agenten. Agent und Modell werden pro Plan festgelegt. Kosten und Bestehensrate lassen sich daher modellspezifisch auf derselben Codebasis vergleichen, ohne den Arbeitsablauf zu verändern.
Lokale Daten. Pläne, Logs und Kostenprotokolle verbleiben auf dem lokalen Rechner. Externe Aufrufe erfolgen ausschließlich an die von Ihnen konfigurierte Modell-API und an GitHub.

Für Teams, die Tendril noch nicht nutzen, stellt Ivy einen kostenlosen Open-Source-PR Cost Calculator bereit. Er liest öffentliche GitHub-Daten eines Repositorys aus und berechnet rollierende 14-Tage-Werte für gemergte PRs und die Ablehnungsrate, sodass Teams ihren Ausgangszustand festhalten können, bevor sie Veränderungen vornehmen. Testen Sie ihn noch heute an Ihrem Repository und erneut einen Monat nach Einführung von Agenten.

Erste Schritte

Baseline ermitteln: Führen Sie den PR Cost Calculator auf Ihrem Haupt-Repository aus und erfassen Sie die rollierenden 14-Tage-Werte für gemergte PRs und Ablehnungsrate.
Tendril installieren: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) oder irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). Dokumentation unter Installation.
Zwei Wochen lang Pläne ausführen und das Dashboard analysieren: Gemergte PRs, abgelehnte PRs, Kosten pro Plan und Trends.
Berechnen Sie die Kosten pro gemergter PR einmal manuell (Gesamtausgaben geteilt durch Anzahl gemergter PRs), damit im Team Einigkeit über die Definition herrscht, bevor die Zahl offiziell berichtet wird.

Tendril ist kostenlos und Source-Available unter der Functional Source License verfügbar. Team-Funktionen, On-Premises-Hosting, SSO und CI-Verifikations-Importe sind in den Tarifen Pro (59 $ pro Benutzer/Monat) und Enterprise enthalten.

Häufig gestellte Fragen

Was ist eine gute Ablehnungsrate?

Es gibt keinen universellen Richtwert, und eine Quote von null bedeutet meist nur, dass keinerlei risikobehaftete Aufgaben angegangen werden. Beobachten Sie Ihre eigene Rate im Zeitverlauf und werten Sie einen Anstieg als Signal, Planqualität und Verifikation zu prüfen – nicht als Vorgabe, die Ausführung künstlich zu drosseln.

Sollten die Kosten pro gemergter PR menschliche Review-Zeiten enthalten?

Beziehen Sie diese ein, wenn Sie sie konsistent messen können. Die meisten Teams starten mit Token- oder Modellkosten, da diese automatisch erfasst werden, und ergänzen Prüfzeiten der Entwickler, sobald sich die Definition eingespielt hat. Beide Werte vor einer klaren methodischen Einigung zu vermischen, erschwert den Monatsvergleich erheblich.

Wie unterscheiden sich diese Kennzahlen von DORA-Metriken?

Sie überschneiden sich. Die Zykluszeit vom Plan bis zum Merge ähnelt der Lead Time for Changes. Für die Ablehnungsrate gibt es bei DORA kein direktes Äquivalent, da DORA davon ausgeht, dass ein Mensch den Code geschrieben hat, und primär fragt, ob er bereitgestellt wurde. Die Ablehnungsrate fragt hingegen, ob die Änderung überhaupt akzeptiert wurde – was zur entscheidenden Frage wird, sobald Agenten die Entwürfe liefern.

Erste Schritte mit Ivy Tendril

Sind Sie bereit für parallele Agenten-Orchestrierung auf Entwickler-Niveau?

Code erkunden: Untersuchen Sie Ivy Tendril auf GitHub (Open Source).
Dokumentation lesen: Finden Sie Integrationsanleitungen unter tendril.ivy.app.
Architektur-Sitzung vereinbaren: Kontaktieren Sie renco@ivy.app für eine 30-minütige technische Beratung.

Agenten-Durchsatz messen: Gemergte PRs, Ablehnungsrate und Kosten pro PR