Andersons vinkel
Menneskelig kode fra 2020 slo vibe-kodede agenter i agenttest

ChatGPT og andre vibe-koding-verktøy ble testet i nesten 40 000 kamper – og tapte mot kode skrevet av en masterstudent før oppfinnelsen av store språkmodeller.
I en ny studie fra Storbritannia, ble menneske-kodede agenter satt opp mot vibe-kodede agenter utviklet med de nyeste store språkmodellene (LLM), som ChatGPT-5 og Claude, og fant at agentene som ble skapt uten AI-hjelp, lett slo de AI-baserte versjonene.
Begge sett med agenter ble skapt av forskjellige generasjoner av studenter fra det sveitsiske føderale tekniske instituttet i Lausanne. De ikke-AI-agenter ble utviklet som en del av kursarbeid i 2020, to år før oppfinnelsen av ChatGPT og starten på LLM-revolusjonen, mens de nye agentene ble skapt av nåværende studenter, med hjelp av de nyeste og beste LLM-ene som er tilgjengelige.
Even om det var en rigget kamp, kunne ikke vibe-kodede løsninger vinne, og de fem øverste plassene ble konsekvent holdt av ‘rene’ agenter, med flertallet av LLM-agenter (33 av 40) ble lett slått av ‘svært enkle’ basisagenter, over 38 304 kamper i en turnering, over en rekke variabler og omstendigheter.
Arbeidet sier:
‘Vårt arbeid viser at selv om state-of-the-art LLM-er kan generere kode som kjører (dvs. fri for syntaksfeil), er den genererte løsningen ikke konkurransedyktig med menneske-designet løsninger på dimensjoner som strategisk planlegging, optimalisering eller multi-agent konkurranse.
‘Derfor bringer dette arbeidet denne nye grensen i kodegenerering til fremtred, og har som mål å fremme utviklingen av benchmark, datasett og åpne kildekoder som understreker resonning-drevet kode-syntese.’
Utfordringen som ble utformet, var å kreativt delta i auksjoner, over en rekke strategier, og å ordne logistikken for å levere vunne varer til vinnerne.
Forfatterne bemerker at en rekke fordeler ble gitt til LLM-er, som å gripe inn i deres kode for å forbedre deres ytelse – en fordel som ikke ble tillatt for 2020-koden. Likevel, selv når de ble forsynt med korrekturkode som ville ha forbedret deres resultater, kunne ikke LLM-ene bruke den eller akseptere den:
‘[I] vårt benchmark, selv når vi eksponerer en god løsning i kontekst, er LLM-en fortsatt ikke i stand til å bruke den.
‘Dette resultatet reiser også interessante fremtidige forskningsspørsmål om grensene for kontekst-læring og problemløsning i komplekse scenarioer.’
LLM-ene som ble brukt i testen, var GPT-5 Thinking, Gemini 2.5 Pro, Claude Opus 4.1, og DeepSeek R1*.
Den nye artikkelen har tittelen Kan vibe-koding slå masterstudenter? En LLM mot menneske-koding turnering på marked-drevet strategisk planlegging, og kommer fra en forfatter ved University of Southampton, og en annen ved University of Oxford og Alan Turing Institute. Benchmarket vil, ifølge forfatterne, bli utgitt snart.
Metode
Forfatterne bemerker at tradisjonelle tester i denne sfæren fokuserer på utfordringer med tydelig definerte binære løsninger (korrekt eller ikke korrekt), verifisert gjennom unit tests. De hevder at dette ikke er den ideelle måten å utforske begrensningene av LLM-basert kode, og har i stedet utformet en mer kompleks utfordrings-scenario, med multiple interne benchmark og milepæler, hvor seier er mulig, men langt ifra enkel.
![Sammenligning av standard, unit-test-basert tilnærming (øverst), og den mer åpne utfordrings-scenariet utformet av forfatterne (i blått, nederst). Kilde [ https://arxiv.org/pdf/2511.20613 ]](https://www.unite.ai/wp-content/uploads/2025/11/figure-1-2.jpg)
Sammenligning av standard, unit-test-basert tilnærming (øverst), og den mer åpne utfordrings-scenariet utformet av forfatterne (i blått, nederst). Kilde
Aksjon, henting og leveringsproblemet (APDP) som ble brukt i forfatternes studie, var delvis selvvalgt, på grunn av tilgjengeligheten av en korpus av 2020-studentarbeid fra det sveitsiske universitetet; arbeid som søkte å skape automatiserte agenter for APDP-oppgaven, før noen evne til å støtte utviklingen gjennom AI.
Forfatterne søkte å unngå populære test-rammeverk som HumanEval, BigCodeBench og WebDev Arena (blant mange andre), siden denne klassen av test-prosedyrer tenderer til å lide under data-forurensning (dvs. eksempler hvor systemet kan ha trent på test-data i stedet for å respektere en split).
APDP er et to-trinns logistikk-problem basert på reverse-auksjoner og kjøretøy-ruting. I det første trinnet, konkurranse-agenter om å vinne leveringsoppgaver ved å sende inn bud for hvor mye de skal betales for å fullføre hver enkelt.
I det andre trinnet, må hver agent skape en effektiv plan for å fullføre bare de oppgavene de vant, ved å tildele dem til kjøretøy med forskjellige kapasiteter og kostnader, under tid- og ressurs-begrensninger:

I APDP, bud selskaper i reverse-auksjoner for leveringsoppgaver, så optimaliserer de kjøretøy-ruter for å fullføre bare de oppgavene de vinner, med mål om å maksimere fortjeneste.
Målet er ikke bare å fullføre oppgavene, men å maksimere total fortjeneste ved å forutse hvilke pakker av oppgaver som vil fungere best sammen, og forutsi strategiene til konkurrenter som alle prøver å gjøre det samme.
APDP-benchmarket øker vanskelighetsgraden av kode-genereringsoppgaver ved å introdusere strategisk planlegging over en sekvens av interavhengige auksjoner, med hver bud som omformer landskapet av fremtidige valg; og derfor krever agenter å resonere ikke bare om umiddelbare kostnader, men om posisjonering, tid og langtids-konsekvenser.
Kjerne-leveringsproblemet er NP-hardt, dvs. ingen algoritme kan pålitelig finne den beste løsningen på en rimelig tid når antallet oppgaver øker. Dette gjør brute force til en uframkommelig tilnærming, og tvinger agenter til å bytte nøyaktighet mot hastighet.
Konkurransen er i gang
Forfatternes evaluering sammenlignet 40 LLM-kodede agenter mot 17 menneske-kodede agenter i en rekke head-to-head-turneringer. Hver av de 12 turneringene brukte en annen kombinasjon av fire vei-nettverkstopologier, og bestod av all-play-all paringer, med agenter som møtte hver andre motstander to ganger: en gang som kontrollerte hver av to selskaper, med forskjellige kjøretøy-specifikasjoner.
Dette opplegget ga 3 192 kamper per turnering, totalt 38 304 kamper. I hver kamp ble 50 leveringsoppgaver auksjonert, definert av deres henting- og leveringspunkter og vekt, og trukket tilfeldig over vei-layoter modellert på Sveits, Frankrike, Storbritannia og Nederland:

Forenklet vei-nettverk brukt i turneringen: Storbritannia (øverst til venstre), Sveits (øverst til høyre), Nederland (nederst til venstre) og Frankrike (nederst til høyre). Blå og røde firkanter markerer henting- og leveringsoppgaver. Fargede trekanter viser nåværende posisjoner for agentens kjøretøy.
Student-agenter ble trukket fra en 2020-kurs-turnering. Åtte kom fra topp-prestasjonene i en enkelt-eliminering-finale, og fire flere ble valgt for sterke prestasjoner mot basis-agenter i head-to-head-kamper.
Basis-agenter fulgte faste heuristikk. Naiv beregnet totalt avstand og bud deretter, ved å bruke bare ett kjøretøy og ignorere batch; ExpCostFixedBid simulerte 10 tilfeldige oppgaver, og bud den gjennomsnittlige marginale kostnaden; Honest beregnet den faktiske marginale kostnaden for å sette inn oppgaven i planen; ModelOpponent gjorde det samme, men la til en estimat av motstanderens kostnad, og bud maks; og RiskSeeking blandet en tid-avtakende prioritet med live-kostnads-estimering og motstander-modellering – igjen bud maks.
Evalueringen inkluderte 40 LLM-kodede agenter bygget med (ovennevnte) GPT-5 Thinking, Claude Opus 4.1, Gemini 2.5 Pro og DeepSeek R1. Hver modell ble promptet med fem forskjellige strategier, anvendt to ganger per modell.
To strategier brukte statiske prompter skrevet av forskjellige forfattere, mens en tredje ba modellen om å reflektere over og revidere sin egen utgang; en annen involverte kritikk og revisjon av en separat LLM. Den siste strategien brukte GPT-4 til å syntetisere en ny prompt ved å gjennomgå alle fire tidligere tilnærminger.
Grunn-prompten reflekterte den opprinnelige student-oppgaven, som beskrev leverings-miljøet og instruerte modellen om å bud og planlegge for å maksimere fortjeneste, uten å bruke høy-kompleksitets-metoder.
Alle LLM-agenter ble testet i både selv-spill og turnerings-innstillinger til alle observerbare feil var fikset. Feil-retting ble håndtert autonomt av LLM-ene selv, promptet med feil-informasjon.
Vanlige LLM-feil, bemerker artikkelen, inkluderte brudd på tidsbegrensninger, feil i å hente eller levere tildelte oppgaver, og brudd på kjøretøy-kapasitets-begrensninger – feil som ofte oppstod fra å ignorere eksplisitte instruksjoner, eller fra feilaktig omplanlegging-logikk†:
‘En annen vanlig feil vi fant (hovedsakelig med Gemini, Claude og DeepSeek, og ikke så mye med GPT) er at LLM-en ofte konsekvent feilet i å løse en feil.
‘For eksempel, en agent ville konsekvent time-out, til tross for flere (f.eks. 5 − 15) sykluser av å prompte LLM-en med feilen og motta den oppdaterte versjonen av koden.
‘Den eneste løsningen vi fant for slike situasjoner (der LLM-en gjentakende feiler i å løse den samme feilen) er å starte på nytt fra scratch. Overordnet sett observerte vi behovet for bettydelig manuell innsats for å oppnå feilfri kode. Vi måtte generere betydelig flere agenter for å få de 40 feilfrie vi evaluerte.’
Resultatene som vises nedenfor summerer resultater fra 12 dobbelte round-robin-turneringer, som omfatter fire nettverks-topologier og tre turneringer per topologi, og gir det beste delen av 40 000 kamper:
| Agent | Gjennomsnittlig antall seiere per turnering | Standardavvik i antall seiere per turnering | Gjennomsnittlig antall tap per turnering | Standardavvik i antall tap per turnering | Samlet antall seiere | Samlet antall tap | Seierprosent |
|---|---|---|---|---|---|---|---|
| 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, 1) | 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 |
For sammenligning, spilte hver agent 112 kamper per turnering, så maksimumsgjennomsnitt for seiere eller tap per agent er 112. Standardavvik (SD) reflekterer variasjon over turneringer. Menneske-kodede agenter vises i fet skrift. LLM-kodede agenter er merket med modell (O = GPT-5 Thinking, G = Gemini 2.5 Pro, A = Claude Opus 4.1, D = DeepSeek R1), etterfulgt av en to-bokstavs prompt-strategi-kode og en siffer som indikerer om agenten er den første eller andre generert med denne prompten. Kilde
I forhold til resultater som vises ovenfor, sier forfatterne†:
‘LLM-er genererte ikke forventet/konkurransedyktig kode, selv i enklere varianter av APDP-problemet (til tross for at koden var nesten fri for syntaksfeil). Dette understreker viktigheten av resonning-drevet kode-evaluering-benchmark som går utenfor auto-complete og identifiserer nye svakheter i LLM-er.’
‘Våre resultater demonstrerer en tydelig overlegenhet for menneske-kodede agenter: (i) De topp 5 plassene er konsekvent holdt av student-agenter, og (ii) flertallet av LLM-agenter (33 av 40) ble slått av svært enkle basisagenter (slik som den forventede kostnads-fikset bud).
‘Viktigere, vi debugget ikke student-koden (mens vi grundig testet/debugget LLM-koden, både i selv-spill og turnerings-innstilling). Hver gang en student-agent krasjet, ga vi automatisk seieren til LLM-en. Et stort antall av disse krasjene ville være enkle å fikse (f.eks. agenter som time-out), så student-agenter kunne potensielt rangere enda høyere.’
Som en ytterligere eksperiment, ble GPT-5 Thinking promptet til å forbedre koden til den beste menneske-kodede agenten, Student 1; men den nå LLM-modifiserte agenten falt til tiende plass, nå den dårligste av alle menneske-kode-resultatene. I stedet for å forbedre løsningen, forverret LLM-ene endringene den med nesten 20%.
Forfatterne konkluderer:
‘[Våre] resultater understreker viktige begrensninger i LLM-kode-generering, mest merkbart deres begrensede resonning- og planleggings-evner mens de genererer [kode]. Moderne LLM-er er i stand til å levere syntaks-feil-frie kode som kjører, men det er ikke benchmarket vi bør bruke til å måle fremgang mot avansert generell AI.’
Konklusjon
Forfatterne selv observerer mot slutten av artikkelen at vibe-koding har gitt mennesker av alle tekniske bakgrunner mulighet, og karakteriserer praksisen i et positivt lys, som en utjevner. Likevel antyder de også at fordi vibe-koding har nettopp ankommet, er dens grenser ikke kjent, og kan antas å være høyere enn man realistisk kan forvente.
De avslutter sitt tilbud med å påkalle en mål-endring ‘fra kode som kompilerer til kode som konkurranse‘.
En spørsmål som den uforberedte leser av denne interessante nye artikkelen kan ha, er om forfatterne slår opp eller ned, siden den agente-oppgaven i spørsmål er betraktelig mer kompleks og involvert enn å spy ut PowerShell-skript og andre former for mindre funksjonalitet og fikser for hvilke vibe-koding er godt egnet.
* Vennligst merk at artikkelen henviser kontinuerlig til ‘DeepThink R1′, som ser ut til å være ikke-eksisterende, og bare dukker opp noen få ganger på internettet (antageligvis fra andre forfattere som har skrevet feil ‘DeepSeek R1)’. Hvis dette er min feil, vennligst kontakt meg via mine profil-detaljer, og jeg vil korrigere.
† Forfatternes betoning, ikke min.
Først publisert onsdag, 26. november 2025. Endret 17:35 est for formatering.












