TL;DR:
- KI-Programmierassistenten sind weder durchweg gut noch durchweg schlecht. Entscheidend ist die Komplexität der Aufgabe. Bei begrenzten Aufgaben (Tests, Prototypen, Dokumentation, Skripterstellung) lassen sich zuverlässige Gewinne erzielen. Bei komplexen Aufgaben (architektonische Entscheidungen, Änderungen an mehreren Dateien, implizites Fachwissen) wird die eingesparte Zeit durch den Aufwand für die Verifizierung und durch Nacharbeiten wieder aufgezehrt.
- Deshalb zeigen aggregierte Produktivitätsmessungen oft „keinen Effekt“: Gewinne und Reibungsverluste sind von ähnlicher Größenordnung und heben sich im Durchschnitt gegenseitig auf. Nicht, weil nichts passiert, sondern weil beides gleichzeitig geschieht.
- Die Grenze der Aufgabenkomplexität ist verschiebbar: Erfahrene Entwickler investieren mehr Zeit im Vorfeld in die Spezifikation und Anforderungsformulierung und wandeln so komplexe Aufgaben in begrenzte um.
Dieser Artikel wurde automatisch übersetzt. Original Artikel.
Vor einiger Zeit habe ich einen ganzen Nachmittag zusammen mit einem KI-Assistenten verbracht. In unserer Microservice-Umgebung mit Micro-Frontends funktionierten Tailwind-Stile, die in den einzelnen Frontends einwandfrei liefen, nicht mehr, sobald sie in die Host-Anwendung geladen wurden. Der Assistent und ich drehten uns im Kreis: Vorschlag, Test, Fehlschlag, neuer Vorschlag. Am nächsten Tag warf ein Kollege einen Blick darauf und behob das Problem mit einem einzigen Befehl. Er kannte die Umgebung und hatte das mentale Modell im Kopf. Die KI und ich hatten beides nicht.
Die gleiche Lücke zeigt sich auch im großen Maßstab. Anbieter versprechen auf der Grundlage kontrollierter Experimente Zeitersparnisse von 26–56 %, doch Produktionsdaten erzählen eine andere Geschichte: Eine Studie unter 400 Unternehmen ergab, dass ein Anstieg der KI-Nutzung um 65 % nur zu einer Steigerung des Pull-Request-Durchsatzes um 7,76 % führte. Eine METR-Studie zeigte, dass erfahrene Open-Source-Entwickler mit KI 19 % langsamer waren, sich dabei aber um 20 % schneller fühlten. Ich wollte diese Kluft zwischen Versprechen, Wahrnehmung und Messung verstehen. Nicht im Labor, sondern hier bei inovex.
Was ich untersucht habe
Meine Masterarbeit (Hochschule der Medien in Stuttgart) ist eine Fallstudie mit gemischter Methodik bei inovex, die drei unabhängige Datenstränge umfasst:
- Telemetrie: 177 Tage Nutzungsdaten zu GitHub Copilot auf Organisationsebene (~138.000 Code-Vorschläge in 72 Sprachen)
- Umfrage: ein auf dem SPACE-Framework basierender Fragebogen, 36 Antworten (28 KI-Nutzer, 8 Nicht-Nutzer)
- Thematische Analyse der Freitextantworten (61 Aussagen, 8 Themen)
Ich habe bewusst darauf verzichtet, „Produktivität“ als einzelne Zahl zu messen, da Forschungsergebnisse zeigen, dass dies sowohl bei KI-gestützter Programmierung als auch generell unzuverlässig ist. Stattdessen habe ich untersucht, wo drei unabhängige Datenstränge zu derselben Schlussfolgerung konvergieren; dort steigt das Vertrauen. Wo sie sich widersprechen, ist der Widerspruch selbst ein Befund.
Wo KI-Programmierassistenten helfen – und wo nicht
Alle drei Datenstränge zeigen dasselbe Muster. In der Telemetrie weist Python (strukturierte, in sich geschlossene Aufgaben) eine Akzeptanzrate von 36 % auf, während TypeScript React (Logik, Markup und Status in derselben Datei) bei nur 19 % liegt. In der Umfrage und den Freitextantworten liegt der vorherrschende Vorteil bei abgegrenzten Aufgaben: Tests, Prototypen, Dokumentation und Skripte. Die Frustration entsteht auf der komplexen Seite, wo immer architektonisches Urteilsvermögen, die Koordination mehrerer Dateien oder implizites Wissen erforderlich sind.
Der DORA-Bericht bezeichnet KI als „Verstärker“: Sie stärkt sowohl vorhandene Kompetenzen als auch bestehende Unsicherheiten. Die Komplexität der Aufgaben ist der zugrunde liegende Mechanismus. Mein Tailwind-Mikro-Frontend-Nachmittag lag genau auf der komplexen Seite dieser Grenze der Aufgabekomplexität. Das Problem lag in der Integration zwischen den Systemen, nicht in einer einzelnen Datei, die die KI erkennen konnte.
Ein Nullergebnis, das keines ist
Der Effizienzvergleich zwischen KI-Nutzern und Nicht-Nutzern ist statistisch nicht signifikant. Das klingt nach einem fehlenden Effekt, doch das Gegenteil ist der Fall. Auf der Ebene der einzelnen Aufgaben stehen sich starke Kräfte gegenüber: 96 % stimmen beim Prototyping zu, 86 % bei der Dokumentensuche und 79 % bei der Aufgabengeschwindigkeit – gegenüber den 61 %, die angeben, dass die Nachbearbeitung länger dauert als erwartet. Der Durchschnitt über alle Aufgaben hinweg ist das Zeichen zweier gegensätzlicher Kräfte, nicht das Fehlen eines Effekts.
Was das in der Praxis bedeutet
Setzen Sie KI dort ein, wo sie zuverlässig Ergebnisse liefert. Gehen Sie begrenzte Aufgaben aktiv mit KI an: Tests, Scaffolding, Prototypen, Konvertierungen und Dokumentation. Der Nutzen ist hier real und reproduzierbar.
Sichern Sie sich den komplexen Bereich, anstatt ihn überzubewerben. Vielversprechende KI-Gewinne für komplexe architektonische Arbeiten untergraben die Glaubwürdigkeit der tatsächlichen Gewinne. Dieser Bereich erfordert konsequente Überprüfungen und Unterstützung, was bedeutet, dass Zeit in den Aufbau von Anwendungskompetenz investiert werden muss, anstatt sofortige Erfolge zu erwarten.
Wechseln Sie vom Schreiben zum Spezifizieren. Die interessanteste Erkenntnis aus den Daten ist, dass erfahrene Entwickler deutlich mehr Zeit in die Beschreibung von Anwendungsfällen und das Anforderungs-Engineering investieren, bevor sie die KI zum Einsatz bringen. Man nennt dies „spezifikationsgesteuerte Entwicklung“. Sie verschieben die Grenze selbst und verwandeln komplexe Aufgaben in abgegrenzte. Mit der Verlagerung hin zu agentenbasierten Arbeitsabläufen wird dies von einem Trick zu einer Voraussetzung. Die Reibungsverluste verschwinden nicht; sie verlagern sich vorgelagert in den Aufwand für Spezifikation und Verifizierung.
Daher wird das Handwerk der Softwareentwicklung nicht ersetzt. Es verlagert sich: weniger auf die Tastenanschläge, die Code erzeugen, und mehr auf die vorgelagerte Absicht, die ihn lenkt, sowie auf die nachgelagerte Beurteilung, die entscheidet, was bestehen bleibt.
