Die schnelle Ausgabe ist erst der Anfang
Eine Funktion, für die vorher eine Stunde eingeplant war, erscheint nach wenigen Minuten auf dem Bildschirm. Die KI hat die Dateien angelegt, Tests ergänzt und eine Zusammenfassung geschrieben.
Dann beginnt die Prüfung. Eine vorhandene Hilfsfunktion wurde übersehen. Eine neue Abhängigkeit ist unnötig. Der Test bestätigt zwar das Standardverhalten, berücksichtigt aber nicht die Berechtigungsregel, um die es eigentlich ging.
Das Beispiel ist fiktiv. Die Rechnung dahinter ist einfach: Zeit, die beim Schreiben gespart wurde, kann bei Prüfung und Nacharbeit wieder verloren gehen.
Mehr erzeugter Code ist deshalb noch kein Nachweis höherer Produktivität. Entscheidend ist, wie viel Aufwand bis zu einem brauchbaren, geprüften Ergebnis entsteht.
Die „Review-Steuer“ ist mehr als ein Schlagwort
Der am 10. März 2026 zuletzt aktualisierte DORA-Beitrag enthält eine qualitative Auswertung von 1.110 offenen Antworten von Google-Softwareentwicklern, erhoben im dritten Quartal 2025.
Die Rückmeldungen beschreiben sowohl Vorteile bei der Codeerstellung als auch zusätzlichen Aufwand für Kontrolle und Korrektur. DORA bezeichnet diesen Aufwand als Verification Tax: Ein Teil der beim Erstellen gewonnenen Zeit wird anschließend für die Überprüfung benötigt. Die Auswertung ist keine repräsentative Zeitmessung aller Entwicklungsteams. [1]
Für mich ist die Unterscheidung zwischen individueller Geschwindigkeit und Teamleistung besonders wichtig. Wer einen großen Änderungsvorschlag schnell erzeugt, kann Arbeit an andere weiterreichen. Der Entwurf ist fertig, die Verantwortung für seine Bewertung aber nicht verschwunden.
Das macht Codeprüfung nicht überflüssig. Es bedeutet, dass sie von Anfang an zur Kalkulation gehören muss – bei selbst geschriebenem genauso wie bei KI-generiertem Code.
Was die Studie mit den 19 Prozent Verlangsamung zeigt
METR veröffentlichte am 10. Juli 2025 einen kontrollierten Versuch mit 16 erfahrenen Open-Source-Entwicklern und 246 realen Aufgaben. Die Teilnehmer arbeiteten an Projekten, mit denen sie bereits vertraut waren. Für die Aufgaben wurde zufällig festgelegt, ob KI-Unterstützung erlaubt war.
Mit den damals eingesetzten Werkzeugen benötigten die Entwickler im Durchschnitt 19 Prozent mehr Zeit. Gleichzeitig glaubten sie auch nach dem Versuch, durch KI schneller gearbeitet zu haben. [2]
Der Befund ist bemerkenswert, aber begrenzt. Er belegt nicht, dass KI jeden Entwickler verlangsamt. Er ist auch kein aktueller Leistungstest sämtlicher Agenten im Herbst 2026.
Vor allem darf eine wichtige Fortsetzung nicht fehlen: Am 24. Februar 2026 erklärte METR, dass neuere Daten auf stärkere Beschleunigung hindeuteten, die genaue Größenordnung wegen erheblicher Auswahl- und Messprobleme aber nicht verlässlich bestimmt werden könne. Unter anderem wollten manche Entwickler bestimmte Aufgaben nicht mehr ohne KI bearbeiten und brachten sie deshalb nicht in den Versuch ein. [3]
Die ältere Zahl als allgemeingültiges Urteil über heutige Werkzeuge zu verwenden, wäre genauso ungenau wie sie vollständig zu ignorieren.
Es gibt auch kontrollierte Untersuchungen mit positiven Ergebnissen
Eine am 27. Februar 2026 online in Management Science veröffentlichte Untersuchung wertete drei Feldexperimente bei Microsoft, Accenture und einem weiteren Großunternehmen aus. Insgesamt wurden 4.867 Entwickler betrachtet.
Über die Versuche hinweg ermittelten die Forscher einen Anstieg erledigter Aufgaben um 26,08 Prozent bei Nutzung des untersuchten Programmierassistenten. Die Ergebnisse unterschieden sich zwischen den Unternehmen; weniger erfahrene Entwickler profitierten stärker. Untersucht wurde eine Unterstützung durch Codevervollständigung, nicht pauschal jeder heutige autonome Agent. [4]
Die Ergebnisse widersprechen der METR-Untersuchung nicht automatisch. Andere Aufgaben, andere Werkzeuge, andere Teams und andere Messgrößen können zu anderen Resultaten führen.
Auch „26 Prozent mehr erledigte Aufgaben“ bedeutet nicht schlicht „jede Aufgabe braucht 26 Prozent weniger Zeit“. Wer solche Zahlen vergleicht, muss zunächst prüfen, was überhaupt gemessen wurde.
Was hinter „Acceleration Whiplash“ steckt
Der Analyseanbieter Faros verwendet in seinem AI Engineering Report 2026, geprüft am 11. Oktober 2026, den Ausdruck Acceleration Whiplash. Gemeint ist ein Spannungsfeld zwischen höherem Durchsatz und wachsenden Belastungen in späteren Entwicklungsschritten.
Nach eigenen Angaben untersuchte Faros Telemetriedaten von rund 22.000 Entwicklern aus mehr als 4.000 Teams. Beim Vergleich von Phasen geringerer und höherer KI-Nutzung berichtet das Unternehmen unter anderem von rund 33,7 Prozent mehr erledigten Aufgaben und zugleich 54 Prozent mehr erfassten Fehlern je Entwickler. [5]
Das ist eine beobachtende Auswertung eines kommerziellen Anbieters, kein randomisierter Nachweis, dass KI allein die Veränderungen verursacht hat. Die Ergebnisse betreffen die ausgewerteten Organisationen, nicht die gesamte Softwarebranche.
Ich würde den Begriff daher nicht als Naturgesetz behandeln. Er beschreibt eine Frage, die sich im eigenen Team prüfen lässt: Steigt nur die Menge der Änderungen – oder verbessert sich auch das, was zuverlässig bei den Nutzern ankommt?
Warum ein guter Benchmarkwert nicht jede Codebasis abdeckt
Ein Test muss festlegen, was als Erfolg zählt. Genau darin liegt eine Grenze.
METR berichtete am 13. August 2025 über eine ergänzende Untersuchung mit 18 realen Aufgaben aus zwei größeren Open-Source-Projekten. Agenten konnten dabei teilweise funktional korrekten Code liefern, der wegen Problemen mit Testabdeckung, Formatierung oder allgemeiner Qualität trotzdem nicht ohne Weiteres übernommen werden konnte. [6]
Daraus folgt nicht, dass Benchmarks wertlos oder grundsätzlich realitätsfern sind. Manche verwenden bereits echte Aufgaben aus vorhandenen Repositories. Ihre automatische Bewertung erfasst jedoch nicht zwangsläufig sämtliche Anforderungen einer produktiven Anwendung. [6]
Bei einer gewachsenen Codebasis gehören beispielsweise bestehende Schnittstellen, Konventionen und Betriebsbedingungen zum Auftrag. Eine neue Funktion muss nicht nur für sich funktionieren, sondern sich in diese Umgebung einfügen.
Die Behauptung, Modelle würden ausschließlich für künstliche Tests entwickelt und scheiterten generell an großen Projekten, wäre deshalb zu pauschal. Die berechtigte Frage lautet, welche Fähigkeiten ein bestimmter Test tatsächlich abbildet und welche nicht.
Die Gesamtrechnung sichtbar machen
Ein vereinfachtes Rechenbeispiel zeigt, weshalb die reine Erstellungszeit täuschen kann:
Rechenbeispiel – Reihenfolge der Werte: ohne KI / mit KI
Auftrag klären und erste Umsetzung erstellen: 60 Minuten: 25 Minuten
Ergebnis prüfen und testen: 30 Minuten: 45 Minuten
Erforderliche Nacharbeit: 10 Minuten: 45 Minuten
Gesamter aktiver Aufwand: 100 Minuten: 115 Minuten
Die Zahlen sind frei gewählte Beispielwerte, keine Untersuchungsergebnisse. Beide Varianten enthalten Prüfzeit. Das Beispiel zeigt lediglich, wie ein deutlicher Vorteil beim ersten Entwurf durch spätere Arbeit aufgebraucht werden kann.
Genauso wäre der umgekehrte Fall möglich: Der erzeugte Code passt gut, vorhandene Tests sind aussagekräftig und es entsteht wenig Nacharbeit. Dann bleibt ein Zeitgewinn übrig.
Bei Agenten würde ich außerdem zwischen menschlicher Arbeitszeit und verstrichener Zeit unterscheiden. Zehn Minuten, in denen ein Agent arbeitet und der Entwickler etwas anderes erledigt, sind anders zu bewerten als zehn Minuten ständige Korrekturanweisungen.
Diese Größen sollten nicht vermischt werden.
Kleine, überprüfbare Aufträge statt großer Überraschungen
Für einen sinnvollen Einsatz würde ich zunächst Aufgaben auswählen, deren Ergebnis klar beurteilt werden kann.
Eine begrenzte Änderung an einer vorhandenen Funktion ist dafür oft der übersichtlichere Ausgangspunkt als „Modernisiere die gesamte Anwendung“. Entscheidend ist nicht eine starre Höchstzahl von Codezeilen, sondern ein nachvollziehbarer Änderungsumfang.
Ein Arbeitsauftrag könnte beispielsweise lauten:
Ergänze einen Filter in der vorhandenen Auftragssuche. Verwende die bestehende Datenzugriffsschicht. Ändere keine Berechtigungen und füge keine Bibliotheken hinzu. Zeige vor der Umsetzung, welche Dateien betroffen sind. Weise anschließend die ausgeführten Tests und offene Punkte aus.
Diese Formulierung ist kein universeller Erfolgs-Prompt. Sie legt aber Grenzen fest, anhand derer sich die Abgabe prüfen lässt.
Wenn der Agent für den Auftrag zusätzliche Änderungen für notwendig hält, möchte ich diese Entscheidung vorher sehen. Eine umfangreiche Umstrukturierung sollte nicht beiläufig als Nebenwirkung einer kleinen Funktion entstehen.
Die Tests dürfen nicht dieselbe falsche Annahme wiederholen
Wenn KI Implementierung und Tests gemeinsam erzeugt, würde ich besonders darauf achten, woher die erwarteten Ergebnisse stammen.
Ein Beispiel: Die Anwendung darf nur Aufträge des angemeldeten Unternehmens anzeigen. Der erzeugte Code ignoriert diese Trennung. Ein gleichzeitig erzeugter Test könnte denselben Fehler übernehmen und lediglich prüfen, ob überhaupt Suchergebnisse erscheinen.
Dann bestätigt der Test die Umsetzung, aber nicht die eigentliche Anforderung.
Deshalb würde ich wichtige Prüfkriterien vor dem Programmieren festhalten. Dazu gehören nicht nur erfolgreiche Standardfälle, sondern auch verweigerte Zugriffe, fehlende Angaben und das Verhalten bei Fehlern.
Ein grüner Testlauf ist wertvoll. Er muss jedoch zum Auftrag passen.
Dasselbe gilt für die Abschlussmeldung des Agenten: „Alles getestet“ genügt nicht. Ich möchte die ausgeführten Prüfungen und ihre Ergebnisse nachvollziehen können.
MCP und Agenten-Frameworks sind Werkzeuge, keine Heilmittel
Das Model Context Protocol, MCP, standardisiert die Verbindung zwischen KI-Anwendungen und externen Datenquellen beziehungsweise Werkzeugen. Die hier herangezogene Spezifikation trägt den Stand 28. Juli 2026. [7]
Ein passender Zugriff auf Projektdateien oder Dokumentation kann hilfreicher sein, als immer größere Quelltextmengen in ein Chatfenster zu kopieren. Daraus folgt aber keine Garantie, dass die KI die richtigen Dateien auswählt, alle Zusammenhänge versteht oder fehlerfreien Code erzeugt.
MCP macht weder das Kontextfenster unbegrenzt noch ersetzt es Tests und Berechtigungsregeln.
Für ein kleines Projekt würde ich daher keine zusätzliche Agentenlandschaft einführen, solange kein konkretes Problem damit gelöst wird. Bei einer größeren Umgebung müssten Zugriffe und Verantwortlichkeiten klar begrenzt bleiben.
Mehr Werkzeuge können Möglichkeiten eröffnen. Sie können aber auch zusätzlichen Einrichtungs- und Prüfaufwand bedeuten.
So würde ich den Nutzen im eigenen Team prüfen
Ich würde mit einer überschaubaren Gruppe vergleichbarer Aufgaben beginnen und vorher festlegen, was als fertig gilt. Dazu gehören Funktionsumfang, Qualität und erforderliche Dokumentation.
Erfasst werden anschließend nicht nur die erzeugten Änderungen, sondern auch aktive Bearbeitungszeit, Prüfung, Nacharbeit und später entdeckte Fehler.
Dabei sollte vermieden werden, ausschließlich besonders leichte Aufgaben mit KI und besonders schwierige ohne KI zu vergleichen. Auch die Reihenfolge spielt eine Rolle: Wer eine Aufgabe bereits einmal gelöst hat, kennt beim zweiten Versuch einen Teil der Antwort.
Für die betriebliche Entscheidung braucht es nicht immer eine wissenschaftliche Studie. Die eigenen Messungen sollten aber ehrlich genug sein, um einen vermeintlichen Vorteil auch widerlegen zu können.
Ich würde außerdem eine Abbruchregel vereinbaren. Wenn ein Agent nach mehreren klaren Korrekturen wieder denselben falschen Ansatz verfolgt, ist eine manuelle Bearbeitung keine Niederlage. Sie kann die wirtschaftlichere Entscheidung sein.
Mein Fazit: Gute KI-Unterstützung spart Nacharbeit, nicht nur Tippzeit
Die Forschung ergibt kein einfaches „KI macht schneller“ oder „KI macht langsamer“. Sie zeigt, dass Aufgabe, Erfahrung, Werkzeug und Arbeitsumgebung einen erheblichen Unterschied machen können.
Für mich liegt die Konsequenz nicht darin, KI grundsätzlich zu vermeiden. Ich würde sie dort einsetzen, wo der Auftrag begrenzt ist und sich das Ergebnis zuverlässig prüfen lässt.
Ein System, das schnell viel Code erzeugt, verdient noch kein Produktivitätslob. Interessant wird es, wenn die Änderung verstanden, getestet und mit vertretbarem Aufwand übernommen werden kann.
Der beste KI-Assistent ist nicht derjenige, der am meisten schreibt. Sondern derjenige, der bis zum brauchbaren Ergebnis am wenigsten unnötige Arbeit hinterlässt.
Einordnung und Recherche
Recherchestand: 11. Oktober 2026. Studien, Befragungen und kommerzielle Anbieteranalysen haben unterschiedliche Aufgaben und Messverfahren. Keine allgemeine Zusage von Zeitgewinn oder Qualitätsverlust. Das Rechenbeispiel ist fiktiv und enthält keine gemessenen Betriebsdaten. Allgemeine technische Orientierung, keine individuelle Rechtsberatung.
Quellen und weiterführende Informationen
[1] DORA: „Balancing AI tensions: Moving from AI adoption to effective SDLC use“
Quelle lesen ↗
[2] METR: „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity“
Quelle lesen ↗
[3] METR: „We are Changing our Developer Productivity Experiment Design“
Quelle lesen ↗
[4] Kevin Zheyuan Cui und weitere Autoren: „The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers“
Quelle lesen ↗
[5] Faros Research: „Ten takeaways from the AI Engineering Report 2026: The Acceleration Whiplash“
Quelle lesen ↗
[6] METR: „Research Update: Algorithmic vs. Holistic Evaluation“
Quelle lesen ↗
[7] Model Context Protocol: Einführung und Spezifikation
Quelle lesen ↗
[7] Model Context Protocol: Einführung und Spezifikation
Quelle lesen ↗