Tobias Reithmeier

Blog

KI-gestützte Programmierung ein Jahr später: Was von den Versprechen übrig blieb

Schematische Gegenüberstellung: Gefühlte Beschleunigung von 20 Prozent gegenüber gemessener Verlangsamung von 19 Prozent aus der METR-Studie
Eigene schematische Darstellung der Wahrnehmungslücke aus der METR-Studie 2025

Vor gut einem Jahr habe ich im Beitrag über Vibe Coding These, Antithese und Synthese durchgespielt: Demokratisierung der Software auf der einen Seite, technische Zeitbombe auf der anderen, dazwischen die These, dass Entwickeln zu Architektur und Audit wird. Inzwischen gibt es etwas, das damals fehlte: belastbare Daten. Zeit für eine Bilanz der drei großen Versprechen.

Versprechen 1: „Mit KI sind alle schneller“

Das prominenteste Gegenbeispiel lieferte die Non-Profit-Organisation METR mit einer randomisierten kontrollierten Studie (Juli 2025): 16 erfahrene Open-Source-Entwicklerinnen und -Entwickler bearbeiteten 246 echte Aufgaben in ihren eigenen, reifen Projekten, mal mit KI-Tools (vor allem Cursor mit Claude-Modellen), mal ohne. Das Ergebnis war eine kleine Sensation: Mit KI brauchten sie 19 Prozent länger. Noch bemerkenswerter war die Wahrnehmungslücke: Dieselben Personen schätzten hinterher, KI habe sie um 20 Prozent beschleunigt. Auch Fachleute aus Ökonomie und Machine Learning hatten vorab kräftige Beschleunigungen prognostiziert.

Fairerweise gehört die Einordnung dazu: Untersucht wurden erfahrene Profis in Codebasen, die sie in- und auswendig kannten. In genau diesem Szenario kann KI am wenigsten beitragen, und der Review-Aufwand schlägt am stärksten durch. Die Tools stammten vom Stand Anfang 2025, und METR selbst entwickelt das Studiendesign inzwischen weiter. Aber als Stachel bleibt der Befund wertvoll: Das Gefühl von Produktivität ist kein Beleg für Produktivität.

Versprechen 2: „Alle, die entwickeln, lieben die Tools“

Die halbe Wahrheit. Der Stack Overflow Developer Survey 2025 zeigt ein gespaltenes Bild: 84 Prozent der Befragten nutzen KI-Tools oder planen es, ein Rekord. Gleichzeitig misstrauen 46 Prozent der Genauigkeit der Ergebnisse, nur 33 Prozent vertrauen ihr; die positive Grundstimmung gegenüber KI-Tools fiel von über 70 auf 60 Prozent. Die meistgenannte Frustration (45 Prozent) bringt das Kernproblem auf den Punkt: KI-Lösungen, die „fast richtig, aber eben nicht ganz richtig“ sind und deren Debugging dann länger dauert als das Selberschreiben.

Adoption rauf, Vertrauen runter: Das ist kein Widerspruch, sondern Professionalisierung. Die Tools sind Alltag geworden, also werden sie entsprechend nüchtern beurteilt.

Versprechen 3: „Der Code wird besser“

Hier sind die Daten am unbequemsten. GitClear analysierte 211 Millionen geänderte Codezeilen aus den Jahren 2020 bis 2024: Der Anteil kopierter (duplizierter) Zeilen stieg von 8,3 auf 12,3 Prozent, während Refactoring (das Umbauen und Aufräumen bestehenden Codes) von 25 Prozent der Änderungen auf unter 10 Prozent einbrach. 2024 überstieg Copy-Paste erstmals die Zahl verschobener Zeilen. Kurz: Es wird mehr Code erzeugt und weniger gepflegt. Genau das ist die „technische Zeitbombe“ aus meinem damaligen Beitrag, nun mit Messwerten.

Und trotzdem gibt es eine Gegenrechnung

Wer daraus „KI-Coding ist gescheitert“ macht, liest die Daten so selektiv wie die Hype-Fraktion ein Jahr zuvor. Meine eigene Bilanz steht ja im Vibe-Coding-Artikel: Es gibt Apps von mir im Store, die es ohne KI-Unterstützung schlicht nicht gäbe. Die Studien messen erfahrene Profis in vertrauten, reifen Codebasen. Nicht gemessen werden der Prototyp am Wochenende, das Boilerplate, der Einstieg in eine fremde Domäne oder das Ein-Personen-Projekt, in dem niemand auf ein Review aus dem Team warten muss. Dort liegen die Gewinne, und sie sind real.

Real ist allerdings auch die Kehrseite in Marktform: eine Flut generierter Apps, von denen kaum eine ein Publikum findet. Die habe ich hier seziert. Leichter bauen heißt nicht leichter bestehen.

Die Synthese hat gehalten

Ein Jahr später fühle ich mich in der damaligen Synthese bestätigt, und zwar präziser, als mir lieb ist. Der Engpass ist nicht mehr das Schreiben von Code, sondern die Urteilskraft darüber: „Fast richtig“ zu erkennen, bevor es in Produktion geht. Die METR-Studie zeigt, dass sich diese Prüfarbeit nicht anfühlt wie Arbeit, die langsamer macht. Manchmal ist sie es aber. Der Stack-Overflow-Survey zeigt, dass die Branche das inzwischen weiß. Und GitClear zeigt, was passiert, wenn die Prüfarbeit unterbleibt. Entwickeln heißt inzwischen auditieren. Das ist keine Zukunftsprognose mehr, sondern die Stellenbeschreibung.

Quellen