Dein Team schiebt Code schneller raus als je zuvor. Die Sprint-Velocity-Charts zeigen steil nach oben. Pull Requests — also Bündel von Codeänderungen, die zur Review vorgeschlagen werden — fliegen durch die Freigabe wie geschmiert. Der PM schreibt es den AI-Coding-Tools zu. Alle nicken. Das Leben ist schön.

Nur dass die Bug-Tickets steigen. Reverts — wenn man eine Änderung rückgängig macht, weil sie etwas kaputt gemacht hat — passieren häufiger. Das Backlog wächst. Niemand verbindet die Punkte, weil das Dashboard sagt, ihr reißt alles weg.

Am 30. März 2026 veröffentlichte ein Forscherteam der Singapore Management University die bislang größte empirische Studie zur Qualität von KI-generiertem Code. Sie analysierten 304.362 verifizierte KI-geschriebene Commits (Codeänderungen, die nachweislich von KI-Tools stammen) in 6.275 GitHub-Repositories, verteilt auf fünf große Tools: GitHub Copilot, Claude, Cursor, Gemini und Devin. Der Zeitraum: Januar 2024 bis Oktober 2025.

Was sie fanden, sollte eure Velocity-Feier deutlich leiser werden lassen.

Über all diese Repos hinweg identifizierten die Forscher 484.606 einzelne Probleme. Davon waren 89 % Code Smells — Muster, die heute funktionieren, aber morgen vor sich hin faulen. Knapp 6 % waren Laufzeitfehler. Und 5,1 % waren Sicherheitslücken. Zwischen 15 % und 29 % der KI-Commits brachten mindestens ein Problem mit, je nach Tool. Gemini saß mit 28,7 % ganz oben. Copilot kam auf 17,3 % — besser, aber immer noch jeder sechste Commit mit Altlasten im Gepäck.

Der eigentliche Hammer: 24,2 % dieser von KI eingeschleppten Probleme waren in der aktuellsten Version des Codes noch quicklebendig. Sicherheitslücken hatten eine Überlebensrate von 41,1 % — die höchste aller Kategorien. Bis Februar 2026 verfolgte die Studie über 110.000 überlebende Probleme, die KI dort hingesetzt hat und die nie ein Mensch aufgeräumt hat. Die Forscher formulierten es nüchtern: KI-Assistenten beheben ungefähr so viele Code Smells, wie sie erzeugen, aber sie "erzeugen mehr Bugs und Sicherheitsprobleme, als sie lösen."

Einen Tag zuvor, am 29. März, veröffentlichte Exceeds AI Benchmark-Daten, die erklären, warum das auf Organisationsebene relevant ist. Ihre Analyse beziffert die sichere KI-Code-Quote auf 25–40 % des Gesamtoutputs — der Bereich, in dem Teams echte 10–15 % Produktivitätsgewinne sehen, ohne in Nacharbeit zu ertrinken. Der aktuelle globale Durchschnitt? 41–42 %. Bereits über der Grenze. Teams mit mehr als 40 % KI-Code zeigen 20–25 % höhere Nacharbeitsraten. Und hier kommt das Produktivitätsparadoxon, das jedem Engineering Manager den Schlaf rauben sollte: Entwickler fühlen sich 20 % schneller, messen aber tatsächlich 19 % langsamer, wenn man Review-Aufwand, Debugging und Fixes einrechnet.

Gefühlte Geschwindigkeit geht hoch. Tatsächlicher Durchsatz geht runter. Das Dashboard lügt.

Am 6. April gab die Forscherin Margaret-Anne Storey von der University of Victoria diesem Problem in einem neuen Paper einen Namen. Sie nennt es "Cognitive Debt" — die Erosion des geteilten Verständnisses innerhalb eines Teams. Wenn KI Code schneller generiert, als Entwickler ihn verstehen können, verliert das Team die Fähigkeit, sein eigenes System sicher zu verändern. Das ist nicht nur Technical Debt (unsauberer Code, den man irgendwann aufräumt). Es ist Wissensschuld — niemand versteht mehr vollständig, was die Codebase eigentlich tut.

Nichts davon bedeutet, dass du aufhören solltest, KI-Coding-Tools zu nutzen. Die Produktivitätsgewinne sind real, und der Geist geht nicht zurück in die Flasche. Aber die Frage, die dein Team stellen sollte, ist nicht "wie viel Code kann KI für uns schreiben?" Sondern: "Wie viel KI-generierten Code kann unser Review-Prozess und unsere Testabdeckung tatsächlich tragen, bevor uns die Räder abfallen?"

Velocity war schon immer eine Eitelkeitsmetrik — eine Zahl, die beeindruckend aussieht, aber dir nicht verrät, ob du etwas Solides baust. Jetzt, ohne einen Qualitätsnenner, ist sie eine gefährliche. Dein Sprint-Chart zeigt nach oben rechts. Dein Bug-Count auch. Dasselbe Diagramm. Eine andere Geschichte.