Direkte Antwort: Die Verbreitung von KI-Coding-Tools ist nahezu flächendeckend, doch die belastbare Evidenz zur Produktivität ist gemischt. Eine randomisierte kontrollierte Studie von METR aus dem Jahr 2025 ergab, dass erfahrene Open-Source-Entwickler mit KI etwa 19 % langsamer waren – während sie glaubten, schneller zu sein. Die Stack-Overflow-Umfrage 2025 zeigt, dass die meisten Entwickler inzwischen KI nutzen, ihrer Genauigkeit aber misstrauen, und Googles DORA-Forschung 2024 verbindet eine höhere KI-Nutzung mit kleinen Rückgängen bei Durchsatz und Stabilität der Auslieferung. Die Lehre lautet nicht, dass KI versagt. Sie lautet: Messen Sie abgenommene Ergebnisse in Ihrer eigenen Umgebung, statt einer Schlagzeile oder Anekdote zu vertrauen.
„KI macht Entwickler schneller“ ist zu einer stillschweigenden Annahme in Tool-Marketing und Vorstandsfolien geworden. Die stärkste aktuelle Evidenz ist deutlich vorsichtiger. Drei unabhängige, glaubwürdige Quellen – eine randomisierte Studie, eine große Entwicklerumfrage und ein mehrjähriges DevOps-Forschungsprogramm – schränken die Behauptung jeweils auf andere Weise ein.
Keine davon sagt, dass KI-Coding-Tools nutzlos sind. Zusammen sagen sie das Ehrliche: Größe und sogar Richtung des Produktivitätseffekts hängen davon ab, wer gemessen wird, was gemessen wird und wie.
Die Verbreitung ist hoch. Das Vertrauen nicht.
Die Stack-Overflow-Entwicklerumfrage 2025 berichtet, dass rund 84 % der Entwickler KI-Tools nutzen oder dies planen – gegenüber 76 % im Vorjahr. Ob sie genutzt werden, ist nicht mehr die interessante Frage.
Vertrauen schon. In derselben Umfrage gaben 46 % der Entwickler an, der Genauigkeit von KI-Tools zu misstrauen, gegenüber 33 %, die ihr vertrauen, und nur rund 3 % vertrauten der Ausgabe „stark“. Breite Verbreitung geht mit breiter Skepsis gegenüber der Korrektheit einher – ein Muster, das jede einzelne Produktivitätszahl verdächtig machen sollte.
Eine randomisierte Studie fand eine überraschende Verlangsamung
Die meisten Produktivitätsbehauptungen stützen sich auf Selbstauskünfte oder Benchmarks. METR, eine gemeinnützige Forschungsorganisation, tat etwas Selteneres: eine randomisierte kontrollierte Studie.
METR rekrutierte 16 erfahrene Open-Source-Entwickler, die an von ihnen gepflegten Repositories arbeiten (im Schnitt über 22.000 Sterne und mehr als eine Million Codezeilen), und ließ sie 246 reale Issues aus ihrer normalen Arbeit einbringen. Jedes Issue wurde zufällig so zugewiesen, dass KI erlaubt oder verboten war. War KI erlaubt, nutzten die Entwickler die damaligen Spitzenwerkzeuge – vor allem Cursor Pro mit Claude 3.5/3.7 Sonnet.
Das Ergebnis lief den Erwartungen zuwider: Die Entwickler brauchten etwa 19 % länger, um Issues zu erledigen, wenn KI erlaubt war. Der auffälligste Teil war die Wahrnehmungslücke. Die Entwickler prognostizierten eine Beschleunigung von 24 %, und selbst nach Abschluss der Aufgaben glaubten sie noch, KI habe sie um rund 20 % beschleunigt.
METR ist ungewöhnlich deutlich darin, was dies nicht beweist, und das ist eine Wiederholung wert:
- Es zeigt nicht, dass KI die meisten Entwickler nicht beschleunigt; die Studie erfasst eine bestimmte Gruppe.
- Sie untersucht nur Softwareentwicklung, in ausgereiften Repositories mit hohen Qualitätsansprüchen.
- Sie kann Lernkurveneffekte jenseits einiger Dutzend Stunden Werkzeugnutzung nicht ausschließen.
- METR veröffentlichte später eine Fortsetzung für 2026 und markierte die Zahlen von Anfang 2025 als überholt.
Behandeln Sie die 19-%-Zahl als einen belastbaren Datenpunkt zu einem anspruchsvollen Umfeld – nicht als universelles Urteil.
Individuelle Geschwindigkeit gegen Systemauslieferung
Selbst wo Einzelne sich schneller fühlen, kann sich das Auslieferungssystem in die andere Richtung bewegen. Googles DORA-Bericht 2024 stellte fest, dass die KI-Nutzung individuelle Produktivität, Flow und Arbeitszufriedenheit steigerte – schätzte aber, dass ein Anstieg der KI-Nutzung um 25 % mit einem Rückgang des Auslieferungsdurchsatzes um rund 1,5 % und der Auslieferungsstabilität um 7,2 % verbunden war.
Diese Kombination – zufriedenere, scheinbar schnellere Einzelne und eine leicht instabilere Auslieferung – ist genau die Art von Effekt, die eine einzelne selbst berichtete Kennzahl übersehen würde.
| Evidenzquelle | Was sie misst | Zentraler Befund | Was sie nicht beweisen kann |
|---|---|---|---|
| METR-RCT (2025) | Aufgabenzeit erfahrener Entwickler bei realen Issues | ~19 % langsamer mit KI, trotz Glaube an Beschleunigung | Dass KI alle Entwickler oder Umfelder verlangsamt |
| Stack Overflow 2025 | Selbst berichtete Nutzung und Vertrauen | ~84 % nutzen KI; 46 % misstrauen der Genauigkeit | Tatsächliche Wirkung auf Qualität oder Tempo der Ergebnisse |
| DORA 2024 | Durchsatz und Stabilität der Teamauslieferung | Kleine Rückgänge, verbunden mit höherer KI-Nutzung | Ein universelles Kausalgesetz für jedes Team |
Warum Wahrnehmung und Realität auseinandergehen
Mehrere Mechanismen erklären, wie sich ein Werkzeug schneller anfühlen kann, während es sich langsamer misst:
- Verzerrung durch Selbstauskunft. Der Aufwand fürs Prüfen und Korrigieren der Ausgabe ist leicht zu vergessen; der Moment der Generierung fühlt sich produktiv an.
- Benchmarks sind nicht Ihr Repository. Hohe Werte bei eng gefassten, automatisch bewerteten Aufgaben übertragen sich nicht auf Code, der Stil-, Test- und Dokumentationsprüfung bestehen muss.
- Verifikationsaufwand. Das Lesen, Testen und Reparieren von generiertem Code kann mehr kosten als die eingesparte Zeit – besonders bei Code, den der Entwickler ohnehin gut kennt.
- Kontextwechsel. Prompten, Warten und das Bewerten von Vorschlägen unterbricht den Flow, auf den sich erfahrene Entwickler verlassen.
Was man stattdessen messen sollte
Die pragmatische Antwort besteht weder darin, KI zu verbieten, noch sie blind einzuführen. Sie besteht darin, das Ergebnis zu messen, auf das es wirklich ankommt: abgenommene, geprüfte Änderungen in Ihrer eigenen Umgebung samt ihrer wahren Kosten.
Halten Sie für eine faire Bewertung Repository-Baseline und Abnahmekriterien konstant und erfassen Sie:
- abgenommene Ergebnisse im Verhältnis zu Versuchen sowie Nacharbeit oder Churn danach;
- aktive Reviewer-Minuten je abgenommener Änderung;
- Durchsatz und Stabilität der Auslieferung über die Zeit, nicht nur das Tempo auf Aufgabenebene;
- Gesamtkosten je abgenommener Änderung, einschließlich Modell, Compute und Review.
Das ist die Disziplin hinter der Pilot-Forschungsmethodik dieser Website und den harten Zuverlässigkeits- und Sicherheits-Gates in der Scorecard für KI-Coding-Piloten. Es ist auch der Grund, warum eine verwaltete Plattform, die Aufgaben, Umgebungen und Review-Belege erfasst – das Modell, das MonkeyCode beschreibt –, die Messung leichter macht als der Ad-hoc-Einsatz auf dem Laptop.
Fazit
KI-Coding-Tools sind weit verbreitet und in vielen Situationen eindeutig nützlich. Doch die beste aktuelle Evidenz – eine RCT, eine große Umfrage und eine mehrjährige DevOps-Studie – warnt davor, „KI macht uns schneller“ als ausgemachte Sache zu behandeln. Die Verbreitung ist hoch, das Vertrauen gering, die individuelle Wahrnehmung unzuverlässig, und die Teamauslieferung kann zurückgehen, selbst wenn sich Einzelne schneller fühlen.
Führen Sie die Messung in Ihren eigenen Repositories mit Ihren eigenen Reviewern durch, bevor Sie eine Behauptung zu einem Budget hochskalieren.
Quellengrenze: Die Zahlen zur Verlangsamung um 19 %, zur Prognose und zur Einschätzung nach der Aufgabe sind METRs berichtete Befunde für Werkzeuge von Anfang 2025 unter erfahrenen Open-Source-Entwicklern; METR markiert diese als historisch und hat eine Aktualisierung für 2026 veröffentlicht. Die Prozentwerte zu Verbreitung und Vertrauen stammen aus der Stack-Overflow-Entwicklerumfrage 2025. Die Schätzungen zu Durchsatz und Stabilität stammen aus Googles DORA-Bericht 2024. Alle Quellen wurden am 20. Juli 2026 geprüft und beschreiben bestimmte Gruppen und Methoden, keine universellen Gesetze.