KI-gestützte Entwicklung: Das Produktivitätsparadox, vor dem niemand warnt

Die Zahlen passen nicht zusammen

Jeder Vendor-Pitch sagt dasselbe: KI macht eure Entwickler 50 % schneller. GitHub behauptet, Copilot-Nutzer erledigen Aufgaben 55 % schneller. Klingt super auf einer Folie.

Hier ist der Reality-Check.

METRs randomisierte kontrollierte Studie — echte erfahrene Open-Source-Entwickler, auf ihren eigenen Repos, bei realer Arbeit — ergab, dass KI-Tools Entwickler 19 % langsamer machten. Nicht schneller. Langsamer. Und der Clou: Die Entwickler glaubten, sie seien 24 % schneller, während sie messbar langsamer waren.

Faros AIs Studie über 10.000+ Entwickler und 1.255 Teams erzählt eine ähnliche Geschichte. Individueller Throughput steigt. Entwickler mergen 98 % mehr Pull Requests. Aber die PR-Review-Zeit steigt um 91 %. Bug-Raten steigen um 9 % pro Entwickler. PR-Größen wachsen um 154 %.

Auf Unternehmensebene? Keine messbare Produktivitätsverbesserung.

Das ist kein Tooling-Problem. Das ist ein Systemproblem.

Wo KI wirklich hilft (und wo nicht)

KI-Coding-Assistenten sind wirklich gut bei:

Boilerplate und Wiederholungen. Config-Dateien, Test-Scaffolding, CRUD-Endpoints. Das Zeug, das niemand schreiben will.
Exploration und Prototyping. Drei Ansätze ausprobieren in der Zeit, die einer gekostet hätte.
Übersetzung zwischen Sprachen und Frameworks. Patterns von Go nach TypeScript portieren oder umgekehrt.
Dokumentation als Erstentwurf. Von der leeren Seite zu einem brauchbaren Startpunkt.

KI-Coding-Assistenten sind schlecht bei:

Architekturentscheidungen. LLMs verstehen nicht die Constraints, Trade-offs oder Historie eures Systems.
Production-Debugging. Ihnen fehlt der Kontext über eure Infrastruktur, Traffic-Patterns und Fehlermodi.
Code-Review. Automatisiertes Review fängt Style-Issues. Es übersieht die „das verursacht eine Race Condition unter Last”-Probleme.
Wissen, wann man keinen Code schreiben sollte. Die besten Engineering-Entscheidungen drehen sich oft darum, was man nicht baut.

Das Muster ist klar: KI beschleunigt den billigsten Teil der Softwareentwicklung (Code schreiben) und tut nichts für die teuren Teile (Design, Review, Debugging, Deployment, Wartung).

Die Engpass-Verschiebung, über die niemand spricht

Wenn Entwickler schneller mehr Code produzieren, wandert der Engpass downstream. Jedes Team, mit dem wir gearbeitet haben und das aggressiv KI-Coding-Tools eingeführt hat, sah dieselbe Abfolge:

Woche 1-4: Entwickler fühlen sich schneller. PR-Volumen steigt sprunghaft.
Monat 2: Review-Queues stauen sich. Senior Engineers verbringen den ganzen Tag mit Review von KI-generierten PRs.
Monat 3: Bug-Reports steigen. KI-generierter Code besteht CI, scheitert aber an Edge Cases, die niemand getestet hat.
Monat 4: Lead-Times sind länger als vorher, weil alles im Review feststeckt.

Faros AIs Daten bestätigen das: Entwickler in Teams mit hoher KI-Adoption bearbeiten 47 % mehr PRs pro Tag, aber der Review-Engpass absorbiert alle Gewinne. Amdahls Gesetz in Aktion — das System bewegt sich so schnell wie sein langsamster Teil.

Was Engineering-Leader wirklich tun sollten

1. Die Pipeline fixen, nicht die Tippgeschwindigkeit

Wenn eure Deployment-Pipeline 45 Minuten braucht und eure Code-Review-Queue 3 Tage tief ist, ändert schnelleres Tippen nichts. Investiert in:

Automatisierte Review-Gates, die das Offensichtliche abfangen, bevor ein Mensch draufschaut
Kleinere-PR-Kultur — KI macht es einfach, massive Changesets zu erzeugen, aber massive PRs sind Review-Killer
Deployment-Confidence — Feature Flags, Canary Releases, automatisierte Rollbacks

2. Messt, was zählt

Hört auf, Lines of Code oder gemergte PRs zu messen. Messt stattdessen:

Lead Time vom Commit bis Production
Change Failure Rate — schippt ihr mehr Bugs?
Review-Turnaround — wächst eure Review-Queue?
Time to Recovery, wenn etwas kaputtgeht

Wenn KI-Adoption die gemergten PRs erhöht, aber auch eure Change Failure Rate steigt, gewinnt ihr nicht. Ihr scheitert nur schneller.

3. KI für den langweiligen Kram, Menschen für den harten Kram

Die besten Teams, die wir sehen, behandeln KI als Multiplikator für die lästige Arbeit:

Test Cases aus Spezifikationen generieren
Migrations-Skripte schreiben
Erstentwurf-Dokumentation erstellen
Neue Services aus Templates scaffolden

Und sie behalten Menschen fest in der Kontrolle über:

Systemdesign und Architektur
Sicherheitskritische Code-Pfade
Performance-sensitive Implementierungen
Team-übergreifende Integrationspunkte

4. Die Lernphase nicht überspringen

Die METR-Studie fand einen Grund, warum KI Entwickler verlangsamte: Context-Switching zwischen eigenem Denken und dem Output der KI. Erfahrene Entwickler hatten tiefe mentale Modelle ihrer Codebasen. KI-Vorschläge passten oft nicht zu diesen Modellen und erforderten extra Zeit zum Bewerten und Anpassen.

Das bedeutet: Junior-Entwickler könnten größere Speed-Gewinne erzielen (sie haben weniger etablierte mentale Modelle, die kollidieren), aber sie brauchen auch mehr Supervision, nicht weniger. KI ersetzt kein Mentoring. Wenn überhaupt, macht sie Mentoring wichtiger — jemand muss den plausibel-aussehenden-aber-falschen Code abfangen, den Juniors unkritisch akzeptieren.

Die ehrliche Einschätzung

KI-gestützte Entwicklung ist gekommen, um zu bleiben. 82 % der Entwickler nutzen wöchentlich KI-Tools. Etwa 27 % des Production-Codes ist inzwischen KI-generiert. Das geht nicht zurück.

Aber die Produktivitätsgewinne sind nur real, wenn ihr eure gesamte Delivery-Pipeline um höheres Code-Volumen herum neu designt — nicht wenn ihr KI auf einen unveränderten Prozess draufschraubt und auf das Beste hofft.

Die Teams, die echten Mehrwert aus KI ziehen, sind die, die:

In Review-Automatisierung investiert haben, bevor sie den Code-Output erhöht haben
Quality-Gates eingerichtet haben, die KI-spezifische Fehlermodi abfangen
Ihre Entwickler trainiert haben, wann sie KI nutzen und wann sie selbst denken sollten
End-to-End-Delivery-Metriken messen, nicht nur Coding-Speed

Der Rest erzeugt nur mehr Code zum Reviewen, mehr Bugs zum Fixen und mehr PRs zum Mergen — und wundert sich, warum die Roadmap trotzdem rutscht.

Braucht ihr Hilfe, KI-Tools in euren Engineering-Workflow zu integrieren, ohne neue Engpässe zu schaffen? Lasst uns reden.