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.












