Beyond Functional Correctness: Design Issues in AI IDE-Generated Large-Scale Projects

Die Studie zeigt, dass Cursor zwar mit einem menschlichen Feedback-Loop funktionale Großprojekte generieren kann, diese jedoch signifikante Designmängel aufweisen, die langfristige Wartungs- und Evolvierbarkeitsrisiken bergen und eine sorgfältige Prüfung durch erfahrene Entwickler erfordern.

Das Wesentliche

Stellen Sie sich vor, Sie haben einen unglaublich talentierten, aber noch sehr jungen Koch namens Cursor. Dieser Koch kann nicht nur ein einzelnes Gericht zubereiten, sondern hat kürzlich den Auftrag erhalten, ein komplettes, riesiges Restaurant mit 10 verschiedenen Speisekarten (von mobilen Apps bis zu Web-Portalen) zu eröffnen.

Die Forscher in diesem Papier haben genau das getan: Sie haben Cursor beauftragt, 10 große Software-Projekte zu „kochen", und dann genau untersucht, wie das Essen schmeckt und wie sauber die Küche ist.

Hier ist die Geschichte, was sie herausgefunden haben, einfach erklärt:

1. Das Problem: Der Koch kann schnell kochen, aber die Küche ist chaotisch

Früher konnten KI-Tools nur einzelne Zutaten (Code-Schnipsel) liefern. Der neue Cursor ist wie ein Koch, der den ganzen Raum betritt, den Kühlschrank öffnet und sofort ein komplettes Menü plant. Das ist beeindruckend!

Aber die Forscher stellten fest: Wenn man dem Koch einfach sagt „Mach mal was Großes!", passiert oft ein Chaos. Der Koch versucht, alles auf einmal zu machen, ohne Plan. Das Ergebnis ist oft ungenießbar oder bricht zusammen.

2. Die Lösung: Der FD-HITL-Kochplan

Damit Cursor wirklich gute Arbeit leistet, entwickelten die Forscher einen strengen Kochplan, den sie FD-HITL nennen (Feature-Driven Human-In-The-Loop).

• Statt „Koch einfach los": Der Mensch (der Chefkoch) sagt dem KI-Koch erst: „Hier ist der Plan. Wir brauchen erst die Suppe, dann das Hauptgericht. Mach Schritt für Schritt."
• Der Ablauf: Der Mensch plant die Features (z. B. „Login-Funktion"), der KI-Koch baut sie, der Mensch prüft sie, und dann geht es zum nächsten Feature.
• Das Ergebnis: Mit diesem Plan konnte Cursor 10 riesige Projekte bauen. Diese Projekte waren groß (durchschnittlich so groß wie ein mehrstöckiges Gebäude mit über 16.000 Zeilen Code) und funktionierten zu 91 % richtig. Das ist eine enorme Leistung!

3. Der Haken: Die Küche sieht aus wie nach einer Schlacht

Auch wenn das Essen (die Funktion) schmeckte, war die Küche (der Code) ein absolutes Desaster. Die Forscher haben zwei „Kücheninspektoren" (SonarQube und CodeScene) eingesetzt, um die Projekte zu überprüfen.

Was fanden sie?
Stellen Sie sich vor, Sie betreten die Küche und sehen Folgendes:

• Doppelte Rezepte (Code Duplication): Der Koch hat das gleiche Rezept 50-mal abgeschrieben, nur mit kleinen Änderungen. Wenn man das Salz im Originalrezept ändern will, muss man alle 50 Kopien ändern. Das ist ein Albtraum für die Wartung.
• Riesige Töpfe (Large Methods): Der Koch hat einen Topf benutzt, der so groß ist, dass er 200 Zutaten auf einmal enthält. Niemand versteht mehr, was darin passiert.
• Verwickelte Schlingen (Complexity): Der Koch hat die Zutaten in so viele Schichten verpackt, dass man den Boden nicht mehr sieht.
• Fehlende Sicherheit (Accessibility & Exceptions): Die Türrahmen sind zu niedrig (für Rollstuhlfahrer unpassierbar) und wenn etwas brennt, gibt es keinen Feuerlöscher, sondern nur ein „Oh nein"-Geräusch.

Insgesamt fanden sie über 4.000 Design-Probleme. Viele davon verletzen goldene Regeln des Kochens (wie „Ein Koch sollte nur eine Sache auf einmal tun" – das Single Responsibility Principle).

4. Die wichtigsten Erkenntnisse (Die Moral der Geschichte)

1. KI ist ein mächtiger Assistent, kein Ersatz für den Chefkoch: Cursor kann das schwere Heben übernehmen und schnell Zutaten schneiden. Aber wenn der Mensch nicht den Plan macht und die Qualität kontrolliert, entsteht ein Chaos, das später teuer zu reparieren ist.
2. Funktionieren reicht nicht: Ein Projekt kann laufen (der Burger schmeckt), aber wenn die Küche so dreckig ist (schlechter Code), wird das Restaurant in sechs Monaten schließen müssen, weil niemand mehr weiß, wie man die Heizung repariert.
3. Struktur ist alles: Wenn man KI einfach so „vibecodet" (einfach drauflos tippen), scheitert sie bei großen Projekten. Man braucht einen menschlichen Leitfaden, der die Arbeit in kleine, prüfbare Häppchen zerlegt.
4. Spezifische Fehler: Je nachdem, welche „Küche" (Technologie wie React oder Java) man nutzt, macht der KI-Koch spezifische Fehler. Er vergisst zum Beispiel oft, die Zutaten richtig zu beschriften (Accessibility) oder benutzt veraltete Werkzeuge.

Fazit für die Praxis

Die KI-Tools sind wie ein Super-Assistent, der Ihnen hilft, ein riesiges Haus in Rekordzeit zu bauen. Aber wenn Sie nicht selbst als Architekt und Bauleiter fungieren, wird das Haus zwar stehen, aber die Leitungen sind verlegt, die Wände sind schief, und wenn Sie später ein Fenster öffnen wollen, stürzt das ganze Gebäude zusammen.

Die Botschaft: Nutzen Sie die KI, aber bleiben Sie der Chef. Planen Sie genau, prüfen Sie jeden Schritt und lassen Sie sich nicht von der Geschwindigkeit blenden. Ein erfahrener Entwickler muss den Code am Ende genau durchsehen, bevor er in die Produktion geht.

Technische Zusammenfassung

1. Problemstellung und Motivation

Die Integration von Large Language Models (LLMs) in die Softwareentwicklung hat sich von der Generierung einzelner Code-Snippets hin zu agenticfähigen KI-IDEs (wie Cursor) entwickelt, die ganze Projekte im Kontext erstellen können. Bisherige Studien konzentrierten sich jedoch meist auf kleine, einfache Projekte oder die Funktionalität von Code-Snippets. Es fehlt an empirischen Belegen dafür, inwieweit KI-IDEs großskalige Softwaresysteme (im industriellen Maßstab) generieren können und welche Design-Probleme in diesen Systemen auftreten.

Das Paper adressiert die Lücke zwischen funktionaler Korrektheit (läuft der Code?) und Design-Qualität (ist der Code wartbar, erweiterbar und folgt er Prinzipien wie DRY oder SRP?). Es wird die Hypothese aufgestellt, dass KI-IDEs zwar funktionale Systeme produzieren können, diese jedoch erhebliche Design-Mängel aufweisen, die langfristige Risiken für Wartbarkeit und Evolvierbarkeit bergen.

2. Methodik

Die Studie ist eine empirische Untersuchung, die in zwei Hauptphasen unterteilt ist:

A. Generierung von Projekten (FD-HITL Framework)

Um realistische, großskalige Projekte zu generieren, entwickelten die Autoren das Feature-Driven Human-In-The-Loop (FD-HITL) Framework. Dies ist eine systematische Abkehr vom „Vibe Coding" (ad-hoc Prompting ohne Planung). Das Framework umfasst vier Phasen:

1. Initialisierung: Definition des Projektkontexts und Auswahl des Tech-Stacks durch kollaboratives Reasoning mit Cursor.
2. Anforderungen & Design: Generierung von requirements.md und tasklist.md. Das Projekt wird in unabhängig testbare Features zerlegt, die Backend, Frontend und Datenbank umfassen.
3. Implementierung: Iterative Entwicklung Feature für Feature. Zuerst Backend/DB, dann Frontend. Ständiges menschliches Feedback und Debugging (z. B. durch Anhängen von Fehlerlogs) sind integraler Bestandteil.
4. Systemweite Prüfung: Manuelle Tests des gesamten Systems gegen die Anforderungen und Nachbesserungen.

B. Datenerhebung und Analyse

• Datensatz: Es wurden 10 komplexe Projekte in drei Domänen generiert (Web, Mobile, Utility Tools) mit Technologien wie React, Spring Boot, Django, Vue.js und PHP.
• Kriterien: Jedes Projekt hatte mindestens 8.000 Zeilen Code (LoC), nutzte mindestens 3 Technologien und folgte einer komplexen Architektur (Client-Server oder modulare Monolithen).
• Bewertung:
  • Funktionale Korrektheit: Manuelle Überprüfung durch Ausführung der Projekte gegen die Anforderungen.
  • Design-Qualität: Einsatz zweier statischer Analyse-Tools:
    • CodeScene: Fokus auf High-Level-Design und Komplexität.
    • SonarQube: Fokus auf Code-Smells, Sicherheitslücken und Best-Practice-Verletzungen (mit manueller Filterung von False Positives).

3. Wichtige Beiträge

1. FD-HITL Framework: Ein neuartiger Ansatz zur systematischen Generierung großskaliger KI-Projekte, der menschliche Planung und KI-Execution kombiniert.
2. DIinAGP-Datensatz: Ein kuratierter Datensatz mit 10 Projektbeschreibungen, den entsprechenden Cursor-generierten Projekten (insgesamt ~170.000 Zeilen Code) und den identifizierten Design-Problemen.
3. Empirische Evidenz: Eine umfassende quantitative und qualitative Analyse der Design-Qualität von KI-generiertem Code auf Projekt-Ebene.
4. Praktische Empfehlungen: Leitlinien für Entwickler, um Design-Probleme bei der Nutzung von KI-IDEs zu minimieren.

4. Ergebnisse

A. Funktionale Korrektheit und Skalierbarkeit (RQ1)

• Erfolgreiche Generierung: Mit dem FD-HITL Framework konnte Cursor durchschnittlich 16.965 Zeilen Code und 114 Dateien pro Projekt generieren.
• Funktionalität: Die Projekte erreichten eine durchschnittliche funktionale Korrektheit von 91 %. Die meisten Anforderungen wurden erfüllt, jedoch gab es Lücken (z. B. fehlende Update-Funktionen oder logische Fehler in komplexen UI-Komponenten).
• Fazit: KI-IDEs können funktionale Großprojekte erstellen, wenn sie durch einen strukturierten, menschgeleiteten Prozess gesteuert werden.

B. Design-Probleme (RQ2)

Trotz funktionaler Korrektheit wiesen die Projekte massive Design-Mängel auf:

• Anzahl der Probleme:

  • CodeScene: 1.305 Probleme in 9 Kategorien.
  • SonarQube: 3.193 Probleme in 11 Kategorien (nach Filterung von 1.612 False Positives).

• Häufigste Probleme:

  1. Code-Duplizierung (28,4% bei CodeScene): Verletzung des DRY-Prinzips (Don't Repeat Yourself). Oft wurden ähnliche Logiken in verschiedenen Methoden kopiert.
  2. Hohe Komplexität: „Complex Methods" (hohe zyklomatische Komplexität), „Large Methods" (zu viele Zeilen Code pro Methode) und „Complex Conditionals".
  3. Verletzung von Design-Prinzipien:
     • SRP (Single Responsibility Principle): Methoden und Klassen übernahmen zu viele Aufgaben (z. B. Datenvalidierung, UI-Rendering und Datenbankzugriff in einer Funktion).
     • SoC (Separation of Concerns): Controller-Logik vermischte sich mit UI-Logik.
     • KISS (Keep It Simple, Stupid): Übermäßig verschachtelte Bedingungen und tiefe Verschachtelungstiefe.
  4. Framework-Best-Practice-Verletzungen: Fehlende Props-Validierung in React, falsche Exception-Handling-Muster (zu generische Exceptions) und veraltete API-Nutzung.
  5. Barrierefreiheit (Accessibility): Fehlende Labels für Formulare, nicht tastaturbedienbare interaktive Elemente.

• Technologie-Spezifika: 59 % der SonarQube-Probleme waren technologie-spezifisch (z. B. React-Props, Spring Boot Dependency Injection, PHP-Namespace-Handling).

C. Überlappung der Tools

Nur 133 Probleme wurden von beiden Tools gleichzeitig erkannt. Diese Überlappungen hatten jedoch fast immer eine kritische Schwere und betrafen hauptsächlich Code-Komplexität. Dies deutet darauf hin, dass Probleme, die von mehreren Tools erkannt werden, höchste Priorität für Refactoring haben.

5. Bedeutung und Implikationen

• Für die Praxis:

  • Fokus auf Design-Qualität: Entwickler dürfen sich nicht nur auf „läuft es?" verlassen. Statische Analyse-Tools müssen kontinuierlich genutzt werden.
  • Menschliche Steuerung ist essenziell: KI-IDEs ersetzen nicht die Ingenieurskunst, insbesondere bei der Anforderungsanalyse, Architekturplanung und Zerlegung in testbare Features. Der menschliche Aufwand muss in die Hoch-Level-Aufgaben (Planung, Review) verlagert werden.
  • Strategische Generierung: Backend und Datenbanken sollten zuerst generiert und getestet werden, bevor das Frontend integriert wird, um Fehler frühzeitig zu isolieren.
  • Barrierefreiheit: Spezifische Anforderungen für Accessibility müssen explizit im Prompting definiert werden, da KI dies oft ignoriert.

• Für die Forschung:

  • Bestehende statische Analyse-Tools sind für Snippets gut, stoßen aber bei der Bewertung der Architektur ganzer KI-generierter Systeme an Grenzen.
  • Zukünftige Tools sollten Design-Constraints (z. B. maximale Methodenlänge) direkt in den Generierungsprozess integrieren.
  • Das Verhalten von Entwicklern („Vibe Coding" vs. strukturiertes Vorgehen) hat einen direkten Einfluss auf die Code-Qualität und muss weiter untersucht werden.

Fazit

Das Paper zeigt, dass KI-IDEs wie Cursor in der Lage sind, funktional korrekte, großskalige Softwareprojekte zu generieren, wenn sie durch ein systematisches Framework (FD-HITL) geleitet werden. Allerdings produzieren diese Systeme signifikante Design-Probleme, die die langfristige Wartbarkeit gefährden. KI-IDEs sind derzeit keine vollständigen Ersatzlösungen für erfahrene Entwickler, sondern Werkzeuge, die eine strenge menschliche Aufsicht und ein tiefes Verständnis von Software-Design erfordern, um qualitativ hochwertige Ergebnisse zu erzielen.