0% Fertigstellungsrate, Claude, GPT und Gemini alle ausgeschieden. Das neue Werk des Autors von SWE-Bench hat die Künstliche-Intelligenz-Szene in Schweigen versetzt.

Die Schöpfer von SWE-Bench haben gerade einen neuen, extrem schwierigen Benchmark herausgebracht.

Das Ergebnis ist ziemlich erschütternd:

Claude Opus 4.7, GPT-5.4, GPT-5 mini, Gemini 3.1 Pro, Gemini 3 Flash – fast alle der stärksten Top-Modelle dieser Generation haben eine Vollzugsrate von 0%.

Kein Modell kann ein Softwareprojekt wirklich vollständig neu aufbauen.

Was bedeutet das?

Die heutigen Large Language Models können schon recht gut Code schreiben, aber können immer noch keine Software-Engineering betreiben.

Kürzlich hat Meta FAIR in Zusammenarbeit mit Institutionen wie Stanford und Harvard einen sehr interessanten neuen Benchmark veröffentlicht, der im Wesentlichen die Bewertungsweise von AI Coding neu definiert:

ProgramBench: Can Language Models Rebuild Programs From Scratch?

Die meisten früheren Benchmarks für Large Language Models im Bereich Programmierung testeten lokale Fähigkeiten: Funktionserstellung, Bugbehebung, Implementierung von Features … Im Wesentlichen handelte es sich immer noch um lokale Änderungen an bestehendem Code.

ProgramBench bringt das Problem erstmals auf die Ebene des echten Software-Engineering: Wenn man einem AI nur die Funktionsbeschreibung und die Nutzungsdokumentation eines Programms gibt, kann es dann wie ein echter Ingenieur von Grund auf einen realen, ausführbaren Software-System aufbauen? Zum Beispiel ffmpeg, SQLite, ripgrep.

Und – es darf keine Internetverbindung hergestellt werden.

Mit anderen Worten: Hat das Modell überhaupt Ingenieurintelligenz?

Um dies zu testen, hat das Forschungsteam den ursprünglichen Quellcode und die Tests einfach gelöscht und nur das ausführbare Programm und die Nutzungsdokumentation behalten. Das Modell muss dann selbst die Programmiersprache, die Architektur, die Modulaufteilung, die Datenstruktur und sogar die Organisation des gesamten Repositories entscheiden.

Das Wichtigste ist, dass ProgramBench nicht mehr nach der Ähnlichkeit des Quellcodes bewertet. Es verwendet die Verhaltensäquivalenz (behavioral equivalence). Das bedeutet, dass man völlig unterschiedliche Sprachen, Algorithmen, Architekturen und sogar völlig unterschiedliche Implementierungen verwenden kann. Solange das endgültige Ein- und Ausgabeverhalten mit dem des ursprünglichen Programms übereinstimmt, gilt es als bestanden.

Das Forschungsteam hat sogar agentengetriebenes Fuzzing eingesetzt, um automatisch eine Vielzahl von End-to-End-Verhaltens-Tests zu generieren.

Zum ersten Mal nähert sich ein Benchmark wirklich dem Software-Engineering in der realen Welt an, anstatt nur Code-Aufgaben zu stellen. Nachdem die Ergebnisse herausgekommen sind, hat sich der gesamte AI-Bereich geschwiegen.

Alle Modelle: 0% Vollzugsrate.

Während Tabelle 2 für die Schockwirkung sorgt, erklärt Abbildung 4 die Details hinter der Schockwirkung. Sie zeigt uns, dass die Modelle nicht komplett unfähig sind, sondern oft einen Teil der Aufgabe erledigen können und sich in einigen wenigen Fällen sogar annähern können. Aber sobald 100%ige Verhaltensäquivalenz gefordert wird, scheitern alle Modelle. Diese letzte Meile ist genau der größte Unterschied zwischen Software-Engineering und normaler Codegenerierung. Übrigens, wenn man das beste aus den schlechten sucht, schneiden die Claude-Serien (insbesondere Opus 4.7 und 4.6) relativ am besten ab.

Selbst wenn die Studie einen zusätzlichen Almost-Indikator einfügt – der die Aufgaben misst, bei denen die Vollzugsrate über 95% liegt – hat das derzeit stärkste Modell, Claude Opus 4.7, nur 3% der Aufgaben fast abgeschlossen.

In der Studie gibt es einen besonders wichtigen Satz:

Models favor monolithic, single-file implementations that diverge sharply from human-written code.

Übersetzt heißt das: Die Modelle neigen stark dazu, monolithischen Code zu generieren. Viele Logiken werden in eine einzelne Datei gepackt; die Verzeichnisstruktur ist sehr flach; es gibt nur wenige Modulaufteilungen; die Funktionen sind sehr lang; das gesamte Repository sieht aus wie ein riesiger Skriptblock.

Dies ist fast das Gegenteil der Gewohnheiten guter menschlicher Ingenieure.

Letztere achten darauf, Module und Interessen zu trennen und teilen den Code elegant auf – die Konfiguration wird in config.json gespeichert, Hilfsfunktionen in utils.py, Datenbankoperationen in db.py, und dann werden sie über import aufgerufen.

Dies zeigt eigentlich ein sehr zentrales Problem auf: AI ist gut darin, lokalen Code zu generieren, aber schlecht darin, globale Systemplanung durchzuführen. Das echte Software-Engineering besteht jedoch im Wesentlichen aus letzterem.

Deshalb sind die Modelle in Szenarien wie LeetCode, SWE-Bench und Copilot bereits sehr stark, aber sobald sie in reale, große Engineering-Systeme eintreten, geraten sie schnell in Schwierigkeiten.

Der eigentliche Engpass des heutigen AI Coding liegt nicht mehr in der Codegenerierungsfähigkeit, sondern in der langfristigen Fähigkeit, Software-Systeme aufzubauen.

Ein weiteres interessantes Ergebnis ist der Leistungsunterschied zwischen verschiedenen Programmiersprachen.

Das Forschungsteam hat die Leistung der Modelle bei Projekten in verschiedenen Sprachen wie C/C++, Go, Rust usw. separat erfasst. Man kann deutlich sehen, dass die Vollzugsrate bei traditionellen C/C++-Projekten am höchsten ist, während Rust am schlechtesten abschneidet.

Die Reihenfolge der Modelle in Bezug auf die Schwierigkeit der Aufgaben stimmt sehr überein: Bei relativ einfachen CLI-Tools wie nnn, fzf, gron erreichen die Modelle im Allgemeinen eine höhere Passrate. Aber bei komplexen Systemen wie FFmpeg, php-src, typst, ast-grep haben fast alle Modelle Schwierigkeiten, voranzukommen. Dies zeigt, dass ProgramBench nicht nur einen zufälligen Fehler eines Modells misst, sondern dass komplexe Software-Systeme die aktuellen Modelle stabil unterdrücken.

Dies ist eigentlich nicht überraschend.

Im Internet gibt es so viele historische Codes, Engineering-Praktiken und Stack Overflow-Inhalte über C/C++, dass die Modelle jahrelang von diesen Mustern geprägt wurden.

Das Engineering-Philosophie von Rust legt stärkeren Wert auf Modularität, Ownership, Trait-System und langfristige Wartbarkeit, und das sind genau die Dinge, in denen die aktuellen Modelle am schlechtesten sind.

In gewissem Sinne misst Rust nicht die Codefähigkeit, sondern die Engineering-Fähigkeit.

Mit der Aufregung, die ProgramBench ausgelöst hat, haben sich auch die Debatten um diesen Benchmark schnell verbreitet. Eine der Hauptkritiken ist: Testet man hier nicht einfach, ob das Modell FFmpeg auswendig gelernt hat? After all, many projects in ProgramBench are public open-source software.

Dafür hat der bekannte Silicon Valley-Anleger Deedy Das speziell einen Artikel veröffentlicht und geantwortet: Jeder Benchmark kann überangepasst werden (overfit).

Man kann die Bugs in SWE-Bench auswendig lernen, die Aufgaben in LeetCode auswendig lernen, und selbst ARC-AGI könnte in Zukunft möglicherweise versteckte Aufgabenbanken verwenden, um Lecks zu vermeiden. Die bloße Diskussion darüber, ob es eine Memorisation gibt oder nicht, kann den Wert des Benchmarks nicht negieren.

Er meint: Wenn ein Modell versucht, diese Programme mit brute-force-Methoden auswendig zu lernen, wird es in anderen Bereichen deutlich an Leistung verlieren.

Denken Sie daran, dass das Training eines echten Large Language Models nicht einfach darin besteht, das gesamte FFmpeg in die Parameter einzubauen. Darüber hinaus können die Forscher auch die Ähnlichkeit zwischen dem generierten Code und dem ursprünglichen Quellcode vergleichen, um zu überprüfen, ob es eine direkte Memorisation gibt.

Was er wirklich betonen möchte, ist, dass das Neuerstellen eines realen Software-Systems von Grund auf eine komplexe Aufgabe mit hohem Nutzen und langer Zeitspanne ist. Wenn ein Modell tatsächlich in der Lage ist, solche Aufgaben zu lösen, wird diese Fähigkeit wahrscheinlich auf viele andere Engineering-Szenarien übertragbar sein.

Eine andere interessante Debatte betrifft die Frage: Selbst Menschen können FFmpeg nicht von Grund auf neu schreiben. Dieser Benchmark ist also überhaupt nicht vernünftig.

Deedy Das antwortet: So what? Viele Dinge, die heutige Large Language Models können, können auch Menschen im Durchschnitt nicht.

Das Ziel eines Benchmarks ist es nie, die durchschnittliche Fähigkeit eines Durchschnittsmenschen zu simulieren, sondern das Modell zu höherer Intelligenz anzuregen. Dass Menschen etwas nicht können, bedeutet nicht, dass der Benchmark wertlos ist.

Zum Beispiel hat AlphaGo das Schachspiel von den meisten Menschen übertroffen, und das hat die Entwicklung von AI vorangetrieben. Ebenso könnte ein Benchmark, der weit über die Fähigkeiten eines normalen Ingenieurs hinausgeht, ein Problem sein, das zukünftige Agentensysteme bewältigen müssen.

Natürlich gibt es auch einige Mängel bei ProgramBench. Beispielsweise werden derzeit nicht komplette Agent-Harness wie Claude Code und Codex getestet; es wird nur gemessen, ob die Aufgabe abgeschlossen ist, ohne die Fortschritte feiner zu bewerten.

Zusätzlich wird die Internetverbindung eingeschränkt, um offensichtliche Betrugsversuche zu vermeiden.

Deedy Das stimmt zu, dass dies dazu führen könnte, dass die Modelle in die falsche Richtung gehen, um in bestimmten Indikatoren besser abzuschneiden (Hill-climbing on the wrong thing). Aber man kann jederzeit einen Leistungstest mit Internetzugang hinzufügen, um einen Vergleich anzustellen.

Einige Leute schlagen vor: Warum verwendet man nicht wirklich neue Probleme, die noch niemand gelöst hat? Deedy Das antwortet, dass es dann fast unmöglich wäre, den Benchmark zu erstellen.

Es ist schwierig, eine vollständige Testsuite für ein Problem ohne richtige Lösung zu entwerfen; und es ist auch schwierig zu entscheiden, ob eine Aufgabe wirklich eine reale Engineering-Aufgabe ist oder ob es sich um eine Herausforderung handelt, die von Forschern erfunden wurde.

Aber all diese Probleme können im Laufe der Entwicklung des Benchmarks korrigiert werden.

Das Wichtigste ist: ProgramBench hat zum ersten Mal die Bewertung von AI Coding von der Funktionsebene auf die Systemebene gehoben. Es zeigt auch die größte Lücke in der gesamten Branche: Das echte Software-Engineering besteht nie darin, eine Funktion zu schreiben, sondern darin, ein wartbares, erweiterbares und kollaboratives Engineering-System zu erstellen.

Heutige Large Language Models können bereits sehr gut lokalen Code generieren. Aber sie fehlt immer noch die Fähigkeit, komplexe Systeme langfristig, konsistent und stabil zu warten.

Deshalb bemerkt man, dass die gesamte Branche derzeit wild an einem anderen Satz von Schlüsselwörtern arbeitet: memory, agents, repo-level reasoning, long-horizon planning, autonomous software engineering.

Because