Die wahre Natur der KI-Programmierung: Die vollständige Projektbestehensrate beträgt nur 27%.

AI-Programmierung ist eine sehr praktische Fähigkeit. Doch im Internet kann man auch immer wieder Programmierer hören, die sich darüber beschweren, dass AI "nicht versteht, was man von ihr will" und "schwerlich das eigentliche Problem findet". Es gibt sogar Erfahrungsberichte, in denen direkt vorgeschlagen wird, "bei jeder Codegenerierung nicht mehr als 5 Zeilen zu erzeugen".

In letzter Zeit haben viele AI-Tools behauptet, dass sie in der Lage sind, vollständige Codeprojekte von Grund auf schnell zu erstellen.

Kann ein AI-Programmieragent wirklich vollständige Softwareprojekte von Grund auf erstellen? Kürzlich hat ein Forscherteam aus mehreren Universitäten diese Frage untersucht.

Shanghai Jiao Tong University, Shanghai Chuangzhi College, University of California, Merced und Beijing Institute of Technology (in der Reihenfolge der Artikelautoren) haben gemeinsam ProjDevBench herausgegeben – das erste Benchmark, das die Fähigkeit von AI-Programmieragenten für die end-to-end-Projektentwicklung durch feingranulare Rückmeldungen eines Online-Judges bewertet. Es verlangt von den Agenten, dass sie allein anhand eines natursprachlichen Anforderungsdokuments ein vollständiges, ausführbares Software-Repository von Grund auf erstellen.

Wenn die Aufgabe von "Existierenden Code ergänzen" zu "Von Grund auf erstellen" wechselt, sinkt die Leistung dramatisch.

Das Ergebnis lässt zu denken: Die Gesamt-AC-Rate aller Agenten beträgt nur 27,38%.

Zusammenfassung der Schlussfolgerungen dieser Studie:

• Die Gesamt-AC-Rate von sechs gängigen Programmieragenten (Cursor, GitHub Copilot, Claude Code usw.) beträgt nur 27,38%. Ihre Leistung sinkt stark bei Aufgaben, die von Grund auf erstellt werden müssen.
• Die feingranularen diagnostischen Rückmeldungen, die der Online-Judge liefert (Kompilierungsfehler (CE), Laufzeitfehler (RE), Zeitüberschreitung (TLE), Speicherüberschreitung (MLE), falsche Antwort (WA) usw.), sind ein Schlüsselbestandteil bei der Bewertung der end-to-end-Entwicklungsfähigkeit und sind weitaus besser als die traditionelle binäre Entscheidung zwischen "Bestanden" und "Nicht bestanden".
• Es besteht eine stark negative Korrelation (-0,734) zwischen der Anzahl der Interaktionsrunden und der Leistung. Wenn die Agenten auf Schwierigkeiten stoßen, geraten sie in einen ineffizienten Versuchs- und Irrtumszyklus, anstatt durch Reflexion einen Durchbruch zu erzielen.

Warum brauchen wir ein Benchmark für end-to-end-Projektentwicklung?

Vorhandene Benchmarks wie HumanEval und MBPP konzentrieren sich auf die Generierung von Funktionscode, und SWE-bench befasst sich mit der Behebung von Fehlern. Doch in der realen Softwareentwicklung wird viel mehr benötigt. Wenn Entwickler Cursor oder GitHub Copilot für "vibe coding" verwenden, erwarten sie, dass die Agenten in der Lage sind: Das Systemdesign von Grund auf zu entwerfen, mehrere Quellcode-Dateien zu erstellen und zu organisieren, Abhängigkeiten und Build-Systeme zu konfigurieren (z.B. CMakeLists.txt) und schließlich ein vollständiges, kompilierbares und ausführbares Projekt zu liefern.

Diese end-to-end-Fähigkeit zur Projektentwicklung wurde bisher nie systematisch bewertet. ProjDevBench schließt diese Lücke.

Der wesentliche Unterschied zu traditionellen Benchmarks besteht darin: HumanEval und andere verlangen von den Agenten, Codeausschnitte zu ergänzen, SWE-bench verlangt die Behebung von Fehlern in bestehenden Code-Bibliotheken, während ProjDevBench von den Agenten verlangt, dass sie wie echte Softwareingenieure den gesamten Prozess von der Architekturplanung bis zur Codierung mehrerer Dateien eigenständig durchführen, ohne irgendein initiales Code-Template.

Doppelter Bewertungsmechanismus: Online-Judge-Test + Code-Review

Im Gegensatz zu früheren Tests, die nur "Bestanden" oder "Nicht bestanden" zurückgaben, verwendet ProjDevBench ein Zwei-Spur-System zur Bewertung:

Bewertung durch den Online-Judge (80%): Durch einen strengen Black-Box-Test in einem Online-Judgesystem werden feingranulare diagnostische Signale geliefert – Kompilierungsfehler (CE), Laufzeitfehler (RE), Zeitüberschreitung (TLE), Speicherüberschreitung (MLE), falsche Antwort (WA) usw. Diese Signale ermöglichen es den Agenten, iterativ zu debuggen und simulieren den realen Entwicklungsprozess "Code schreiben - Fehler erhalten - Code ändern".

Bewertung durch Code-Review (20%): Durch die Kombination von Regelskripten und Code-Reviews, die von einem Large Language Model (LLM) simuliert werden, können Probleme erkannt werden, die der Online-Judge-Test nicht erfassen kann: Ob explizite Regeln verletzt werden (z.B. die Verwendung verbotener Bibliotheken), ob es betrügerische Lösungen gibt oder ob die Test-Suite ausgenutzt wird, anstatt die tatsächlichen Einschränkungen zu befolgen.

Der Kerngedanke dieser Gestaltung ist: Testfälle allein können die Code-Qualität nicht vollständig bewerten. Eine Lösung, die alle Tests besteht, könnte auf schlampige Weise erstellt worden sein, ohne dass das Problem wirklich verstanden und die Spezifikationen befolgt wurden. Der vollständige Prozess ist im folgenden Bild dargestellt:

Aufgabenentwurf und Datenquelle

Das Forscherteam hat 20 anspruchsvolle Programmierprojekte aus der Online-Judge-Plattform der ACM-Klasse der Shanghai Jiao Tong University (https://acm.sjtu.edu.cn/home) ausgewählt. Diese Projekte umfassen 8 Kategorien, wie Algorithmen, Datenstrukturen, Interpreter, Verwaltungssysteme und Speicherkomponenten.

Diese Aufgaben wurden in drei Phasen selektiert:

Initiale Sammlung: Auswahl aus etwa 2.800 Kandidatenaufgaben

Bereichsfilterung: Beibehaltung von Projektaufgaben, die die Implementierung mehrerer Dateien, die Organisation von Modulen und die Konfiguration von Build-Systemen erfordern, Ausschluss von reinen Algorithmenaufgaben in einer einzigen Datei. Es blieben etwa 100 Aufgaben übrig.

Qualitätsfilterung: Auswahl von Aufgaben mit klaren Spezifikationen, umfassenden Test-Suiten und nicht-trivialer Schwierigkeit. Schließlich blieben 20 Aufgaben übrig.

Zwei Aufgabenmodi:

Easy-Modus (mit Code-Bibliothek): Es wird ein Teil des Codes bereitgestellt, und die Aufgabe besteht darin, das Projekt zu ergänzen.

Hard-Modus (ohne Code-Bibliothek): Es wird nur eine natursprachliche Spezifikation bereitgestellt, und die Aufgabe besteht darin, das Projekt von Grund auf zu erstellen.

Die menschlichen Referenzlösungen umfassen durchschnittlich etwa 10 Quellcode-Dateien. Die Agenten müssen durchschnittlich 138 Mal Tools aufrufen und 4,81 M Tokens verbrauchen, um eine Aufgabe zu lösen. Die komplexesten Aufgaben dauern über zwei Stunden.

Interpretation der Experimentergebnisse

Das Forscherteam hat sechs gängige Programmieragenten bewertet: Cursor, GitHub Copilot, Claude Code, Augment, Codex CLI, Gemini CLI, in Kombination mit modernen Modellen wie GPT-5, Claude Sonnet 4.5 und Gemini 3 Pro.

Gesamtleistung: Codex + GPT-5 hat die höchste Gesamtnote von 77,85 erzielt, aber die Gesamt-AC-Rate aller Agenten beträgt nur 27,38%.

Die Leistung sinkt dramatisch, wenn das Projekt von Grund auf erstellt werden muss: Dies ist die wichtigste Erkenntnis. Wenn die Aufgabe vom Easy-Modus (mit Code-Bibliothek) in den Hard-Modus (ohne Code-Bibliothek) wechselt, sinkt die Leistung bei den meisten Konfigurationen deutlich. Beispiel:

GitHub Copilot + Sonnet-4.5: 71,10 → 36,63

Gemini CLI + Gemini-3-Pro: 74,57 → 35,53

Codex + Sonnet-4.5: 66,07 → 31,88

Dies zeigt, dass die aktuellen Agenten gut darin sind, bestehenden Code zu reparieren, aber die Fähigkeit zur makroskopischen Architekturplanung von Grund auf fehlt ihnen.

Tiefgehende Analyse der Fehlermodi

Das Forscherteam hat alle Einreichungen systematisch analysiert und die Kernschwächen der Agenten aufgedeckt: Verteilung der Einreichungsstatus:

Akzeptiert: 27,38% Falsche Antwort: 41,86% Zeitüberschreitung: 13,91% Laufzeitfehler: 7,01% Kompilierungsfehler: 4,52% Speicherlecks: 3,51%

Fehlinterpretation der Spezifikationen: Die Agenten generieren oft syntaktisch korrekten Rahmen-Code, der jedoch wichtige Geschäftslogiken auslässt. Bei der Aufgabe des Zugticket-Verwaltungssystems haben alle Agenten die Benutzerverwaltung und die Zugsuche implementiert, aber das Sitzplatz-Verwaltungssystem ausgelassen. Bei der Minesweeper-Aufgabe haben die Agenten 3.825 von 3.789 sicheren Feldern besucht, was darauf hinweist, dass die Implementierung unvollständig ist, nicht aber ein logischer Fehler vorliegt.

Schwache Behandlung von Randfällen: Viele Laufzeitfehler resultieren aus Problemen wie Dereferenzierung von Nullpointern und Array-Überläufen. Bei der Implementierung einer Map fehlt in der Rot-Schwarz-Baum-Drehfunktion die Prüfung auf Nullpointer. Bei der Bookstore-Aufgabe konnten alle Agenten die versteckten Testfälle nicht bestehen, was die mangelnde Behandlung von leeren Strings, Datei-E/A-Ausnahmen und verschachtelten Szenarien aufzeigt.

Fehlende Analyse der Zeitkomplexität: Bei der Aufgabe des ICPC-Verwaltungssystems sortieren die Agenten alle Teams nach jedem Entsperrungsvorgang neu und erhalten eine Lösung mit O(K × N log N), während die richtige Methode die Lokalisierung der Rangänderungen nutzen würde, um O(K log N) zu erreichen. Die Agenten neigen dazu, bekannte, aber suboptimale Muster zu verwenden, anstatt die Problemmerkmale zu analysieren und gezielt zu optimieren.

Begrenzte Ressourcenverwaltung: Bei der Aufgabe des BASIC-Interpreters wird, wenn std::stoi() eine Ausnahme wirft, das bereits zugewiesene Ausdrucksobjekt nicht freigegeben, was zu Speicherlecks führt. Die Agenten behandeln explizite Fehlerpfade, aber ignorieren die Ausnahmen, die bei normalen Operationen auftreten können.

Negative Korrelation zwischen Interaktionslänge und Leistung

Das Forscherteam hat ein unintuitives Phänomen entdeckt: Je mehr Interaktionsrunden die Agenten haben und je mehr Tokens sie verbrauchen, desto geringer ist ihre Endnote.

Korrelationskoeffizient zwischen Tokens und Note: -0,734

Korrelationskoeffizient zwischen Interaktionsrunden und Note: -0,668

Korrelationskoeffizient zwischen Interaktionsrunden und Tokenverbrauch: 0,898

Dies bedeutet, dass die Agenten, wenn sie auf Schwierigkeiten stoßen, oft in einen ineffizienten "Versuch - Fehler - neuer Versuch"-Zyklus geraten und nicht wie menschliche Experten durch tiefes Denken eine bessere Lösung finden können. Die zusätzlichen Tokens stammen hauptsächlich aus wiederholten Interaktionsrunden, nicht aus wenigen, aber tiefgehenden langen Schlüssen.

Die Korrelation zwischen der statischen Code-Komplexität (Anzahl der Dateien, Anzahl der geänderten Zeilen) und der Leistung ist schwach. Dies zeigt, dass die Schwierigkeit der Aufgabe hauptsächlich in der verlängerten Interaktion und der verringerten Leistung liegt, nicht direkt in der Codegröße.

Der einzigartige Wert des Code-Reviews

Abgesehen von den Ausführungsergebnissen zeigt das Code-Review die Blindstellen der Agenten beim Verständnis des Softwareentwicklungsprozesses auf:

Fehlverständnis der Versionskontrolle: Die Agenten ändern oft lokal den Code und erstellen Commits, aber pushen sie nicht in das Remote-Repository, was zu unvollständigen Einreichungen führt. Dies zeigt, dass die Agenten implizit annehmen, dass "Code schreiben = Aufgabe erledigt" und die Anforderung ignorieren, dass der Fortschritt durch die