Humaner Code aus 2020 schlug vibe-codierte Agenten in Agentic-Tests

ChatGPT und andere vibe-codierte 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-codierte Agenten gegen vibe-codierte 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-facilitierten Versionen sehr leicht schlugen.

Beide Agentensätze wurden von verschiedenen Generationen von Studenten des Artificial Intelligence Laboratory am Schweizerischen Bundesinstitut für Technologie in Lausanne erstellt. Die nicht-KI-Agenten wurden im Rahmen von Kursarbeiten im Jahr 2020 entwickelt, zwei Jahre vor der Einführung von ChatGPT und dem Beginn der LLM-Revolution, während die neuen Agenten von aktuellen Studenten mit den neuesten und besten verfügbaren LLMs erstellt wurden.

Selbst bei einem manipulierten Spiel konnten die vibe-codierte Lösungen nicht gewinnen, und die Top-5-Plätze wurden konstant von “rohen” Agenten gehalten, während die Mehrheit der LLM-Agenten (33 von 40) mühelos von “sehr einfachen” Basisagenten in 38.304 Herausforderungen in einem Turnier über eine breite Anzahl von Variablen und Umständen besiegt wurden.

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 jedoch nicht wettbewerbsfähig zu human-designten Lösungen in Dimensionen wie strategische Planung, Optimierung oder Multi-Agenten-Wettbewerb ist.

‘Somit bringt diese Arbeit diese neue Grenze in der Codegenerierung 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 bestand darin, kreativ an Auktionen teilzunehmen, über verschiedene Strategien hinweg, und die Logistik der Lieferung der gewonnenen Artikel an die Gewinner zu organisieren.

Die Autoren bemerken, dass den LLMs eine Reihe von Vorteilen eingeräumt wurden, wie z. B. die Intervention in ihren Code, um ihre Leistung zu verbessern – ein Vorteil, der dem Code aus dem Jahr 2020 nicht zugestanden wurde. Trotzdem konnten die LLMs, selbst wenn ihnen korrigierter Code zur Verfügung gestellt wurde, der ihre Ergebnisse definitiv verbessert hätte, diesen nicht akzeptieren oder nutzen:

‘[In] unserem Benchmark kann das LLM, selbst wenn wir eine gute Lösung im Kontext vorlegen, diese nicht nutzen.

‘Dieses Ergebnis wirft auch interessante Fragen über die Grenzen des in-context-Lernens und des retrieval-augmented Problem-Solvings in komplexen Szenarien auf.’

Die in dem Test 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 an der University of Southampton und einem anderen an der University of Oxford und dem Alan Turing Institute. Der Benchmark wird, so die Autoren, kurzfristig veröffentlicht.

Methode

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

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

Das Auction, Pickup and Delivery Problem (APDP) wurde für die Studie der Autoren verwendet, teilweise weil eine Korpus von 2020-Studentenarbeit von der Schweizer Universität verfügbar war; Arbeit, die darauf abzielte, automatisierte Agenten für die APDP-Aufgabe zu erstellen, bevor es möglich war, die Entwicklung durch KI zu unterstützen. Es war daher relativ einfach, moderne Studenten mit dem gleichen Auftrag zu betrauen, aber ihnen aktuelle Tools zur Verfügung zu stellen.

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

Das APDP ist ein zweistufiges Logistikproblem, das auf Reverse-Auktionen und Vehicle-Routing basiert. In der ersten Phase konkurrieren die Agenten, um Lieferaufträge zu gewinnen, indem sie Gebote für die Bezahlung abgeben, die sie für die Erfüllung jedes Auftrags erhalten sollten. Ein zu hohes Gebot bedeutet den Verlust des Auftrags; ein zu niedriges Gebot kann bedeuten, Geld zu verlieren.

In der zweiten Phase 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:

Im 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 Auftragsbündel am besten zusammenpassen, und die Strategien der Konkurrenten vorhersieht, die alle versuchen, das gleiche zu tun.

Das APDP-Benchmark erhöht die Schwierigkeit von Codegenerierungsaufgaben, indem es strategische Planung über eine Folge von voneinander abhängigen Auktionen einführt, wobei jedes Gebot die Landschaft zukünftiger Entscheidungen neu gestaltet; und erfordert daher, 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 es unmöglich, eine brute-force-Lösung zu verwenden, und zwingt die Agenten, Genauigkeit gegen Geschwindigkeit zu tauschen.

Das Rennen ist eröffnet

Die Bewertung der Autoren verglich 40 LLM-codierte Agenten mit 17 human-codierten 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 Kontrolle über jedes von zwei Unternehmen, mit unterschiedlichen Fahrzeugspezifikationen.

Diese Einrichtung 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 basieren:

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

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

Die Basisagenten folgten festen Heuristiken. Naive berechnete die Gesamtstrecke und bot entsprechend, unter Verwendung nur eines Fahrzeugs und unter Ignorierung von Batching; ExpCostFixedBid simulierte 10 zufällige Aufträge und bot den Durchschnittskosten; Honest berechnete die tatsächlichen Grenzkosten der Einfügung 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 mischte eine time-decaying Priorität mit Live-Kosten-Schätzung und Gegner-Modellierung – wiederum das Höhere der beiden bietend.

Die Bewertung umfasste 40 LLM-codierte Agenten, die mit den (vorher 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 angestoßen, 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 finale Strategie verwendete GPT-4, um einen neuen Prompt zu synthetisieren, indem sie alle vier vorherigen Ansätze überprüfte.

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

Alle LLM-Agenten wurden in Selbstspiel- und Turnierszenarien getestet, bis alle beobachtbaren Fehler behoben waren. Die Fehlerbehebung wurde autonom von den LLMs selbst durchgeführt, die mit Fehlerinformationen angestoßen wurden.

Häufige LLM-Fehler, die im Papier erwähnt werden, umfassten Verstöße gegen Timeout-Limits, das Versäumnis, zugewiesene Aufträge abzuholen oder zu liefern, und Verstöße gegen Fahrzeugkapazitätsbeschränkungen – Fehler, die oft durch die Missachtung expliziter Anweisungen oder durch 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 das LLM häufig nicht in der Lage war, einen Fehler zu beheben.

‘Zum Beispiel würde ein Agent häufig timeouten, trotz mehrerer (z. B. 5 – 15) Zyklen, in denen das LLM mit dem Fehler angestoßen und die aktualisierte Version des Codes erhalten wurde.

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

Die Ergebnisse, die unten dargestellt sind, fassen die Ergebnisse von 12 Doppel-Rundenturnieren zusammen, die vier Straßennetz-Topologien und drei Turniere pro Topologie umfassen, was zu etwa 40.000 Matches führt:

Im Kontext spielte jeder Agent 112 Matches pro Turnier, so dass die maximale mögliche Durchschnittswert für Siege oder Niederlagen pro Agent 112 beträgt. Die Standardabweichung (SD) spiegelt die Variabilität über die Turniere hinweg wider. Human-codierte Agenten sind fett gedruckt. LLM-codierte Agenten sind mit dem 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 nicht den erwarteten/wettbewerbsfähigen Code, sogar in einfacheren Varianten des APDP-Problems (trotzdem der Code größtenteils frei von Syntaxfehlern war). Dies unterstreicht die Wichtigkeit von reasoning-getriebenen Code-Evaluations-Benchmarks, die über Auto-Vervollständigung hinausgehen und neue Schwächen von LLMs identifizieren.’

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

‘Wichtig ist, dass wir den Studenten-Code nicht debuggt haben (während wir den LLM-Code sorgfältig getestet und debuggt haben, sowohl in Selbstspiel als auch in Turnier-[Einstellungen]). Jedes Mal, wenn ein Studentenagent abstürzte, gaben wir dem LLM automatisch den Sieg. Eine große Anzahl dieser Abstürze wäre leicht zu beheben (z. B. Agenten, die timeouten), so dass die Studentenagenten potenziell höher einstufen könnten.’

Als weiteres Experiment wurde GPT-5 Thinking angestoßen, den Code des top-performenden humanen Agenten, Student 1, zu verbessern; jedoch fiel der jetzt LLM-modifizierte Agent auf den zehnten Platz zurück, der schlechteste aller humanen Ergebnisse. Anstatt die Lösung zu verbessern, verschlechterten die Änderungen des LLMs sie um fast 20%.

Die Autoren schließen:

‘[Unsere] Ergebnisse heben wichtige Grenzen der LLM-Codegenerierung hervor, insbesondere ihre begrenzten Fähigkeiten zur Planung und zum Reasoning bei der Codegenerierung. Moderne LLMs sind in der Lage, syntaxfehlerfreien Code zu liefern, der läuft, aber das ist nicht der Benchmark, den wir verwenden sollten, um den Fortschritt hin zu fortschrittlicher allgemeiner KI zu messen.’

Schlussfolgerung

Die Autoren selbst bemerken gegen Ende des Papiers, dass Vibe-Coding Menschen aller technischen Hintergründe ermöglicht hat und diese Praxis in einem positiven Licht darstellen, als eine ausgleichende Kraft. Sie implizieren jedoch auch, dass Vibe-Coding erst kürzlich angekommen ist, seine Grenzen nicht bekannt sind und möglicherweise höher angenommen werden, als realistisch erwartet werden kann.

Sie schließen ihr Angebot mit einem Aufruf zu einer Zielverschiebung ‘von Code, der compiliert, zu Code, der wettbewerbsfähig ist‘ ab.

Eine Frage, die der interessierte Leser dieses interessanten 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 Erstellen 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, das offensichtlich 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, kontaktieren Sie mich bitte über meine Profildaten, und ich werde es ändern.

^† Betonung der Autoren, nicht meine.

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