Sind AI Coding Agents effizienter, wenn sie mehr Code erzeugen? Einordnung der Studie 2026

Für wen dieser Beitrag gedacht ist: Wenn Sie in Engineering Effectiveness, Plattformarbeit oder als Entwicklungsleitung einen Agent-Pilot bewerten, finden Sie hier ein Raster für aussagekräftigere Teamkennzahlen. Als Code-Reviewer können Sie damit prüfen, ob zusätzliche Änderungen einen Rückstau oder mehr Nacharbeit erzeugen.

Zuletzt aktualisiert am 13.10.2026. Die Datumsangabe und die Forschungsbefunde wurden mit der am 04.08.2026 datierten Autorenfassung abgeglichen; die jüngere Berichterstattung dient hier nur zur Einordnung der Diskussion vom 09. bis 12.10.2026 (Autorenfassung, Bericht zur erneuten Diskussion).

1Mehr Codeaktivität oder mehr Lieferung: Was die Effizienzstudie zu AI Coding Agents 2026 aussagt

Die Arbeit ist eine versionierte Arbeitsfassung, keine allgemeingültige Messung aller Entwicklungsteams. Ihre Ergebnisse beziehen sich auf einen spezifischen Datensatz aus einem Engineering-Analyseumfeld und auf die dort verfügbaren Unternehmens- und Aktivitätsdaten. Das ist wichtig, weil ein Zusammenhang in einem solchen Datensatz nicht automatisch belegt, dass der Agent die beobachtete Veränderung verursacht hat. Ebenso wenig lässt sich daraus ableiten, dass jedes Unternehmen mit anderen Werkzeugen, Review-Regeln oder Aufgabenprofilen dieselben Resultate erzielt.

Für die Interpretation hilft es, vier Ebenen auseinanderzuhalten, die in der Diskussion leicht vermischt werden: die untersuchte Nutzung von Agent- beziehungsweise Assistant-Werkzeugen, beobachtete Codeaktivität, Abläufe in der Codeprüfung und abgeschlossene Jira-Arbeit. Die erste Ebene beschreibt die Art der Werkzeugnutzung; die zweite zählt Aktivitäten rund um Code. Review-Signale zeigen, was mit Änderungen während der Prüfung geschieht. Abgeschlossene Arbeit liegt näher am tatsächlich erledigten Auftrag, beantwortet aber ebenfalls nicht jede Frage zu Qualität, Nutzen oder Kundenauswirkung. Die Autorenfassung ist daher die maßgebliche Quelle für Begriffe, Forschungsdesign und Grenzen der Auswertung.

Der Unterschied zwischen Agent und Assistant ist für die Übertragung auf Ihren Alltag nicht nebensächlich: Unterstützende Funktionen, die einzelne Vorschläge liefern, sind nicht zwingend mit Agenten gleichzusetzen, die Arbeitsschritte selbstständig ausführen. Prüfen Sie deshalb vor einem Vergleich, welche Nutzungsform Ihr Team tatsächlich testet. Wenn ein Pilot mehrere Funktionen oder Arbeitsweisen bündelt, ist ein beobachteter Effekt nicht ohne Weiteres einer einzelnen davon zuzuordnen.

Auch der Begriff „Produktivität“ braucht mehr als einen Messwert. Das SPACE-Framework zur Entwicklerproduktivität behandelt Produktivität als mehrdimensional und warnt damit vor einer verkürzten Gleichsetzung von Aktivität und Ergebnis. Für Ihren Pilot bedeutet das: Eine einzelne Messgröße eignet sich selten als vollständige Antwort auf die Frage, ob die Arbeitsweise besser geworden ist.

2Für Entwicklungsleitungen: Aktivität nicht mit erledigten Anforderungen verwechseln

Wenn in einem Team die Zahl der Commits oder Pull Requests steigt, ist zunächst nur eine Veränderung der sichtbaren Aktivität festgestellt. Eine Anforderung kann mehrere PRs benötigen, ein größerer PR kann mehrere Aufgaben bündeln, und erzeugte Änderungen können vor der Integration noch angepasst oder verworfen werden. Deshalb ist „mehr Code“ weder gleichbedeutend mit mehr fertiger Software noch automatisch ein Zeichen für bessere Lieferfähigkeit.

Der Forschungsbefund liefert einen konkreten Prüfauftrag, aber keine fertige Managemententscheidung: In der ausgewerteten Stichprobe wurde kein signifikanter Zuwachs abgeschlossener Jira-Arbeit berichtet, obwohl Agent-Nutzung mit mehr Codeaktivität verbunden war. Das ist ein Hinweis, Ihre eigenen Ergebniskennzahlen gesondert zu erfassen. Es ist kein Beweis dafür, dass Agenten in jedem Team wirkungslos sind. Aufgabenmix, Teamroutine, Architektur und die Art, wie Arbeit in Jira erfasst wird, können das Ergebnis beeinflussen.

Stellen Sie vor einer Ausweitung des Pilots folgende Fragen:

• Werden Anforderungen nach denselben Kriterien als abgeschlossen gezählt wie vor dem Pilot?
• Verändert sich die Zeit von Arbeitsbeginn bis zur Integration, oder steigt nur die sichtbare Aktivität?
• Bleibt die Rückarbeit stabil, oder werden zusätzliche Änderungen erst nach der ersten Prüfung sichtbar?
• Werden Ergebnisse tatsächlich genutzt, oder verschiebt der Agent Arbeit lediglich in spätere Phasen?

Die DORA-Anleitung zu Softwarebereitstellungskennzahlen bietet eine Orientierung für Kennzahlen rund um Bereitstellung. Nutzen Sie sie nicht als Ersatz für Ihre Teamdefinitionen: Vergleichen Sie nur Daten, bei denen Zeitfenster, Teamumfang und Ereignisdefinition tatsächlich zusammenpassen. Eine schnellere Codeproduktion kann sonst einen Engpass verdecken, statt ihn zu beseitigen.

3Für Code-Reviewer: Mehr PRs können den Engpass nur verlagern

Eine Änderung ist nicht fertig, sobald der Agent sie erzeugt hat. Sie muss verstanden, auf Risiken geprüft, gegebenenfalls überarbeitet und in den bestehenden Entwicklungsablauf integriert werden. Die Studie weist auf Review-Aufwand als mögliche Engstelle hin, darunter Prüfzeit, Kommentare und Änderungsanforderungen. Diese Signale sind für ein Team nützlich, aber nicht isoliert zu interpretieren: Eine zusätzliche Änderungsanforderung kann auf eine notwendige Qualitätskorrektur hindeuten, aber auch auf besonders strenge Review-Regeln oder eine komplexe Änderung.

Die Grundmechanik eines Pull Requests macht deutlich, warum diese Unterscheidung zählt: Änderungen werden zur Prüfung vorgelegt, diskutiert und gegebenenfalls angepasst, bevor sie in einen gemeinsamen Entwicklungszweig einfließen. Die Dokumentation zum Pull-Request-Ablauf beschreibt diesen kooperativen Prozess. Wenn ein Agent mehr PRs oder größere Änderungssätze erzeugt, kann die Prüfkapazität zum begrenzenden Schritt werden. Das ist eine plausible Prozessfrage, aber noch kein Beleg, dass die Nutzung eines Agenten in Ihrem Team tatsächlich die Prüfzeit verlängert.

Achten Sie auf vergleichbare Änderungen: Wenn ein Pilot viele kleine, risikoarme Änderungen mit einer Ausgangsphase voller größerer Umbauten vergleicht, sagt der rohe Review-Zeitunterschied wenig aus. Trennen Sie Änderungen nach Umfang und Risikoklasse, bevor Sie Schlussfolgerungen ziehen.

Für die Diagnose sollten Sie die Warteschlange und die Rückarbeit gemeinsam betrachten. Bleiben PRs länger unbearbeitet? Steigt die Zahl offener Review-Anmerkungen? Werden Änderungen nach dem ersten Review häufiger überarbeitet? Und entstehen dabei neue Fehler oder lediglich mehr sichtbare Abstimmung? Wenn Sie diese Signale nicht gemeinsam lesen, können Sie „mehr Kommentare“ vorschnell als Qualitätsverlust deuten oder einen tatsächlichen Rückstau übersehen.

4Für Engineering Effectiveness: Ein Pilot braucht festgelegte Messpunkte

Machen Sie aus dem Studienbefund keine allgemeingültige Rezeptur. Die folgenden Prüfschritte sind ein Selbstcheck für Ihren Ablauf, nicht eine von der Arbeit validierte Standardmethode. Legen Sie die Definitionen fest, bevor Sie Werkzeugnutzung vergleichen; sonst können Sie einen Unterschied nachträglich nicht sauber von veränderten Erfassungsregeln unterscheiden.

1. Ausgangslage festhalten. Dokumentieren Sie vor dem Pilot, welche Teams und Aufgaben einbezogen sind, wie eine abgeschlossene Anforderung definiert wird und welche Zeitfenster Sie vergleichen. Halten Sie zugleich fest, welche Agent- oder Assistant-Funktionen tatsächlich verwendet werden.
2. Ergebniskennzahlen bestimmen. Wählen Sie Messpunkte, die erledigte Arbeit und Lieferung abbilden, etwa abgeschlossene Anforderungen oder die Zeit bis zur Integration. Definieren Sie für jeden Messpunkt, welche Ereignisse einbezogen werden und welche nicht.
3. Review-Ablauf separat beobachten. Erfassen Sie Wartezeit, Review-Kommentare und Änderungsanforderungen als Prozesssignale. Lesen Sie sie zusammen mit PR-Umfang und Risikoklasse, statt sie zu einem pauschalen Qualitätswert zusammenzufassen.
4. Qualität und Rückarbeit einbeziehen. Prüfen Sie, ob Änderungen nach der Prüfung angepasst werden müssen und ob sich nachgelagerte Korrekturen häufen. Welche Qualitätssignale geeignet sind, hängt von Ihrer Arbeit ab; verwenden Sie keine Kennzahl, deren Erfassung sich während des Vergleichs verändert.
5. Vergleich sauber begrenzen. Halten Sie Teamumfang, Aufgabentypen, Definitionen und Zeitfenster zwischen Ausgangslage und Pilot so konstant wie möglich. Wenn sich gleichzeitig Teamzuschnitt oder Review-Regeln ändern, kennzeichnen Sie das als Störfaktor, statt den Unterschied dem Agenten zuzuschreiben.
6. Entscheidung an Bedingungen knüpfen. Weiten Sie einen Pilot nur dann aus, wenn ein messbarer Liefernutzen mit vertretbarem Review- und Nacharbeitsaufwand einhergeht. Steigt lediglich die Aktivität, während Lieferung unklar bleibt oder die Prüfwarteschlange wächst, verlängern Sie die Beobachtung oder passen Sie den Einsatzbereich an.

Als Entscheidungshilfe können Sie vor dem nächsten Meilenstein die folgenden Punkte abhaken:

• [ ] Die Definition von „abgeschlossener Arbeit“ ist für Ausgangslage und Pilot identisch.
• [ ] Codeaktivität wird getrennt von abgeschlossenen Anforderungen ausgewertet.
• [ ] Review-Zeit und Änderungsanforderungen werden zusammen mit Umfang und Risikoklasse betrachtet.
• [ ] Rückarbeit und geeignete Qualitätssignale sind Teil der Auswertung.
• [ ] Änderungen an Teamumfang, Aufgabenmix oder Review-Regeln sind dokumentiert.
• [ ] Eine Entscheidung zur Ausweitung hängt an Lieferergebnis und Prozesslast, nicht an PR- oder Commit-Wachstum allein.

Wenn Sie daraus einen detaillierteren Abnahmeprozess entwickeln, finden Sie weitere Beiträge im vpstix-Blog. Für Tests mit Agenten, die länger laufen oder auf eine reproduzierbare Entwicklungsumgebung angewiesen sind, sollten Sie außerdem vorab Zugriffsrechte, Datenflüsse und den Umgang mit Protokollen klären. Dokumentieren Sie, welche Daten Ihr Test verarbeitet, wer darauf zugreifen kann und wie lange Protokolle aufbewahrt werden; organisatorische Fragen zum Zugang können Sie anhand der vpstix-Hilfe prüfen. Beachten Sie dabei Ihre Datenschutzvorgaben und internen Richtlinien.

5Für das Management: Befund als Pilotfrage statt als Abbruchsignal

Der belastbare Schluss ist enger als manche Schlagzeile vermuten lässt: Die Arbeit belegt weder, dass alle AI Coding Agents ineffektiv sind, noch dass mehr erzeugter Code automatisch nützlich ist. Sie zeigt eine Diskrepanz, die Sie in Ihrem Team überprüfen können: Mehr Codeaktivität kann auftreten, ohne dass sich die gemessene abgeschlossene Arbeit im selben Maße verändert. Ob dafür Review-Aufwand, Aufgabenmix, Messdefinitionen oder andere Faktoren ausschlaggebend sind, muss Ihr Pilot klären.

Ein praktikabler Meilenstein ist daher nicht „Agent eingeführt“, sondern „Ergebnis und Aufwand gemeinsam ausgewertet“. Wenn Anforderungen schneller abgeschlossen werden und Prüf- sowie Nacharbeitsaufwand nicht unverhältnismäßig steigen, spricht das für eine Fortsetzung im getesteten Einsatzbereich. Wenn nur Aktivitätszahlen steigen, sollten Sie zunächst Aufgabenwahl, Rechte, Review-Kapazität und Messverfahren prüfen. Wenn sich der Nutzen nicht zuverlässig von Schwankungen im Teamalltag trennen lässt, ist eine längere oder enger abgegrenzte Beobachtung aussagekräftiger als eine pauschale Einführung oder ein pauschaler Stopp.

6Häufige Fragen

Warum ist mehr Agent-Code nicht automatisch mehr fertige Software?

Codezeilen und Commits zeigen Aktivität, nicht notwendigerweise erledigte Anforderungen. Zwischen dem Erzeugen einer Änderung und einer nutzbaren Funktion liegen Prüfung, Überarbeitung und Integration. In der untersuchten Stichprobe wurde kein signifikanter Zuwachs abgeschlossener Jira-Arbeit berichtet. Beobachten Sie deshalb auch Durchlaufzeit und Rückarbeit, statt allein auf das Codevolumen zu schauen.

Welche Messgrößen stehen in der Arbeit im Mittelpunkt?

Die Auswertung unterscheidet Werkzeugnutzung, Codeaktivität, Review-Signale und abgeschlossene Jira-Arbeit. Diese Größen beantworten verschiedene Fragen: ob Codeänderungen stattfinden, wie viel Prüf- und Überarbeitungsaufwand sichtbar wird und ob erfasste Aufgaben abgeschlossen werden. Keine dieser Größen allein misst die gesamte Produktivität eines Teams oder beweist eine Ursache-Wirkung-Beziehung.

Verlangsamen Agenten tatsächlich die Codeprüfung?

Die Arbeit behandelt Review-Aufwand als mögliche Engstelle, aber daraus folgt keine allgemeine Aussage über jedes Team. Prüfzeit, Kommentare und Änderungsanforderungen werden auch durch PR-Größe, Risiko und Teamregeln beeinflusst. Vergleichen Sie möglichst ähnliche Änderungen und halten Sie den Ablauf konstant. Erst dann lässt sich beurteilen, ob sich die Warteschlange im Pilot tatsächlich verändert.

Woran erkennt ein Team einen echten Lieferfortschritt?

Legen Sie im Voraus fest, was als abgeschlossene Arbeit gilt, und beobachten Sie neben der Lieferung die Prüfzeit, Rückarbeit und passende Qualitätssignale. Vergleichen Sie dieselben Teams oder klar abgegrenzte Arbeitsbereiche mit identischen Definitionen und Zeitfenstern. Steigen nur Commits oder PRs, ist das kein ausreichender Nachweis für eine verbesserte Lieferung.

7Nächster Schritt: den eigenen Prüfpunkt festlegen

Wenn Ihr aktueller Ablauf vor allem auf Codezeilen, Commits oder PR-Anzahlen schaut, bleiben abgeschlossene Anforderungen, Prüfwarteschlangen und Rückarbeit leicht unsichtbar. Eine vollständige Eigenbeschaffung kann für einen kurzen, abgegrenzten Test unnötige Bindung bedeuten; eine allgemeine Cloud-Umgebung bildet Apple-spezifische Entwicklungsabläufe möglicherweise nicht ab; ein gemeinsam genutzter lokaler Rechner erschwert unter Umständen reproduzierbare Tests und klare Berechtigungen. Für einen zeitlich begrenzten Agent-Test kann das Mieten eines Mac über vpstix eine passendere Umgebung bieten, sofern Ihr Versuch tatsächlich macOS benötigt und Datenschutz- sowie Zugriffsanforderungen geklärt sind. Für dauerhaft hohe Last oder den Bedarf an physischen Schnittstellen bleibt ein eigener Rechner oft sinnvoller.

Der nächste sinnvolle Schritt ist daher nicht, aus der Studie ein pauschales Kauf- oder Stoppurteil abzuleiten, sondern Ihren Pilot so zu definieren, dass Codeaktivität, Lieferung und Review getrennt sichtbar werden. Nutzen Sie den verlinkten Leitfadenbereich, um passende Prüf- und Prozessfragen für Ihren eigenen Einsatz abzuleiten.