Andersons vinkel
Menneskelig kode fra 2020 besejrede vibe-kodede agenter i agente-test

ChatGPT og andre vibe-kodningværktøjer blev testet i næsten 40.000 kampe – og tabte til kode skrevet af studerende før opfindelsen af Large Language Models.
I en ny studie fra Storbritannien fik forskerne menneskeligt kodede agenter til at konkurrere mod vibe-kodede agenter udviklet med de seneste Large Language Models (LLMs), såsom ChatGPT-5 og Claude, og fandt, at agenterne, der blev skabt uden AI-hjælp, let kunne besejre de AI-faciliteterede versioner.
Begge sæt af agenter blev skabt af forskellige generationer af studerende fra det schweiziske føderale tekniske institut i Lausanne. De ikke-AI-agenter blev udviklet som en del af en kursus i 2020, to år før opfindelsen af ChatGPT og starten på LLM-revolutionen, mens de nye agenter blev skabt af nuværende studerende med hjælp fra de seneste og bedste LLMs.
Selv med en manipuleret kamp kunne vibe-kodede løsninger ikke vinde, og de fem øverste pladser blev konsekvent besat af ‘rå’ agenter, og de fleste LLM-agenter (33 ud af 40) blev let besejret af ‘meget simple’ baseline-agenter, på tværs af 38.304 udfordringer i en turnering, på tværs af et stort antal variable og omstændigheder.
Artiklen siger:
‘Vores arbejde demonstrerer, at selvom state-of-the-art LLMs kan generere kode, der kører (dvs. fri for syntaksfejl), er den genererede løsning ikke konkurrencedygtig i forhold til menneskeligt designede løsninger på dimensioner såsom strategisk planlægning, optimering eller multi-agent-konkurrence.
‘Derfor bringer dette arbejde denne nye front i kodegenerering til forkanten, og sigter mod at faciliterer udviklingen af benchmarks, datasæt og open-source-baselines, der belaster reasoningsdrevet kode-syntese.’
Udfordringen, der blev udformet, var at deltage kreativt i auktioner på tværs af en række strategier og at arrangere logistikken for levering af vundne varer til vinderne.
Forfatterne bemærker, at en række fordele blev givet til LLMs, såsom at gribe ind i deres kode for at forbedre deres præstation – en fordel, der ikke var tilladt for 2020-koden. Trods dette kunne LLMs ikke acceptere eller bruge denne fordel, selv når de fik korrekt kode, der ville have forbedret deres resultater:
‘[I] vores benchmark, selv når vi eksponerer en god løsning i kontekst, kan LLM ikke udnytte den.
‘Dette resultat rejser også interessante fremtidige forskningsspørgsmål om grænserne for in-context-læring og retrieval-forstærket problemløsning i komplekse scenarier.’
LLMs, der blev brugt i testen, var GPT-5 Thinking, Gemini 2.5 Pro, Claude Opus 4.1 og DeepSeek R1*.
Den nye artikel har titlen Can Vibe Coding Beat Graduate CS Students? An LLM vs. Human Coding Tournament on Market-driven Strategic Planning og kommer fra en forfatter fra University of Southampton og en anden fra University of Oxford og Alan Turing Institute. Benchmarket vil, ifølge forfatterne, blive frigivet snart.
Metode
Forfatterne bemærker, at traditionelle tests i denne sfære fokuserer på udfordringer med klart definerede binære løsninger (korrekt eller ikke korrekt), verificeret gennem unit-tests. De hævder, at dette ikke er den ideelle måde at udforske begrænsningerne for LLM-hjulpet kode, og har i stedet udformet en mere kompleks udfordrings-scenario med multiple interne benchmarks og milepæle, hvor sejr er muligt, men langt fra simpelt:
![Sammenligning af standard, unit-test-baserede tilgange (øverst), og den mere åbne udfordrings-scenario, der er udformet af forfatterne (i blåt, nederst). Kilde [ https://arxiv.org/pdf/2511.20613 ]](https://www.unite.ai/wp-content/uploads/2025/11/figure-1-2.jpg)
Sammenligning af standard, unit-test-baserede tilgange (øverst), og den mere åbne udfordrings-scenario, der er udformet af forfatterne (i blåt, nederst). Kilde
Auktion, afhentning og leverings-problemet (APDP) blev brugt i forfatternes studie og var delvist selvvalgt på grund af tilgængeligheden af en korpus af 2020-studentarbejde fra det schweiziske universitet; arbejde, der havde til formål at skabe automatiserede agenter til APDP-opgaven, før muligheden for at styrke udviklingen gennem AI. Derfor var det relativt let at give moderne studerende samme opgave, men med de nuværende værktøjer.
Forfatterne søgte at undgå populære test-rammer såsom HumanEval, BigCodeBench og WebDev Arena (iblandt mange andre), da denne klasse af test-procedurer tenderer til at lide under data-forurening (dvs. tilfælde, hvor systemet måske har trænet på test-data i stedet for at respektere en split).
APDP er et to-trins logistik-problem baseret på reverse-auktioner og køretøjs-ruteplanlægning. I første trin konkurrerer agenterne om at vinde leverings-opgaver ved at indgive bud på, hvor meget de skal betales for at fuldføre hver opgave. At budde for højt betyder at tabe opgaven; at budde for lavt kan betyde at tabe penge.
I andet trin skal hver agent skabe en effektiv plan til at fuldføre kun de opgaver, de har vundet, ved at tildele dem til køretøjer med forskellige kapaciteter og omkostninger, under tids- og ressource-begrænsninger:

I APDP, buder virksomheder på reverse-auktioner for leverings-opgaver, derefter optimerer de køretøjs-ruter for at fuldføre kun de opgaver, de har vundet, med det formål at maksimere profit.
Målet er ikke blot at fuldføre opgaverne, men at maksimere den samlede profit ved at forudse, hvilke bundter af opgaver, der vil fungere bedst sammen, og forudse strategierne for konkurrenter, der alle forsøger at gøre det samme.
APDP-benchmarket øger sværhedsgraden af kode-genererings-opgaver ved at introducere strategisk planlægning på tværs af en række afhængige auktioner, hvor hver bud ændrer landskabet for fremtidige valg; og kræver derfor, at agenterne forstår ikke blot omgående omkostninger, men også positionering, timing og langsigtede konsekvenser.
Det centrale leverings-problem er NP-hard, dvs. ingen algoritme kan pålideligt finde den bedste løsning på rimelig tid, når antallet af opgaver vokser. Dette gør, at brute force ikke er en brugbar tilgang, og tvinger agenterne til at handle præcision for hastighed.
Kap-løbet er i gang
Forfatternes evaluering sammenlignede 40 LLM-kodede agenter med 17 menneskeligt kodede agenter i en række head-to-head-turneringer. Hver af de 12 turneringer brugte en anden kombination af fire vej-netværk-topologier og bestod af all-play-all-par-rengøringer, hvor agenterne mødte hver modstander to gange: en gang som kontrollerende selskab og en gang som det andet selskab, med forskellige køretøjs-specifikationer.
Dette setup resulterede i 3.192 kampe per turnering, i alt 38.304 kampe. I hver kamp blev 50 leverings-opgaver auktioneret, defineret af deres afhentnings- og leveringspunkter og vægt, og trukket tilfældigt på tværs af vej-layout, der var modelleret på Schweiz, Frankrig, Storbritannien og Holland:

Forenklede vej-netværk, der blev brugt i turneringen: Storbritannien (øverst til venstre), Schweiz (øverst til højre), Holland (nederst til venstre) og Frankrig (nederst til højre). Blå og røde firkanter markerer afhentnings- og leverings-opgaver. Farvede trekanter viser den nuværende position for agenternes køretøjer.
Student-agenterne blev trukket fra en 2020-kursus-turnering. Otte kom fra de bedste performere i en enkelt-eliminations-finale, og fire mere blev valgt for stærke præstationer mod baseline-agenterne i head-to-head-kampe.
Baseline-agenterne fulgte faste heuristikker. Naiv beregnede den samlede distance og bød derefter, ved at bruge kun ét køretøj og ignorere batchning; ExpCostFixedBid simulerede 10 tilfældige opgaver og bød den gennemsnitlige marginale omkostning; Honest beregnede den faktiske marginale omkostning ved at indsætte opgaven i tidsplanen; ModelOpponent gjorde det samme, men tilføjede en estimat af modstanderens omkostning, og bød maksimum; og RiskSeeking blandede en tids-afbrydende prioritet med live-omkostnings-estimering og modstander-modellering – igen bød det højere af de to.
Evalueringen omfattede 40 LLM-kodede agenter, der blev bygget med (ovennævnte) GPT-5 Thinking, Claude Opus 4.1, Gemini 2.5 Pro og DeepSeek R1. Hver model blev promptet med fem forskellige strategier, der blev anvendt to gange per model.
To strategier brugte statiske prompts skrevet af forskellige forfattere, mens en tredje bad modellen om at selv-reflektere og revidere sin egen output; en anden involverede kritik og revision af en separat LLM. Den sidste strategi brugte GPT-4 til at syntetisere en ny prompt ved at gennemgå alle fire tidligere tilgange.
Den grundlæggende prompt afspejlede den oprindelige student-opgave, der beskrev leverings-miljøet og instruerede modellen om at budde og planlægge for at maksimere profit, uden at stole på komplekse metoder.
Alle LLM-agenter blev testet i både selv-spil og turnerings-indstillinger, indtil alle observerbare fejl var rettet. Fejl-retning blev håndteret autonomt af LLMs selv, promptet med fejl-informationen.
Almindelige LLM-fejl, som artiklen bemærker, omfattede overtrædelse af tidsgrænser, fejl ved at afhente eller levere tildelte opgaver, og overtrædelse af køretøjs-kapacitets-begrænsninger – fejl, der ofte opstod på grund af, at de ikke respekterede eksplicitte instruktioner eller på grund af fejl i omplanlægnings-logik†:
‘En anden almindelig fejl, vi fandt (især med Gemini, Claude og DeepSeek, og ikke så meget med GPT), er, at LLM ofte konsekvent fejlede i at løse en fejl.
‘For eksempel ville en agent konsekvent timeout, på trods af multiple (f.eks. 5 − 15) cykler af at prompte LLM med fejlen og modtage den opdaterede version af koden.
‘Den eneste løsning, vi fandt for sådanne situationer (hvor LLM gentagne gange fejler i at løse den samme fejl), er at starte forfra. Overordnet set observerede vi behovet for betragtelig manuel indsats for at opnå fejl-fri kode. Vi måtte generere betragteligt flere agenter for at få de 40 fejl-frie, vi evaluerede.’
Resultaterne, der vises nedenfor, summerer resultater fra 12 dobbelt-omgangs-turneringer, der omfatter fire netværk-topologier og tre turneringer per topologi, hvilket resulterer i næsten 40.000 kampe:
| Agent | Gennemsnitligt antal sejre per turnering | Standardafvigelse for antal sejre per turnering | Gennemsnitligt antal nederlag per turnering | Standardafvigelse for antal nederlag per turnering | Samlet antal sejre | Samlet antal nederlag | Sejrsprocent |
|---|---|---|---|---|---|---|---|
| Student 1 | 108.167 | 1.193 | 3.833 | 1.193 | 1298 | 46 | 0.9658 |
| Student 2 | 104.917 | 2.539 | 7.083 | 2.539 | 1259 | 85 | 0.9368 |
| Student 3 | 103.917 | 2.466 | 8.083 | 2.466 | 1247 | 97 | 0.9278 |
| Student 4 | 103.25 | 1.815 | 8.75 | 1.815 | 1239 | 105 | 0.9219 |
| Student 5 | 96.5 | 2.908 | 15.5 | 2.908 | 1158 | 186 | 0.8616 |
| LLM(O, IR, 1) | 95.417 | 2.314 | 16.583 | 2.314 | 1145 | 199 | 0.8519 |
| LLM(O, A2, 1) | 94.583 | 2.314 | 17.417 | 2.314 | 1135 | 209 | 0.8445 |
| Student 6 | 93.167 | 1.899 | 18.833 | 1.899 | 1118 | 226 | 0.8318 |
| Student 7 | 93.167 | 3.563 | 18.833 | 3.563 | 1118 | 226 | 0.8318 |
| LLM(O, A1, 1) | 86.083 | 3.029 | 25.917 | 3.029 | 1033 | 311 | 0.7686 |
| LLM(O, GEN, 2) | 84.083 | 6.947 | 27.917 | 6.947 | 1009 | 335 | 0.7507 |
| LLM(O, CR, 2) | 83.5 | 4.442 | 28.5 | 4.442 | 1002 | 342 | 0.7455 |
| Student 8 | 83.417 | 4.122 | 28.583 | 4.122 | 1001 | 343 | 0.7448 |
| RiskSeeking | 82.417 | 3.343 | 29.583 | 3.343 | 989 | 355 | 0.7359 |
| LLM(O, GEN, 1) | 80.667 | 4.355 | 31.25 | 4.372 | 968 | 375 | 0.7208 |
| ModelOpponent | 80.583 | 3.26 | 31.417 | 3.26 | 967 | 377 | 0.7195 |
| LLM(D, A1, 1) | 79.417 | 3.965 | 32.583 | 3.965 | 953 | 391 | 0.7091 |
| ExpCostFixedBid | 77.167 | 4.951 | 34.833 | 4.951 | 926 | 418 | 0.689 |
| LLM(O, IR, 2) | 73.917 | 3.502 | 38 | 3.618 | 887 | 456 | 0.6605 |
| LLM(O, A1, 2) | 72.417 | 2.193 | 39.583 | 2.193 | 869 | 475 | 0.6466 |
| LLM(G, A1, 2) | 68.5 | 3.555 | 43.5 | 3.555 | 822 | 522 | 0.6116 |
| LLM(A, GEN, 2) | 67.917 | 2.968 | 44.083 | 2.968 | 815 | 529 | 0.6064 |
| LLM(G, IR, 2) | 65.917 | 2.314 | 46.083 | 2.314 | 791 | 553 | 0.5885 |
| Student 9 | 64.167 | 11.044 | 47.833 | 11.044 | 770 | 574 | 0.5729 |
| LLM(G, A1, 1) | 64 | 4.243 | 47.917 | 4.316 | 768 | 575 | 0.5719 |
| LLM(G, IR, 1) | 60.333 | 3.725 | 51.667 | 3.725 | 724 | 620 | 0.5387 |
| LLM(O, A2, 2) | 59.333 | 4.499 | 52.667 | 4.499 | 712 | 632 | 0.5298 |
| LLM(D, CR, 1) | 55.083 | 6.694 | 56.833 | 6.59 | 661 | 682 | 0.4922 |
| LLM(G, GEN, 2) | 53.167 | 3.664 | 58.833 | 3.664 | 638 | 706 | 0.4747 |
| LLM(D, GEN, 2) | 52.083 | 9.06 | 59.917 | 9.06 | 625 | 719 | 0.465 |
| Honest | 50.583 | 3.848 | 61.417 | 3.848 | 607 | 737 | 0.4516 |
| Student 10 | 48.833 | 2.98 | 63.167 | 2.98 | 586 | 758 | 0.436 |
| LLM(D, IR, 1) | 48.583 | 10.211 | 63.417 | 10.211 | 583 | 761 | 0.4338 |
| LLM(A, A1, 1) | 48 | 4.69 | 64 | 4.69 | 576 | 768 | 0.4286 |
| LLM(G, A2, 1) | 47.25 | 3.864 | 64.75 | 3.864 | 567 | 777 | 0.4219 |
| LLM(A, CR, 1) | 43.833 | 4.609 | 68.167 | 4.609 | 526 | 818 | 0.3914 |
| LLM(A, A1, 2) | 43.75 | 2.05 | 68.25 | 2.05 | 525 | 819 | 0.3906 |
| Student 11 | 42.083 | 5.664 | 69.917 | 5.664 | 505 | 839 | 0.3757 |
| LLM(A, IR, 1) | 39.5 | 2.541 | 72.5 | 2.541 | 474 | 870 | 0.3527 |
| Naive | 36.75 | 1.712 | 75.25 | 1.712 | 441 | 903 | 0.3281 |
| Student 12 | 36.333 | 1.775 | 75.667 | 1.775 | 436 | 908 | 0.3244 |
| LLM(D, A2, 1) | 33.917 | 2.193 | 78.083 | 2.193 | 407 | 937 | 0.3028 |
| LLM(A, GEN, 1) | 30.167 | 1.749 | 81.833 | 1.749 | 362 | 982 | 0.2693 |
| LLM(D, A2, 2) | 29.833 | 2.038 | 82.167 | 2.038 | 358 | 986 | 0.2664 |
| LLM(G, A2, 2) | 27 | 2.256 | 85 | 2.256 | 324 | 1020 | 0.2411 |
| LLM(A, A2, 1) | 26.333 | 0.985 | 85.667 | 0.985 | 316 | 1028 | 0.2351 |
| LLM(O, CR, 1) | 25 | 3.411 | 87 | 3.411 | 300 | 1044 | 0.2232 |
| LLM(A, IR, 2) | 24.333 | 8.542 | 87.667 | 8.542 | 292 | 1052 | 0.2173 |
| LLM(A, A2, 2) | 24 | 1.809 | 88 | 1.809 | 288 | 1056 | 0.2143 |
| LLM(A, CR, 2) | 23.333 | 1.557 | 88.667 | 1.557 | 280 | 1064 | 0.2083 |
| LLM(D, GEN, 1) | 22.5 | 1.784 | 89.5 | 1.784 | 270 | 1074 | 0.2009 |
| LLM(D, A1, 2) | 13.333 | 1.826 | 98.667 | 1.826 | 160 | 1184 | 0.119 |
| LLM(G, CR, 1) | 9.5 | 1.087 | 102.5 | 1.087 | 114 | 1230 | 0.0848 |
| LLM(G, GEN, 1) | 9.167 | 0.937 | 102.833 | 0.937 | 110 | 1234 | 0.0818 |
| LLM(D, IR, 2) | 7.75 | 0.622 | 104.25 | 0.622 | 93 | 1251 | 0.0692 |
| LLM(G, CR, 2) | 7.25 | 1.422 | 104.75 | 1.422 | 87 | 1257 | 0.0647 |
| LLM(D, CR, 2) | 5.667 | 0.985 | 106.333 | 0.985 | 68 | 1276 | 0.0506 |
Til sammenligning, spillede hver agent 112 kampe per turnering, så det maksimale gennemsnitlige antal sejre eller nederlag per agent er 112. Standardafvigelse (SD) afspejler variabilitet på tværs af turneringer. Menneskeligt kodede agenter fremhæves i fed. LLM-kodede agenter er mærket med model (O = GPT-5 Thinking, G = Gemini 2.5 Pro, A = Claude Opus 4.1, D = DeepSeek R1), efterfulgt af en to-bogstavers prompt-strategi-kode og et tal, der angiver, om agenten er den første eller anden, der er genereret med denne prompt. Kilde
I forhold til resultaterne ovenfor siger forfatterne†:
‘LLMs genererede ikke forventede/konkurrencedygtige kode, selv i simple varianter af APDP-problemet (på trods af, at koden var stort set fri for syntaksfejl). Dette understreger vigtigheden af reasoningsdrevne kode-evaluering-benchmarks, der går ud over auto-complete og identificerer nye svagheder i LLMs.’
‘Vore resultater demonstrerer en klar overlegenhet for menneskeligt kodede agenter: (i) De top 5 pladser er konsekvent besat af student-agenter, og (ii) de fleste LLM-agenter (33 ud af 40) bliver besejret af meget simple baseline-agenter (såsom den forventede omkostnings-fikserede bud).
‘Vigtigt, vi debuggede ikke student-koden (mens vi grundigt testede og debuggede LLM-koden, både i selv-spil og turnerings-indstillinger). Hver gang en student-agent crashed, gav vi automatisk sejren til LLM. Et stort antal af disse crashes ville være lette at rette (f.eks. agenter, der timed out), så student-agenter kunne potentielt rangere endnu højere.’
Som en yderligere eksperiment blev GPT-5 Thinking promptet til at forbedre koden for den bedst performende menneskeligt kodede agent, Student 1; men den nu LLM-modificerede agent faldt herefter til tiende pladsen, nu den dårligste af alle menneskeligt kodede scores. I stedet for at forbedre løsningen, forringede LLMs ændringer den med næsten 20%.
Forfatterne konkluderer:
‘[Vore] resultater fremhæver vigtige begrænsninger for LLM-kode-generering, mest bemærkelsesværdigt deres begrænsede reasonings- og planlægnings-evner, mens de genererer [kode]. Moderne LLMs kan levere syntaks-fejl-fri kode, der kører, men det er ikke den benchmark, vi skal bruge til at måle fremgang mod avanceret generel AI.’
Konklusion
Forfatterne selv bemærker mod slutningen af artiklen, at vibe-kodning har givet mennesker af alle tekniske baggrunde mulighed for at deltage, og karakteriserer praksis i en positiv lys, som en udjævner. De antyder dog også, at da vibe-kodning er en ny udvikling, er dens begrænsninger ikke kendt, og kan antages at være højere, end man realistisk kan forvente.
De afslutter deres artikel med at kalde for en mål-skift ‘fra kode, der compiler til kode, der konkurrerer’.
En spørgsmål, som den almindelige læser af denne interessante nye artikel kan have, er, om forfatterne slår opad eller nedad, da den agente-opgave i spørgsmål er betydeligt mere kompleks og involveret end at generere PowerShell-scripts og andre former for mindre funktionalitet og rettelser, som vibe-kodning er velegnet til.
* Vær venlig at bemærke, at artiklen henviser konstant til ‘DeepThink R1′, som synes at være ikke-eksisterende, og kun viser en håndfuld henvisninger på internettet (formodentlig fra andre forfattere, der har skrevet forkert ‘DeepSeek R1)’. Hvis dette er min fejl, kontakt mig venligst via mine profil-oplysninger, så jeg kan rette.
† Forfatternes fremhævelse, ikke min.
Først publiceret onsdag, den 26. november 2025. Ændret kl. 17:35 øst for formatering.












