Miglior modello AI per programmare

Scegliere un modello AI per programmare è uno dei pochi casi in cui i benchmark pubblici sono davvero pertinenti — e allo stesso tempo uno di quelli in cui vengono letti peggio.

Il motivo è che questi test non misurano il modello: misurano la coppia strumento più modello. E cambiare l'uno o l'altro cambia il risultato in modo sostanziale.

I benchmark pertinenti

SWE-bench valuta i modelli su problemi reali presi da progetti open source: si dà la descrizione del problema e il codice, e il modello deve produrre una modifica che superi i test. È il test più vicino al lavoro vero, perché richiede di capire dove intervenire in una base di codice articolata.

La variante verificata esclude i casi ambigui o non risolvibili con le informazioni date, ed è quella su cui i confronti hanno più senso. Il funzionamento è spiegato in SWE-bench e i benchmark di coding.

I benchmark agentici come Frontier-Bench misurano compiti multi-passo eseguiti in ambiente isolato. Sono pertinenti se stai valutando un agente di sviluppo che esegue, corregge e riprova, non un semplice completamento. Il dettaglio è in Frontier-Bench: cos'è e cosa misura.

Cosa i benchmark non misurano

È il limite più importante da tenere presente, perché riguarda esattamente ciò che determina se il codice prodotto sarà un aiuto o un problema fra sei mesi.

La colonna di destra richiede giudizio umano e nessun test automatico la copre. È il motivo per cui la valutazione finale va fatta leggendo il codice prodotto, non guardando una percentuale.

C'è poi un secondo limite: i progetti usati nei benchmark sono pubblici, quindi parte di quel materiale può essere finita nei dati di addestramento. Le versioni curate cercano di limitare il fenomeno, ma la cautela resta giustificata.

Quale fascia serve

Il coding è uno dei pochi ambiti in cui la fascia alta si giustifica con una certa regolarità, perché il compito è genuinamente complesso: capire una base di codice, individuare il punto giusto, produrre una modifica coerente con il resto.

La colonna di destra vale la pena tenerla presente: in un flusso di lavoro reale una buona parte delle richieste sono di quel tipo, e usare la fascia alta per tutte è uno spreco. Un'impostazione a due livelli funziona anche qui.

La prova sul proprio codice

• Prendi dieci problemi reali già risolti dal tuo team
• Includi almeno tre interventi su codice esistente, non solo file nuovi
• Dai a ogni modello lo stesso materiale e lo stesso strumento
• Confronta con la soluzione vera adottata dal team
• Valuta la leggibilità, non solo se funziona
• Conta i tentativi necessari per arrivarci

Il secondo punto è quello che distingue una prova utile da una inutile. Scrivere una funzione da zero è un compito che tutti i modelli moderni svolgono bene; modificare codice esistente con convenzioni e stranezze accumulate negli anni è il lavoro vero, ed è lì che le differenze emergono.

Il sesto punto ha anche un risvolto economico: un modello che costa il doppio ma risolve in un tentativo invece di quattro conviene. È il ragionamento sviluppato in costo per task o prezzo per token.

Errori da evitare

• Confrontare punteggi ottenuti con impalcature diverse.
• Confondere le varianti del benchmark senza dirlo.
• Dedurre la qualità del codice da una percentuale.
• Provare solo su file nuovi invece che su codice esistente.
• Usare la fascia alta per tutto, anche per i completamenti.
• Non contare i tentativi nel calcolo del costo.

Cosa dichiarano i produttori

Vale la pena riportare le affermazioni ufficiali attribuendole, perché sono dati auto-riportati e non verifiche indipendenti.

Nell'annuncio di Claude Opus 5 del 24 luglio 2026, Anthropic dichiara risultati allo stato dell'arte su Frontier-Bench e cita CursorBench 3.2 al massimo livello di ragionamento, riportando un risultato entro lo 0,5% dal picco di Fable 5 a circa metà costo. Sullo stesso benchmark agentico Frontier-Bench v0.1, dichiara di più che raddoppiare il risultato di Opus 4.8 a un costo per task inferiore.

Due osservazioni. La prima: il dato sul costo per task è raro e utile, perché per un team di sviluppo conta quanto il punteggio. La seconda: sono confronti interni o con la concorrenza pubblicati dal produttore, quindi vanno usati per orientarsi e non per decidere.

Le documentazioni ufficiali indicano inoltre un elemento pratico rilevante per il coding: tutti i principali modelli espongono un livello di ragionamento regolabile. Su compiti di sviluppo articolati alzarlo migliora sensibilmente i risultati, ma aumenta costo e tempo — e su un completamento breve non serve a nulla.

Le fasce e i prezzi, per il coding

Prezzi in dollari per milione di token, verificati il 19 agosto 2026 per Anthropic e OpenAI e il 3 settembre 2026 per Google sul piano Standard.

Il coding ha una caratteristica economica particolare: il contesto è grande. Passare i file pertinenti significa migliaia di token di input a ogni richiesta, e su un team che lavora tutto il giorno il conto sale in fretta.

Il rischio del codice che sembra giusto

C'è un modo specifico in cui l'AI applicata allo sviluppo produce danni, ed è diverso dal semplice errore.

Un modello che genera codice palesemente rotto non fa danni: il test fallisce, qualcuno se ne accorge, si corregge. Un modello che genera codice che funziona sui casi previsti ma sbaglia su quelli non testati produce un problema che emergerà in produzione, magari mesi dopo.

• Chiedi sempre di spiegare la modifica, non solo di farla
• Verifica i casi limite che i test esistenti non coprono
• Diffida delle modifiche che toccano molti file in un colpo
• Fai revisionare da una persona ciò che va in produzione
• Chiedi di segnalare le assunzioni fatte

L'ultimo punto è quello che intercetta più problemi. Un modello che dichiara «ho assunto che questo campo sia sempre presente» ti sta dando l'informazione che serve per verificare. Uno che non lo dichiara ha fatto la stessa assunzione senza dirtelo.

Esempi pratici

Completamento assistito. Il modello suggerisce mentre si scrive. Latenza critica, contesto limitato, compito relativamente semplice: è il caso in cui la fascia leggera è la scelta corretta, perché un suggerimento che arriva dopo tre secondi non serve a nessuno.

Assistente conversazionale. Si descrive un problema e si discute la soluzione. Latenza tollerabile, ragionamento richiesto: fascia intermedia o alta, con il livello di ragionamento alzato sui problemi difficili.

Agente autonomo. Il modello riceve un compito, esplora il codice, modifica, esegue i test e corregge fino a chiudere. È il caso che richiede di più ed è anche quello in cui i benchmark agentici sono pertinenti. Qui la latenza si moltiplica per il numero di passaggi, quindi va messo in conto che un'esecuzione duri minuti.

Un team maturo li usa tutti e tre, con modelli diversi. Trattarli come lo stesso problema e sceglierne uno solo è il modo più comune di spendere troppo e ottenere poco.

Come applicarlo in azienda

Per un team di sviluppo il percorso ha tre passaggi, e il primo è quello che quasi nessuno fa.

Separa i tre modi d'uso. Completamento assistito mentre si scrive, assistente conversazionale su problemi da discutere, agente autonomo che esegue e corregge. Sono compiti diversi con requisiti opposti: il primo ha bisogno di velocità, il terzo di capacità. Trattarli come un unico problema e scegliere un solo modello fa spendere troppo e ottenere poco.

Prova sul tuo codice. Dieci problemi reali già risolti dal team, di cui almeno tre interventi su codice esistente e non file nuovi. Scrivere una funzione da zero è un compito che tutti i modelli moderni svolgono bene; modificare codice con convenzioni e stranezze accumulate negli anni è il lavoro vero, ed è lì che le differenze emergono.

Valuta due cose separatamente. Se il codice funziona e se è codice che accetteresti in revisione. Solo la prima la misura un benchmark; la seconda decide se il risultato sarà un aiuto o un problema fra sei mesi.

Sul piano economico, il coding ha una caratteristica specifica: il contesto è grande, perché vanno passati i file pertinenti. Uno strumento che seleziona i tre file giusti costa una frazione di uno che manda l'intero progetto e produce anche risposte migliori — è il ragionamento di finestra di contesto: quanto conta davvero.

Infine, conta i tentativi: un modello che costa il doppio ma chiude al primo colpo invece che al quarto conviene, secondo il calcolo di costo per task o prezzo per token. E ricorda che i benchmark misurano la coppia strumento-modello, come spiegato in SWE-bench e i benchmark di coding: se il tuo strumento non permette di eseguire i test e correggersi, non otterrai il comportamento riportato in classifica.

Se vuoi integrare l'AI nel flusso di sviluppo della tua azienda, Giallo Studio progetta soluzioni su misura e le mette in produzione.

Conclusione

Per programmare, i benchmark pubblici sono pertinenti ma vanno letti sapendo che misurano la coppia strumento più modello. Un punteggio ottenuto con un'impalcatura che permette di eseguire i test non si trasferisce a uno strumento che non lo consente.

E resta il limite di fondo: nessun test automatico misura leggibilità, manutenibilità e rispetto delle convenzioni — cioè le proprietà che decidono se il codice prodotto sarà un aiuto o un problema. Quelle si valutano leggendo.

Se vuoi integrare l'AI nel flusso di sviluppo della tua azienda, Giallo Studio progetta soluzioni su misura e le mette in produzione.

Schema consigliato: Article + FAQPage + BreadcrumbList