Menschlicher Code aus 2020 besiegt Vibe-Coded-Agents in Agentic-Tests

ChatGPT und andere Vibe-Coding-Tools wurden in fast 40.000 Matches getestet – und verloren gegen Code, der von Studenten vor der Erfindung von Large Language Models geschrieben wurde.

In einer neuen Studie aus dem Vereinigten Königreich setzten Forscher human-kodierte Agenten gegen vibe-kodierte Agenten ein, die mit den neuesten Large Language Models (LLMs) wie ChatGPT-5 und Claude entwickelt wurden, und fanden heraus, dass die ohne die Hilfe von KI erstellten Agenten die KI-gestützten Versionen leicht schlugen.

Beide Agentengruppen wurden von verschiedenen Generationen von Studenten des Artificial Intelligence Laboratory am Swiss Federal Technology Institute of Lausanne erstellt. Die nicht-KI-Agenten wurden als Teil eines Kurses im Jahr 2020 entwickelt, zwei Jahre vor der Erfindung von ChatGPT und dem Beginn der LLM-Revolution, während die neuen Agenten von aktuellen Studenten mit den neuesten und besten LLMs erstellt wurden.

Even mit einem manipulierten Spiel konnten die vibe-kodierten Lösungen nicht gewinnen, und die Top-5-Plätze wurden konstant von “rohen” Agenten gehalten, und die Mehrheit der LLM-Agenten (33 von 40) wurde mühelos von “sehr einfachen” Baseline-Agenten besiegt, über 38.304 Herausforderungen in einem Turnier, über eine Vielzahl von Variablen und Umständen.

Das Papier besagt:

‘Unsere Arbeit zeigt, dass zwar state-of-the-art-LLMs Code generieren können, der läuft (d. h. frei von Syntaxfehlern), die generierte Lösung aber nicht wettbewerbsfähig ist mit human-designten Lösungen in Dimensionen wie strategischer Planung, Optimierung oder Multi-Agenten-Wettbewerb.

‘Somit bringt diese Arbeit eine neue Grenze in der Code-Generierung in den Vordergrund und zielt darauf ab, die Entwicklung von Benchmarks, Datenbanken und Open-Source-Baselines zu erleichtern, die reasoning-getriebene Code-Synthese betonen.’

Die Herausforderung, die die Autoren entwarfen, bestand darin, kreativ an Auktionen teilzunehmen, über eine Vielzahl von Strategien und die Logistik der Lieferung von gewonnenen Artikeln an die Gewinner zu organisieren.

Die Autoren bemerken, dass den LLMs eine Reihe von Vorteilen gegeben wurden, wie z. B. die Intervention in ihren Code, um ihre Leistung zu verbessern – ein Vorteil, der den 2020er-Code nicht erlaubt war. Trotzdem konnten die LLMs, selbst wenn sie mit korrigiertem Code versorgt wurden, der ihre Ergebnisse definitiv verbessern würde, diesen nicht annehmen oder verwenden:

‘[In] unserem Benchmark ist der LLM auch dann nicht in der Lage, eine gute Lösung zu nutzen, wenn wir sie in Kontext setzen.

‘Dieses Ergebnis wirft auch interessante Fragen über die Grenzen des in-Kontext-Lernens und der retrieval-augmentierten Problemlösung in komplexen Szenarien auf.’

Die in der Studie verwendeten LLMs waren GPT-5 Thinking, Gemini 2.5 Pro, Claude Opus 4.1 und DeepSeek R1*.

Das neue Papier trägt den Titel Can Vibe Coding Beat Graduate CS Students? An LLM vs. Human Coding Tournament on Market-driven Strategic Planning und stammt von einem Autor der University of Southampton und einem Autor der University of Oxford und Alan Turing Institute. Der Benchmark wird, so die Autoren, in Kürze veröffentlicht.

Methode

Die Autoren bemerken, dass traditionelle Tests in diesem Bereich sich auf Herausforderungen mit klar definierten binären Lösungen (korrekt oder nikt korrekt) konzentrieren, die durch Unit-Tests überprüft werden. Sie argumentieren, dass dies nicht der ideale Weg ist, um die Grenzen von LLM-gestütztem Code zu erforschen, und stattdessen eine komplexere Herausforderungssituation mit mehreren internen Benchmarks und Meilensteinen entwickelten, in der der Sieg möglich ist, aber weit von einfach:

Vergleich von Standard-, unit-test-basierten Ansätzen (oben), und der von den Autoren entwickelten Herausforderungssituation (in Blau, unten). Quelle

Die Auktion, Abholung und Lieferproblematik (APDP) wurde für die Studie der Autoren verwendet und teilweise selbst ausgewählt, weil eine Korpus von 2020er-Studentenarbeit der Schweizer Universität verfügbar war; Arbeit, die darauf abzielte, automatisierte Agenten für die APDP-Aufgabe zu erstellen, bevor die Möglichkeit bestand, die Entwicklung durch KI zu unterstützen. Es war daher relativ einfach, moderne Studenten mit der gleichen Aufgabe zu betrauen, aber mit aktuellen Tools auszustatten.

Die Autoren suchten, populäre Testframeworks wie HumanEval, BigCodeBench und WebDev Arena (unter vielen anderen) zu vermeiden, da diese Klasse von Testverfahren oft unter Datenkontamination leidet (d. h., Instanzen, in denen das System möglicherweise auf Testdaten trainiert wurde, anstatt einen Split zu respektieren).

Die APDP ist ein zweistufiges Logistikproblem, das auf Reverse-Auktionen und Fahrzeugrouting basiert. In der ersten Stufe konkurrieren die Agenten, um Lieferaufträge zu gewinnen, indem sie Gebote für die Bezahlung jedes Auftrags abgeben. Zu hohe Gebote bedeuten den Verlust des Auftrags; zu niedrige Gebote können zu Verlusten führen.

In der zweiten Stufe muss jeder Agent einen effizienten Plan erstellen, um nur die Aufträge zu erfüllen, die er gewonnen hat, indem er sie Fahrzeugen mit unterschiedlichen Kapazitäten und Kosten zuweist, unter Zeit- und Ressourcenbeschränkungen:

In der APDP bieten Unternehmen in Reverse-Auktionen für Lieferaufträge, dann optimieren sie Fahrzeugrouten, um nur die Aufträge zu erfüllen, die sie gewonnen haben, mit dem Ziel, den Gewinn zu maximieren.

Das Ziel ist nicht nur, die Aufträge zu erfüllen, sondern den Gesamtgewinn zu maximieren, indem man vorhersieht, welche Bündel von Aufträgen am besten zusammenpassen, und die Strategien der Konkurrenten vorhersieht, die alle versuchen, das Gleiche zu tun.

Die APDP-Herausforderung erhöht die Schwierigkeit von Code-Generierungsaufgaben, indem sie strategische Planung über eine Folge von interdependenten Auktionen einführt, bei denen jedes Gebot die Landschaft zukünftiger Entscheidungen neu gestaltet; und daher erfordert sie, dass die Agenten nicht nur über unmittelbare Kosten nachdenken, sondern über Positionierung, Timing und langfristige Konsequenzen.

Das Kernlieferproblem ist NP-hard, d. h., kein Algorithmus kann zuverlässig die beste Lösung in vernünftiger Zeit finden, wenn die Anzahl der Aufträge wächst. Dies macht die brute-force-Methode unpraktikabel und zwingt die Agenten, Präzision gegen Geschwindigkeit zu tauschen.

Der Wettbewerb ist eröffnet

Die Autoren verglichen 40 LLM-kodierte Agenten mit 17 human-kodierten Agenten in einer Reihe von Kopf-an-Kopf-Turnieren. Jedes der 12 Turniere verwendete eine andere Kombination von vier Straßennetz-Topologien und bestand aus all-play-all-Paarungen, wobei die Agenten jeden anderen Gegner zweimal trafen: einmal als Kontrolleur von zwei Unternehmen, mit unterschiedlichen Fahrzeugspezifikationen.

Diese Aufstellung ergab 3.192 Matches pro Turnier, insgesamt 38.304 Matches. In jedem Match wurden 50 Lieferaufträge versteigert, definiert durch ihre Abhol- und Lieferpunkte und Gewicht, und zufällig über Straßenlayouts verteilt, die auf der Schweiz, Frankreich, Großbritannien und den Niederlanden basierten:

Vereinfachte Straßennetze, die im Turnier verwendet wurden: Großbritannien (oben links), Schweiz (oben rechts), Niederlande (unten links) und Frankreich (unten rechts). Blaue und rote Quadrate markieren Abhol- und Lieferaufträge. Farbige Dreiecke zeigen die aktuellen Positionen der Fahrzeuge der Agenten.

Studentenagenten wurden aus einem Turnier von 2020 ausgewählt. Acht kamen aus den Top-Performern in einem Einzel-Eliminationsfinale, und vier weitere wurden für ihre starke Leistung gegen die Baseline-Agents in Kopf-an-Kopf-Matches ausgewählt.

Die Baseline-Agents folgten festen Heuristiken. Naive berechnete die Gesamtentfernung und bot entsprechend, unter Verwendung nur eines Fahrzeugs und Ignorierung von Batching; ExpCostFixedBid simulierte 10 zufällige Aufträge und bot den durchschnittlichen marginales Kosten; Honest berechnete die tatsächlichen marginales Kosten des Einfügens des Auftrags in den Zeitplan; ModelOpponent tat dasselbe, aber fügte eine Schätzung der Kosten des Gegners hinzu, indem er das Maximum bot; und RiskSeeking kombinierte eine zeitlich abnehmende Priorität mit Live-Kosten-Schätzung und Gegner-Modellierung – wiederum das Höhere der beiden bietend.

Die Bewertung umfasste 40 LLM-kodierte Agenten, die mit den (oben genannten) GPT-5 Thinking, Claude Opus 4.1, Gemini 2.5 Pro und DeepSeek R1 erstellt wurden. Jedes Modell wurde mit fünf unterschiedlichen Strategien aufgefordert, zweimal pro Modell.

Zwei Strategien verwendeten statische Prompts, die von verschiedenen Autoren geschrieben wurden, während eine dritte den Modell aufforderte, sich selbst zu reflektieren und seine eigene Ausgabe zu überarbeiten; eine weitere beinhaltete Kritik und Überarbeitung durch ein separates LLM. Die letzte Strategie verwendete GPT-4, um einen neuen Prompt zu synthetisieren, indem alle vier vorherigen Ansätze überprüft wurden.

Der Basis-Prompt spiegelte die ursprüngliche Studentenaufgabe wider, indem er die Lieferumgebung beschrieb und den Modell aufforderte, zu bieten und zu planen, um den Gewinn zu maximieren, ohne auf komplexe Methoden zurückzugreifen.

Alle LLM-Agents wurden in Selbstspiel- und Turniersituationen getestet, bis alle beobachtbaren Fehler behoben waren. Fehlerbehebung wurde autonom von den LLMs selbst gehandhabt, indem sie mit Fehlerinformationen aufgefordert wurden.

Häufige LLM-Fehler, so das Papier, umfassten Verstöße gegen Zeitlimits, das Versäumnis, zugewiesene Aufträge abzuholen oder zu liefern, und Verstöße gegen Fahrzeugkapazitätsbeschränkungen – Fehler, die oft durch Missachtung expliziter Anweisungen oder fehlerhafte Neuplanung entstanden:

‘Ein weiteres häufiges Problem, das wir festgestellt haben (hauptsächlich mit Gemini, Claude und DeepSeek, und nicht so sehr mit GPT), ist, dass der LLM oft konsequent nicht in der Lage war, einen Fehler zu beheben.

‘Zum Beispiel würde ein Agent konsequent Zeitüberschreitungen haben, trotz mehrerer (z. B. 5 − 15) Zyklen, in denen der LLM mit dem Fehler aufgefordert und die aktualisierte Version des Codes erhalten wurde.

‘Die einzige Lösung, die wir für solche Situationen (in denen der LLM wiederholt nicht in der Lage ist, den gleichen Fehler zu beheben) gefunden haben, ist, von vorne zu beginnen. Insgesamt haben wir festgestellt, dass ein signifikanter manueller Aufwand erforderlich ist, um fehlerfreien Code zu erreichen. Wir mussten wesentlich mehr Agenten generieren, um die 40 fehlerfreien zu erhalten, die wir ausgewertet haben.’

Die Ergebnisse, die unten zusammengefasst sind, umfassen Ergebnisse aus 12 Doppel-Rundenturnieren, die vier Netzwerktopologien und drei Turniere pro Topologie umfassten, mit insgesamt fast 40.000 Matches:

Um den Kontext zu verstehen, spielte jeder Agent 112 Matches pro Turnier, so dass der maximale mögliche Durchschnitt für Siege oder Niederlagen pro Agent 112 beträgt. Die Standardabweichung (SD) spiegelt die Variabilität über Turniere hinweg wider. Human-kodierte Agenten sind in Fettdruck dargestellt. LLM-kodierte Agenten sind durch Modell (O = GPT-5 Thinking, G = Gemini 2.5 Pro, A = Claude Opus 4.1, D = DeepSeek R1) gekennzeichnet, gefolgt von einem zweibuchstabigen Prompt-Strategie-Code und einer Ziffer, die angibt, ob der Agent der erste oder zweite mit diesem Prompt ist. Quelle

In Bezug auf die oben gezeigten Ergebnisse bemerken die Autoren^†:

‘LLMs generierten keinen erwarteten/wettbewerbsfähigen Code, sogar in einfacheren Varianten des APDP-Problems (trotz des Codes, der größtenteils frei von Syntaxfehlern war). Dies unterstreicht die Bedeutung von reasoning-getriebenen Code-Bewertungsbenchmarks, die über Auto-Vervollständigung hinausgehen und neue Schwächen von LLMs identifizieren.’

‘Unsere Ergebnisse zeigen eine klare Überlegenheit von human-kodierten Agenten: (i) Die Top-5-Plätze werden konstant von Studenten-Agents gehalten, und (ii) die Mehrheit der LLM-Agents (33 von 40) wird von sehr einfachen Baseline-Agents besiegt (wie dem erwarteten Kosten-Festpreis).

‘Wichtig ist, dass wir den Studenten-Code nicht debuggt haben (während wir den LLM-Code gründlich getestet und debuggt haben, sowohl in Selbstspiel- als auch in Turniersituationen). Jedes Mal, wenn ein Studenten-Agent abstürzte, gaben wir automatisch den Sieg an den LLM. Eine große Anzahl dieser Abstürze wäre leicht zu beheben (z. B. Agenten, die Zeitüberschreitungen hatten), so dass die Studenten-Agents möglicherweise höher einstufen könnten.’

Als weiteres Experiment wurde GPT-5 Thinking aufgefordert, den Code des besten human-kodierten Agenten, Student 1, zu verbessern; aber der nun LLM-modifizierte Agent fiel auf den zehnten Platz zurück, nun der schlechteste aller human-kodierten Ergebnisse. Anstatt die Lösung zu verbessern, verschlechterten die LLMs sie um fast 20%.

Die Autoren schlussfolgern:

‘[Unsere] Ergebnisse heben wichtige Grenzen der LLM-Code-Generierung hervor, insbesondere ihre begrenzten Fähigkeiten zur Planung und zum Denken bei der Code-Generierung. Moderne LLMs können syntax-fehlerfreien Code liefern, der läuft, aber das ist nicht der Benchmark, den wir verwenden sollten, um den Fortschritt hin zu fortgeschrittener allgemeiner KI zu messen.’

Schlussfolgerung

Die Autoren selbst bemerken gegen Ende des Papiers, dass Vibe-Coding Menschen aller technischen Hintergründe befähigt hat und beschreiben die Praxis in einem positiven Licht, als eine ausgleichende Kraft. Sie implizieren jedoch auch, dass Vibe-Coding erst kürzlich aufgetaucht ist und seine Grenzen noch nicht bekannt sind und möglicherweise höher sind, als man realistisch erwarten kann.

Sie schließen ihr Angebot mit einem Aufruf zu einem Zielwechsel ab: ‘von Code, der compiliert, zu Code, der konkurriert‘.

Eine Frage, die der interessierte Leser dieses neuen Papiers haben könnte, ist, ob die Autoren nach oben oder unten schlagen, da die agente Aufgabe in Frage wesentlich komplexer und involvierter ist als das Ausstoßen von PowerShell-Skripten und anderen Formen von geringer Funktionalität und Korrekturen, für die Vibe-Coding gut geeignet ist.

* Bitte beachten Sie, dass das Papier kontinuierlich auf ‘DeepThink R1′ verweist, was nicht existiert, und nur eine Handvoll von Referenzen im Internet aufweist (vermutlich von anderen Autoren, die ‘DeepSeek R1’ falsch geschrieben haben). Wenn dies mein Fehler ist, bitte kontaktieren Sie mich über meine Profildaten, und ich werde es korrigieren.

^† Autoren-Betonung, nicht meine.

Erstveröffentlicht am Mittwoch, den 26. November 2025. Geändert am 17:35 Uhr (östliche Zeit) für die Formatierung.