Alle AI-Systeme, die Bewertungen manipulieren, scheiterten. Meta und Stanford führten eine extrem schwierige Testung durch, und GPT, Claude und Gemini erzielten alle Null Punkte.

Hier ist eine Anwendungsdokumentation für FFmpeg und eine kompilierte ausführbare Datei.

Jetzt schreiben Sie das gesamte Programm von Grund auf neu.

Dies ist die Aufgabe, die ProgramBench an die weltweit besten KI-Systeme stellt.

Es wurde erst gestern veröffentlicht und stammt von der gleichen Gruppe wie SWE-Bench, die von Meta, Stanford und Harvard gemeinsam entwickelt wurde.

200 Softwareprojekte. 9 Spitzenmodelle. Durchfallrate: 0%!

Mitautor John Yang, Doktorand an der Stanford University und Gründer von SWE-Bench und SWE-agent

Es geht nicht um das Beheben von Fehlern, sondern um das Erstellen von Software von Grund auf

In den letzten 12 Monaten wurden immer mehr Berichte über Fälle veröffentlicht, in denen KI-Agenten Software von Grund auf entwickelt haben.

Anthropic hat mit einer Gruppe paralleler Claude-Instanzen einen C-Compiler geschrieben. Cursor hat in einem Blogbeitrag über langfristiges autonomes Programmieren berichtet. Epoch AI's MirrorCode macht ähnliches.

Aber all diesen Fällen liegt ein gemeinsames Problem zugrunde: Jeder Test behandelt nur wenige Projekte, und die Gerüste werden manuell optimiert.

Im Vergleich dazu hat ProgramBench diesen Prozess formalisier.

200 Aufgaben, einheitliche Gerüste, systematische Anti-Spoofing-Maßnahmen und alle an die Standards eines Benchmarks angepasst.

Link zur Studie: https://programbench.com/static/paper.pdf

Bei den früheren Tests von SWE-Bench bekamen Sie eine vorhandene Codebasis und wurden darüber informiert, wo es Fehler gibt oder welche Funktionen hinzugefügt werden müssen. Im Wesentlichen handelte es sich um "Textverständnis + lokale Operation".

Bei der Bewertung wurden Einheitstests verwendet, um zu überprüfen, ob die interne Implementierung Ihres Codes korrekt ist. Ihre Funktionssignaturen und Variablennamen müssen mit den Erwartungen übereinstimmen.

ProgramBench geht dagegen genau anders vor.

Es gibt Ihnen nur zwei Dinge: eine kompilierte ausführbare Datei und die Anwendungsdokumentation.

Ihre Aufgabe ist es, nur anhand des Ausführens des Programms und der Beobachtung seines Eingabe-Ausgabe-Verhaltens einen Code zu schreiben, der dasselbe Verhalten reproduziert.

Welche Programmiersprache Sie verwenden, welche Datenstrukturen Sie wählen und wie Sie die Module aufteilen, entscheiden Sie selbst.

Es gibt keine Codegerüste, keine Funktionssignaturen und keine Hinweise.

Bei der Bewertung hat das Forschungsteam Agent-gesteuerte Fuzz-Tests durchgeführt und insgesamt 248.853 Verhaltens-Tests für 200 Aufgaben generiert.

Wenn Ihr Programm ausgeführt wird und die Eingabe-Ausgabe mit der Originalversion übereinstimmt, besteht der Test. Andernfalls besteht er nicht. Die Tests werden dem Modell nie preisgegeben.

Im Gegensatz zu den Einheitstests von SWE-Bench interessieren die Verhaltens-Tests von ProgramBench nicht, wie der interne Code aussieht, solange das Verhalten übereinstimmt.

Die 200 Aufgaben umfassen Projekte aus den Bereichen Komprimierungstools (zstd, lz4, brotli), Sprachinterpreter (PHP, Lua, tinycc), Datenbanken (DuckDB, SQLite), Medienverarbeitung (FFmpeg) und Entwicklungstools (ripgrep, fzf, jq).

Die mittlere Anzahl der Codezeilen beträgt 8.635. Das größte Projekt, FFmpeg, hat 2,7 Millionen Zeilen.

Zusammenfassend gesagt misst dieser Test, ob eine KI in der Lage ist, "wie ein menschlicher Ingenieur zu denken und Software zu entwerfen", und nicht nur "in vorhandenem Code den zu ändernden Bereich zu finden und ihn korrekt zu ändern".

Neun Modelle stehen in einer Reihe, alle haben durchgefallen

Insgesamt 9 Modelle haben an den Tests teilgenommen, darunter die drei großen Familien Claude, Gemini und GPT.

Die vollständige Durchfallrate (alle Tests bestanden) beträgt für alle Modelle 0%.

Schauen wir uns zunächst den direkten Vergleich der drei Flaggschiffen an.

Die durchschnittliche Testdurchfallrate von GPT - 5.4 und Gemini 3.1 Pro ist fast gleich, nämlich 38,3% und 36,6%. Aber ihre Vorgehensweisen beim Lösen der Aufgaben sind völlig unterschiedlich.

GPT - 5.4 verwendet nur 16 API - Aufrufe und kostet 0,33 US - Dollar. Es schreibt im Wesentlichen den gesamten Code in einem Zug und ändert ihn danach kaum noch. 100% des Codes werden in einer Bearbeitung generiert.

Gemini 3.1 Pro ist das am meisten "beobachtende" Modell unter den neun. Es verwendet 94 API - Aufrufe, von denen 34,1% darin bestehen, das Originalprogramm auszuführen und das Eingabe - Ausgabe - Verhalten zu beobachten. Es macht die meisten Untersuchungen, aber das Endergebnis ist nicht viel besser.

Der echte Unterschied macht Claude Opus 4.7.

Die durchschnittliche Durchfallrate beträgt 51,2%. Bei 3% der Aufgaben hat es über 95% der Tests bestanden. Es ist das einzige Modell, das das Kriterium "fast bestanden" erreicht hat. Aber selbst dieses Modell hat keine volle Punktzahl bei einer Aufgabe erreicht.

Insgesamt zeigt sich eine klare Staffelung der neun Modelle.

Die drei Flaggschiffe der Claude - Familie (Opus 4.7, Opus 4.6, Sonnet 4.6) sind führend. GPT - 5.4 und Gemini 3.1 Pro bilden die zweite Staffel. Die übrigen vier kleineren Modelle haben eine Durchfallrate von weniger als 35%.

Eine andere überraschende Entdeckung ist, dass Geld und Zeit nicht unbedingt bessere Ergebnisse bringen.

Sonnet 4.6 führt durchschnittlich 868 Befehle pro Aufgabe aus und kostet 27,09 US - Dollar. Der längste Ablauf hat fast 2.000 Schritte. Aber seine Ergebnisse sind schlechter als die von Opus 4.7, das nur 93 Aufrufe verwendet und 3,81 US - Dollar kostet.

Was noch wichtiger ist: In 98% der Fälle hat das Modell selbst entschieden, dass es "fertig" ist und hat die Aufgabe abgeschlossen, ohne die Zeit - oder Schrittgrenze zu erreichen.

Es ist nicht, dass die Zeit für die Prüfung zu kurz war. Es ist einfach nicht möglich.

Außerdem stimmt die Schwierigkeit der Aufgaben mit der Rangfolge der Modelle überein.

Bei einfachen CLI - Tools (nnn, fzf, gron) bekommen alle Modelle gute Ergebnisse. Komplexe Systeme (FFmpeg, PHP, typst, ast - grep) sind für alle Modelle gleichermaßen schwierig.

Es sei angemerkt, dass ProgramBench das minimale Gerüst mini - SWE - agent verwendet, ohne Kontextkompression, ohne Multi - Agent - Kollaboration und ohne maßgeschneiderte Toolketten.

Der Code ist geschrieben, aber er sieht nicht wie menschlicher Code aus

Das Forschungsteam hat die Lösungen, die über 75% der Tests bestanden haben, mit dem menschlichen Originalcode verglichen und einige erstaunliche Unterschiede festgestellt.

Einzeldatei - Monster.

Der menschliche Code ist im Median auf 15 Dateien verteilt, während es bei den Modellen nur 3 Dateien sind.

60% der Lösungen haben nur 1 bis 3 Code - Dateien.

Menschliche Ingenieure teilen den Code nach Funktionen auf, während die Modelle tendieren, alles in eine einzige große Datei zu packen. Die mittlere Verzeichnistiefe beträgt bei Menschen 2 Ebenen, bei den Modellen 1 Ebene.

Wenige und lange Funktionen.

Opus 4.7 schreibt nur 29% der Anzahl der Funktionen im Vergleich zu Menschen. Sonnet 4.6 schreibt 24%, und GPT - 5.4 nur 10%.

Aber die durchschnittliche Länge jeder Funktion ist länger. Die Funktionen, die Gemini 3.1 Pro schreibt, sind 62% länger als die von Menschen.

Der Code ist deutlich kürzer.

Der Median der Codezeilen bei den Modellen beträgt 1.173, während es bei Menschen 3.068 Zeilen sind. 85% der Lösungen mit hoher Punktzahl sind kürzer als das Original.

Zusammenfassend gesagt können die heutigen KIs Code schreiben, aber keine Software entwerfen.

Sie verstehen nicht, warum man Module aufteilen sollte, und warum menschliche Ingenieure Zeit darauf verwenden, Schnittstellen und Abstraktionsschichten zu definieren. Ihre Strategie besteht darin, alle Logiken in möglichst wenige Dateien und Funktionen zu packen, solange es funktioniert.

Die Leistung von GPT - 5.4 ist am extremsten. Durchschnittlich erstellt es pro Aufgabe nur 5 Dateien und ändert sie 1,2 Mal. 39,5% der Abläufe ändern die Dateien nach der Erstellung gar nicht.

Im Vergleich dazu erstellt Claude Sonnet 4.6 durchschnittlich 11,3 Dateien und ändert sie 18,3 Mal. Dies zeigt ein Iterationsentwicklungsmuster, das näher an dem von Menschen liegt.

Es gibt noch ein sehr interessantes Phänomen.

Die Modelle wählen in nur 50% der Fälle dieselbe Programmiersprache wie das Original.

Python ist die Lieblingssprache der Modelle und wird in 36% aller 1.800 Ausführungen verwendet.

Von den Projekten, die ursprünglich in Rust geschrieben wurden, werden nur 44% in Rust neu geschrieben. Bei C/C++ ist es 46%. Die "Loyalität" bei Go - Projekten ist am höchsten mit 70%.

Egal, in welcher Sprache das Original geschrieben ist, in einem Drittel der Fälle wird das Projekt von den Modellen in Python neu geschrieben.

Kein Spoofing zugelassen, aber beim Verbinden mit dem Internet wird direkt von GitHub Quellcode kopiert

Dies ist vielleicht der dramatischste Teil der gesamten Studie.