Die echten Zahlen zum Einfluss von KI

Was sich in der Entwicklung in den letzten drei Jahren verändert hat

Vor nicht allzu langer Zeit sah die tägliche Arbeit eines Entwicklers über viele Jahre gleich aus. Man schrieb jede Zeile von Hand, suchte auf Stack Overflow nach Antworten und verbrachte Tage damit, sich in eine neue Codebasis einzuarbeiten. Das hat sich schnell geändert.

Hier ist ein kurzer Überblick darüber, was heute wirklich anders ist:

• Code-Generierung. Boilerplate und sich wiederholende Muster gab es schon immer. Entwickler lösten das mit Vorlagen, Snippets und Copy-paste aus alten Projekten. Jetzt übernimmt KI das direkt — sie liest den Kontext und generiert, was gebraucht wird.
• Debugging. Fehler zu finden und zu erklären war immer Handarbeit. Man las den Stacktrace, suchte nach der Meldung, versuchte zu verstehen, was schiefgelaufen war. Jetzt fügt man den Fehler ein und erhält in Sekunden eine Erklärung samt Lösungsvorschlag.
• Neuen Code verstehen. Sich in eine unbekannte Codebasis einzuarbeiten bedeutete früher tagelanges Lesen. Jetzt kann man fragen, und die KI führt einen hindurch.
• Tests schreiben. Tests wurden oft übersprungen oder verschoben, weil sie von Hand so lange dauerten. Jetzt wird die erste Version automatisch generiert, und der Entwickler prüft und passt sie an.
• Dokumentation. Niemand schrieb sie gern. Jetzt erstellt die KI den ersten Entwurf, und der Entwickler überarbeitet, statt bei null anzufangen.

Die Veränderung besteht nicht darin, dass diese Probleme perfekt gelöst werden. Sondern darin, dass der mechanische Teil von jedem davon deutlich schneller wurde.

Die Lücke zwischen KI-Versprechen und realer Entwicklungsarbeit

Beginnen wir mit einem kurzen Überblick darüber, was große Unternehmen und Forscher tatsächlich gemessen haben.

Anthropics eigene Forschung zeigt, dass Entwickler isolierte Aufgaben mit KI-Unterstützung 80 % schneller erledigen. GitHub meldet 55 % schneller bei ähnlichen Benchmarks. Microsoft, Google und Amazon veröffentlichten alle Zahlen in derselben Größenordnung. Die Schlagzeilen schreiben sich von selbst.

Aber das hier schafft es nicht in die Pressemitteilung.

• METR, eine Organisation für KI-Sicherheitsforschung, führte eine echte randomisierte kontrollierte Studie mit erfahrenen Entwicklern an realen Open-Source-Projekten durch. Keine Spielaufgaben. Keine isolierten Übungen. Echte Codebasen, echte Tickets. Ergebnis: Entwickler mit KI-Tools waren 19 % langsamer als die ohne.
• Googles DORA-Report 2025 befragte über 3.000 Entwickler. 90 % nutzen KI-Tools. 80 % sagen, sie fühlen sich produktiver. Aber 30 % sagen, sie vertrauen dem von KI generierten Code nicht — und der Report fand einen negativen Zusammenhang zwischen KI-Einsatz und Softwarestabilität.
• Microsoft führte eine dreiwöchige Studie durch, die echte Telemetrie — Tastenanschläge, Commits, Pull Requests — neben Entwickler-Tagebüchern erfasste. Die Entwickler fühlten sich produktiver. Die Telemetrie zeigte keine statistisch signifikante Veränderung.
• Die Stack-Overflow-Umfrage 2025: nur 16,3 % der Entwickler sagen, dass KI sie deutlich produktiver gemacht hat.

Das ist nicht KI-feindlich. Es ist das übliche Muster bei neuen Werkzeugen: Frühe Benchmarks messen Best-Case-Szenarien bei klar definierten Aufgaben. Echte Arbeit ist unordentlicher. Die Lücke zwischen „erledigt eine in sich geschlossene Funktion 55 % schneller“ und „liefert Produktionsfeatures schneller aus“ ist dort, wo die meisten Feinheiten liegen — und wo so gut wie kein Marketing hingeht.

Das ist nicht KI-feindlich. Es ist das übliche Muster bei neuen Werkzeugen: Frühe Benchmarks messen Best-Case-Szenarien bei klar definierten Aufgaben. Echte Arbeit ist unordentlicher. Die Lücke zwischen „erledigt eine in sich geschlossene Funktion 55 % schneller“ und „liefert Produktionsfeatures schneller aus“ ist dort, wo die meisten Feinheiten liegen — und wo so gut wie kein Marketing hingeht.

Es gibt hier also eine echte Spannung. Unabhängige Forscher messen keine signifikante Veränderung in der Telemetrie oder sogar eine Verlangsamung. Aber echte Kunden mit echten Budgets zahlen weiter. Und manche Anbieter verkünden selbstbewusst 20-fache Produktivitätsgewinne.

Die Frage, die man stellen sollte, lautet: Wie werden diese Zahlen berechnet? Eine 20-fache Verbesserung — wovon genau? Eine for-Schleife schreiben, eine Boilerplate-Datei generieren, einen Unit-Test fertigstellen? Das sind echte Beschleunigungen bei isolierten Aufgaben. Aber ein funktionierendes Feature in einem Produktionssystem ist keine isolierte Aufgabe. Es ist eine for-Schleife plus ein Code-Review plus eine Diskussion über Edge Cases plus ein Deployment plus ein Rollback. Ein Teilstück zu messen und es für das Ganze zu behaupten — so werden Benchmarks zu Marketing.

Unsere Untersuchung mit echten GitHub-Daten über große Frameworks hinweg

Um den echten Einfluss von KI auf die Entwicklerproduktivität zu verstehen, haben wir ein messbares Signal verfolgt: die Zeit zwischen dem Öffnen und dem Schließen eines Issues. Wenn KI-Tooling Entwickler wirklich schneller macht, sollte sich das darin zeigen, wie schnell Teams im Lauf der Zeit neue Probleme lösen. Die folgenden Ergebnisse decken die am weitesten verbreiteten Frameworks und Tools ab:

Volatil, aber erholt — der Einbruch 2023 spiegelt die Entwicklung von React 19 wider, und bis 2025 schließt das Team 72 % der neuen Issues im selben Jahr, mit einer medianen Schließzeit von nur noch 1 Tag.

Stetig und ausgereift — das Volumen halbierte sich über drei Jahre, die Schließquote im selben Jahr hielt sich bei 70–81 %, und die mediane Lösungszeit blieb durchgehend unter 1 Tag.

Der konstanteste Performer — schließt 2025 mehr Issues, als geöffnet werden, Schließquote im selben Jahr bei 85 %, und mediane Lösung unter 1 Tag über alle drei Jahre.

Svelte 5 verdoppelte 2024 das Issue-Volumen, das Team fing es auf — und bis 2025 fiel die durchschnittliche Schließdauer von 33 auf 11 Tage, der Median auf nur 1 Tag.

Jährlich rückläufig, während das Ökosystem reift, Schließquote stabil bei 79–87 %, und die mediane Schließzeit verbesserte sich von 4 Tagen 2024 auf 2 Tage 2025.

Dreifaches Volumenwachstum in zwei Jahren bei gleichbleibender Schließquote — die medianen Schließtage stiegen jedoch von 3 auf 6, was zeigt, dass das Team an der Kapazitätsgrenze ist.

Die mediane Schließzeit fiel dramatisch von 41 Tagen 2024 auf nur 2 Tage 2025 — aber nur 32 % der neuen Issues werden im selben Jahr gelöst, Geschwindigkeit ist also nicht die ganze Geschichte.

Was die Zahlen tatsächlich zeigen und was zu erwarten ist

Der Trend ist klar: Die Zeit zum Lösen von Issues wird auf breiter Front kürzer. Ob das an KI-Tools, an besserem Tooling allgemein oder an erfahreneren Teams liegt, ist schwer zu isolieren — aber die Richtung ist eindeutig.

Was die Repositories zeigen, ist ein geteiltes Muster. Dokumentations-Updates, Komponentenänderungen, kleine Fixes — die werden schneller geschlossen als früher, teils deutlich. Genau bei gut definierter, abgegrenzter und wiederholbarer Arbeit ist die Beschleunigung am sichtbarsten. Dieser Teil des KI-Versprechens ist real.

Architekturänderungen erzählen eine andere Geschichte. Komplexe Entscheidungen, strukturelle Refactorings, übergreifende Belange — deren Zeitachse hat sich nicht nennenswert verkürzt. Das nötige Nachdenken lässt sich nicht auf dieselbe Weise komprimieren.

Was man daraus mitnehmen sollte:

• Einfache, sich wiederholende, klar abgegrenzte Arbeit ist jetzt wirklich schneller. Das ist das klarste Signal in den Daten.
• Der Einstieg in eine neue Aufgabe oder Codebasis ist leichter — Informationen lassen sich schneller sammeln und verstehen.
• Komplexe Architekturarbeit dauert so lange wie eh und je. KI unterstützt, ersetzt aber nicht das erforderliche Urteilsvermögen.
• Je klüger der Einsatz von KI-Tools — zugeschnitten auf die richtigen Aufgaben —, desto realer der Ertrag. Sie breit einzusetzen und einheitliche Gewinne zu erwarten, ist die Ursache der Kluft zwischen Anbieterversprechen und echten Ergebnissen.

Nutze es. Aber nutze es dort, wo es funktioniert.