Angolo di Anderson
Codice Umano del 2020 Sconfigge Agenti con Codifica Vibe in Test Agentici

ChatGPT e altri strumenti di codifica vibe sono stati sottoposti a un test in quasi 40.000 partite – e hanno perso contro il codice scritto da uno studente universitario prima dell’invenzione dei Modelli di Linguaggio di Grande Scala.
In uno studio recente del Regno Unito, i ricercatori hanno confrontato agenti codificati dall’uomo con agenti codificati con la codifica vibe sviluppati con i più recenti Modelli di Linguaggio di Grande Scala (LLM), come ChatGPT-5 e Claude, e hanno scoperto che gli agenti creati senza l’aiuto dell’IA hanno facilmente sconfitto le versioni facilitate dall’IA.
Entrambi i set di agenti sono stati creati da diverse generazioni di studenti del Laboratorio di Intelligenza Artificiale dell’Istituto Tecnologico Federale Svizzero di Losanna. Gli agenti non-IA sono stati sviluppati come parte di un corso di studi nel 2020, due anni prima dell’inizio di ChatGPT e dell’inizio della rivoluzione LLM, mentre i nuovi agenti sono stati creati da studenti attuali, aiutati dai più recenti e migliori LLM disponibili.
Anche con un gioco truccato, le soluzioni con codifica vibe non sono riuscite a vincere, e i primi cinque posti sono stati costantemente occupati da agenti “grezzi”, con la maggior parte degli agenti LLM (33 su 40) sconfitti facilmente da agenti di base “molto semplici”, in 38.304 sfide in un torneo, su un ampio numero di variabili e circostanze.
Il paper afferma:
‘Il nostro lavoro dimostra che, mentre i LLM di stato dell’arte possono generare codice che funziona (cioè, senza errori di sintassi), la soluzione generata non è competitiva con le soluzioni progettate dall’uomo in dimensioni come la pianificazione strategica, l’ottimizzazione o la competizione multi-agente.
‘Pertanto, questo lavoro porta alla ribalta questa nuova frontiera nella generazione di codice, e mira a facilitare lo sviluppo di benchmark, set di dati e baseline open-source che enfatizzano la sintesi del codice guidata dalla ragione.’
La sfida ideata era quella di partecipare creativamente a aste, su una varietà di strategie, e di organizzare la logistica della consegna degli oggetti vinti ai vincitori.
Gli autori notano che sono stati concessi diversi vantaggi ai LLM, come l’intervento nel loro codice per migliorare le loro prestazioni – un vantaggio non concesso al codice del 2020; tuttavia, anche quando fornito con codice correttivo che avrebbe sicuramente migliorato i loro risultati, i LLM non sono stati in grado di utilizzarlo:
‘[Nel] nostro benchmark, anche quando esponiamo una buona soluzione in contesto, il LLM non è ancora in grado di utilizzarla.
‘Questo risultato solleva anche interessanti domande di ricerca future sui limiti dell’apprendimento in contesto e della risoluzione dei problemi aumentata in scenari complessi.’
I LLM utilizzati nel test sono stati GPT-5 Thinking, Gemini 2.5 Pro, Claude Opus 4.1, e DeepSeek R1*.
Il nuovo paper è intitolato Can Vibe Coding Beat Graduate CS Students? An LLM vs. Human Coding Tournament on Market-driven Strategic Planning, e proviene da un autore dell’Università di Southampton e da un altro dell’Università di Oxford e dell’Istituto Alan Turing. Il benchmark sarà, secondo gli autori, rilasciato presto.
Metodo
Gli autori notano che i test tradizionali in questo ambito si concentrano su sfide con soluzioni chiaramente definite (binarie, corrette o non corrette), verificate attraverso test unitari. Sostenendo che questo non è il modo ideale per esplorare i limiti del codice facilitato da LLM, gli autori hanno invece ideato una sfida più complessa, con molti benchmark interni e pietre miliari, in cui la vittoria è possibile, ma lontana dall’essere semplice:
![Confronto tra approcci standard basati su test unitari (in alto) e la sfida più aperta ideata dagli autori (in blu, in basso). Fonte [ https://arxiv.org/pdf/2511.20613 ]](https://www.unite.ai/wp-content/uploads/2025/11/figure-1-2.jpg)
Confronto tra approcci standard basati su test unitari (in alto) e la sfida più aperta ideata dagli autori (in blu, in basso). Fonte
Il Problema di Asta, Ritiro e Consegna (APDP) utilizzato per lo studio degli autori è stato in parte auto-selezionato, a causa della disponibilità di un corpus di lavori di studenti del 2020 dell’università svizzera; lavori che hanno cercato di creare agenti automatici per il compito APDP, prima della possibilità di rafforzare lo sviluppo attraverso l’IA. Pertanto, è stato relativamente facile assegnare agli studenti moderni lo stesso incarico, ma fornirli di strumenti attuali.
Gli autori hanno cercato di evitare framework di test popolari come HumanEval, BigCodeBench e WebDev Arena (tra molti altri), poiché questa classe di procedure di test tende a soffrire di contaminazione dei dati (ad esempio, istanze in cui il sistema può aver addestrato su dati di test invece di rispettare una divisione).
L’APDP è un problema di logistica a due fasi basato su aste inverse e pianificazione dei veicoli. Nella prima fase, gli agenti competono per vincere compiti di consegna presentando offerte per quanto dovrebbero essere pagati per completare ciascuno di essi. Offrire troppo significa perdere il compito; offrire troppo poco può significare perdere denaro.
Nella seconda fase, ogni agente deve creare un piano efficiente per adempiere solo ai compiti che ha vinto, assegnandoli a veicoli con diverse capacità e costi, sotto vincoli di tempo e risorse:

Nell’APDP, le aziende partecipano a aste inverse per compiti di consegna, poi ottimizzano le rotte dei veicoli per adempiere solo ai compiti che vincono, cercando di massimizzare il profitto.
L’obiettivo non è semplicemente completare i compiti, ma massimizzare il profitto complessivo anticipando quali bundle di compiti funzioneranno meglio insieme e prevedendo le strategie dei concorrenti che stanno cercando di fare lo stesso.
L’APDP solleva la difficoltà dei compiti di generazione di codice introducendo la pianificazione strategica attraverso una sequenza di aste interdipendenti, con ogni offerta che ridisegna il paesaggio delle scelte future; e quindi richiede agli agenti di ragionare non solo sui costi immediati, ma sulla posizione, sul timing e sulle conseguenze a lungo termine.
Il problema di consegna di base è NP-hard, cioè nessun algoritmo può trovare la soluzione migliore in tempo ragionevole man mano che il numero di compiti cresce. Ciò rende la forza bruta un approccio non praticabile e costringe gli agenti a scambiare la precisione con la velocità.
La Corsa è Iniziata
La valutazione degli autori ha confrontato 40 agenti codificati con LLM contro 17 agenti codificati dall’uomo in una serie di tornei testa a testa. Ogni uno dei 12 tornei ha utilizzato una combinazione diversa di quattro topologie di rete stradale, e consisteva in tutte le partite, con gli agenti che affrontavano ogni altro avversario due volte: una volta controllando ogni due società, con diverse specifiche di veicolo.
Questo setup ha prodotto 3.192 partite per torneo, per un totale di 38.304 partite. In ogni partita, 50 compiti di consegna sono stati messi all’asta, definiti dai loro punti di ritiro e consegna e peso, e tratti casualmente attraverso layout stradali modellati sulla Svizzera, Francia, Gran Bretagna e Paesi Bassi:

Reti stradali semplificate utilizzate nel torneo: Gran Bretagna (in alto a sinistra), Svizzera (in alto a destra), Paesi Bassi (in basso a sinistra) e Francia (in basso a destra). I quadrati blu e rossi segnano i compiti di ritiro e consegna. I triangoli colorati mostrano le posizioni attuali dei veicoli degli agenti.
Gli agenti degli studenti sono stati tratti da un torneo di corsi del 2020. Otto provenivano dai migliori performer in una finale a eliminazione singola, e quattro altri sono stati scelti per le loro prestazioni forti contro gli agenti di base in partite testa a testa.
Gli agenti di base seguivano euristici fissi. Naive calcolava la distanza totale e offriva di conseguenza, utilizzando solo un veicolo e ignorando il batching; ExpCostFixedBid simulava 10 compiti casuali e offriva il costo marginale medio; Honest calcolava il costo marginale effettivo di inserimento del compito nel piano; ModelOpponent fece lo stesso, ma aggiunse una stima del costo dell’avversario, offrendo il massimo; e RiskSeeking combinava un prior con decadimento temporale con la stima del costo e la modellazione dell’avversario – offrendo il più alto dei due.
La valutazione includeva 40 agenti codificati con LLM costruiti utilizzando i già menzionati GPT-5 Thinking, Claude Opus 4.1, Gemini 2.5 Pro e DeepSeek R1. Ogni modello è stato promosso con cinque strategie diverse, applicate due volte per modello.
Due strategie utilizzavano prompt statici scritti da autori diversi, mentre una terza chiedeva al modello di riflettere e rivedere la sua stessa output; un’altra strategia coinvolgeva la critica e la revisione da parte di un LLM separato. L’ultima strategia utilizzava GPT-4 per sintetizzare un nuovo prompt esaminando tutti e quattro gli approcci precedenti.
Il prompt di base rifletteva l’incarico originale dello studente, descrivendo l’ambiente di consegna e istruendo il modello a offrire e pianificare per massimizzare il profitto, senza affidarsi a metodi ad alta complessità.
Tutti gli agenti LLM sono stati testati in entrambi i contesti di auto-gioco e torneo fino a quando non sono stati risolti tutti gli errori osservabili. La correzione degli errori è stata gestita in modo autonomo dai LLM stessi, promossi con le informazioni di errore.
I fallimenti comuni dei LLM, nota il paper, includevano violazioni dei limiti di timeout, fallimenti nel ritiro o nella consegna di compiti assegnati e violazioni dei vincoli di capacità dei veicoli – errori che spesso derivavano dal disprezzo di istruzioni esplicite o da una logica di ripianificazione difettosa†:
‘Un altro problema comune che abbiamo riscontrato (soprattutto con Gemini, Claude e DeepSeek, e non così tanto con GPT) è che spesso il LLM non riusciva a risolvere un bug.
‘Ad esempio, un agente si bloccava costantemente, nonostante molteplici (ad esempio, 5-15) cicli di prompt del LLM con l’errore e ricezione della versione aggiornata del codice.
‘L’unica soluzione che abbiamo trovato per tali situazioni (in cui il LLM ripetutamente non riesce a risolvere lo stesso bug) è di ripartire da zero. In generale, abbiamo osservato la necessità di sforzo manuale significativo per raggiungere un codice senza bug. Abbiamo dovuto generare sostanzialmente più agenti per ottenere i 40 senza bug che abbiamo valutato.’
I risultati mostrati di seguito riassumono gli esiti di 12 tornei a doppia eliminazione, che coprono quattro topologie di rete e tre tornei per topologia, per un totale di quasi 40.000 partite:
| Agente | Avg #Vittorie / Torneo | SD #Vittorie / Torneo | Avg #Sconfitte / Torneo | SD #Sconfitte / Torneo | Vittorie Totali | Sconfitte Totali | Percentuale di Vittorie |
|---|---|---|---|---|---|---|---|
| Studente 1 | 108.167 | 1.193 | 3.833 | 1.193 | 1298 | 46 | 0.9658 |
| Studente 2 | 104.917 | 2.539 | 7.083 | 2.539 | 1259 | 85 | 0.9368 |
| Studente 3 | 103.917 | 2.466 | 8.083 | 2.466 | 1247 | 97 | 0.9278 |
| Studente 4 | 103.25 | 1.815 | 8.75 | 1.815 | 1239 | 105 | 0.9219 |
| Studente 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 |
| Studente 6 | 93.167 | 1.899 | 18.833 | 1.899 | 1118 | 226 | 0.8318 |
| Studente 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 |
| Studente 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 |
| Studente 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 |
| Studente 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 |
| Studente 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 |
| Studente 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 |
Per contesto, ogni agente ha giocato 112 partite per torneo, quindi la media massima possibile per vittorie o sconfitte per agente è 112. La deviazione standard (SD) riflette la variabilità tra i tornei. Gli agenti codificati dall’uomo appaiono in grassetto. Gli agenti codificati con LLM sono etichettati con il modello (O = GPT-5 Thinking, G = Gemini 2.5 Pro, A = Claude Opus 4.1, D = DeepSeek R1), seguito da un codice di strategia a due lettere e da un numero che indica se l’agente è il primo o il secondo generato con quel prompt. Fonte
Riguardo ai risultati mostrati sopra, gli autori affermano†:
‘I LLM non generano codice atteso/competitivo anche in varianti più semplici del problema APDP (nonostante il codice sia largamente privo di bug di sintassi). Ciò sottolinea l’importanza di benchmark di valutazione del codice guidati dalla ragione che vanno oltre l’autocompletamento e identificano nuove debolezze dei LLM.’
‘I nostri risultati dimostrano una chiara superiorità degli agenti codificati dall’uomo: (i) i primi 5 posti sono costantemente occupati da agenti degli studenti, e (ii) la maggior parte degli agenti LLM (33 su 40) sono sconfitti da agenti di base molto semplici (come l’offerta fissa del costo atteso).
‘Inoltre, non abbiamo debuggato il codice degli studenti (mentre abbiamo testato e debuggato accuratamente il codice LLM, sia in auto-gioco che in torneo). Ogni volta che un agente degli studenti si bloccava, gli abbiamo automaticamente assegnato la vittoria al LLM. Un gran numero di questi blocchi sarebbe stato facile da risolvere (ad esempio, gli agenti si bloccavano), quindi gli agenti degli studenti potrebbero classificarsi ancora più in alto.’
Come ulteriore esperimento, GPT-5 Thinking è stato promosso per migliorare il codice dell’agente umano di alto rendimento, Studente 1; ma l’agente LLM modificato è poi sceso al decimo posto, ora il peggiore di tutti i punteggi umani. Invece di migliorare la soluzione, i cambiamenti dei LLM l’hanno degradata di quasi il 20%.
Gli autori concludono:
‘[I nostri] risultati mettono in luce importanti limitazioni della generazione di codice LLM, più notevolmente le loro limitate capacità di ragionamento e pianificazione mentre generano [codice]. I LLM moderni possono fornire codice privo di bug di sintassi che funziona, ma questo non è il benchmark che dovremmo utilizzare per misurare i progressi verso un’IA generale avanzata.’
Conclusione
Gli autori stessi osservano verso la fine del paper che la codifica vibe ha dato potere alle persone di tutti i background tecnici e la caratterizzano in una luce positiva, come una forza livellatrice. Tuttavia, implicano anche che poiché la codifica vibe è appena arrivata, i suoi limiti non sono noti e potrebbero essere considerati piuttosto più alti di quanto ci si possa realisticamente aspettare.
Chiudono la loro offerta chiedendo un cambio di obiettivo ‘da codice che compila a codice che compete‘.
Una domanda che il lettore casuale di questo nuovo paper interessante potrebbe avere è se gli autori stanno colpendo in alto o in basso, poiché il compito agente in questione è considerevolmente più complesso e coinvolto rispetto a quello di generare script PowerShell e altre forme di funzionalità e correzioni minori per le quali la codifica vibe è ben adatta.
* Si prega di notare che il paper si riferisce costantemente a ‘DeepThink R1′, che sembra essere inesistente, comparso solo in un pugno di riferimenti su Internet (presumibilmente da altri autori che hanno scritto male ‘DeepSeek R1)’. Se questo è il mio errore, si prega di contattarmi tramite i miei dettagli di profilo e lo correggerò.
† Enfasi degli autori, non mia.
Pubblicato per la prima volta mercoledì, 26 novembre 2025. Modificato alle 17:35 est per la formattazione.












