Beyond Functional Correctness -- Design-Probleme in AI-IDE-generierten Grossprojekten
Syed Mohammad Kashif et al. stellen eine unbequeme Frage: Wenn AI-IDEs wie Cursor funktional korrekten Code liefern, ist damit alles gut? Die Antwort ist ein klares Nein. Die Autoren lassen Cursor zehn grosse Projekte generieren und unterziehen sie statischer Analyse. Das Ergebnis: 91% der Features funktionieren, aber der Code ist durchzogen von Duplikation, uebermaessiger Komplexitaet und systematischen Verletzungen grundlegender Design-Prinzipien. Die Studie verschiebt den Fokus von der Frage "Funktioniert der Code?" hin zu "Kann man den Code auch warten?"
Kernaussagen
AI-IDEs erzeugen Code, der funktional ueberwiegend korrekt ist. Ueber zehn Projekte hinweg liegt die durchschnittliche funktionale Korrektheit bei 91%. Diese Zahl verdeckt jedoch die strukturellen Probleme unter der Oberflaeche.
Die statische Analyse mit SonarQube identifiziert ueber 4.400 Design-Issues ueber alle zehn Projekte. Die haeufigsten Kategorien: Code-Duplikation, hohe zyklomatische Komplexitaet, uebergrosse Methoden und Klassen, Verletzungen von Framework-Best-Practices, mangelhaftes Exception-Handling und Accessibility-Probleme. Jedes einzelne dieser Probleme ist fuer sich genommen beherrschbar -- in der Summe entsteht eine technische Schuld, die mit jeder Iteration waechst.
Auf architektonischer Ebene verletzen die generierten Projekte konsistent das Single Responsibility Principle, das Separation of Concerns und das DRY-Prinzip. Klassen uebernehmen zu viele Aufgaben, Geschaeftslogik mischt sich mit Darstellungslogik, und identische Code-Bloecke tauchen an mehreren Stellen auf. Das sind keine Einzelfaelle, sondern systematische Muster.
Methodik
Die Autoren verwenden ein Feature-Driven Human-In-The-Loop Framework: Jedes Projekt wird als Feature-Liste spezifiziert, Cursor generiert den Code, und menschliche Pruefer verifizieren die funktionale Korrektheit jedes Features. Die zehn Projekte umfassen unterschiedliche Domaenen und Technologie-Stacks, um Generalisierbarkeit sicherzustellen.
Die Projekte sind keine Spielzeug-Beispiele. Durchschnittlich umfasst ein Projekt 16.965 Lines of Code verteilt auf 114 Dateien. Das entspricht einem Umfang, wie er in realen Anwendungen vorkommt.
Fuer die Design-Analyse kommt SonarQube zum Einsatz, ein industrieweit etabliertes Werkzeug fuer statische Code-Analyse. Die identifizierten Issues werden nach Kategorie und Schweregrad klassifiziert. Diese Wahl ist bewusst konservativ -- SonarQube erkennt nur Probleme, die sich regelbasiert erfassen lassen. Subtilere Architekturmaengel, die menschliches Urteil erfordern, sind in den 4.400 Issues nicht enthalten.
Relevanz fuer die Praxis
91% Korrektheit ist nicht 91% Produktionsreife. Die Zahl klingt gut, taeuscht aber. Die restlichen 9% fehlender Funktionalitaet plus die ueber 4.400 Design-Issues sind genau das, was in Produktion teuer wird. Bugs in den letzten 9% treten oft in Edge Cases auf, die spaet entdeckt werden. Die Design-Probleme akkumulieren technische Schuld, die kuenftige Aenderungen verlangsamt und fehleranfaelliger macht.
AI-IDEs sind Entwurfs-Werkzeuge, keine Fertigungsstrassen. Der generierte Code braucht Review und Refactoring durch erfahrene Entwickler. Wer den Output von Cursor oder vergleichbaren Tools ohne Pruefung in Produktion bringt, importiert systematisch technische Schuld. Die Staerke der AI-IDEs liegt im schnellen Prototyping und im Erstellen einer funktionalen Basis -- nicht im Liefern wartbarer Software.
Statische Analyse als Pflicht-Gate. Die Ergebnisse unterstreichen, dass statische Analyse bei AI-generiertem Code nicht optional ist. Ein SonarQube-Gate in der CI-Pipeline faengt die grobsten Probleme ab, bevor sie sich festsetzen. Das gilt umso mehr, wenn groessere Teile des Codes maschinell erzeugt werden und die natuerliche Qualitaetssicherung durch schrittweises menschliches Schreiben entfaellt.