# FrontierCode Diamond: 13.4% di patch integrabili su 50 attività difficili (giugno 2026) > I risultati FrontierCode di giugno 2026: 13.4% sulle 50 attività difficili di Diamond e 51.8% su Extended; come esaminare una patch generata dall’IA. Source: https://ailoot.ai/blog/it/frontiercode-benchmark-mergeable-ai-code/ Canonical: https://ailoot.ai/blog/it/frontiercode-benchmark-mergeable-ai-code/ Language: it Publisher: Ailoot (https://ailoot.ai/) Translation: guide-173 Revision: sha256-95ac4c56e82959160e8988aced5f73d6bc89124ebd32af89c14a711f8610fdbe
Punto chiave L'8 giugno 2026, Cognition ha rilasciato FrontierCode, un benchmark che misura se il maintainer di un vero repository open source accetterebbe di integrare nel proprio progetto codice generato dall'IA. Il risultato principale: persino Claude Opus 4.8, il miglior modello del settore, supera solo il 13,4% dei 50 task più difficili. I benchmark più datati, come HumanEval e SWE-bench, misuravano «il codice funziona?», mentre quello nuovo misura «il maintainer accetterebbe questa PR?». Questo cambia la prospettiva per chiunque porti in produzione codice generato dall'IA.
Ulteriori materiali sulla configurazione degli strumenti sono disponibili nella [documentazione di Ailoot](https://ailoot.ai/docs/).
[Guide Ailoot](https://ailoot.ai/docs/)
## Che cos'è FrontierCode e perché è importante?
Punto chiave FrontierCode è un benchmark della qualità del codice generato dall'IA, creato da Cognition e pubblicato l'8 giugno 2026. Valuta se una patch soddisfa i criteri di integrazione del benchmark orientati ai maintainer. È un risultato definito del benchmark, non un tasso generale di prontezza produttiva per tutto il codice IA. Più di 20 maintainer di importanti progetti open source hanno dedicato oltre 40 ore a ciascun task per creare scenari che richiedono non solo correttezza, ma anche stile, sicurezza e test.
Cognition è l'azienda che ha creato Devin (il primo ingegnere IA autonomo, marzo 2024) e Windsurf (acquisita nel luglio 2025). Sta inoltre sviluppando una propria linea di modelli, SWE-1.x. Il benchmark è stato pubblicato sul blog pubblico all'indirizzo `cognition.com/blog/frontier-code`. Il cambiamento fondamentale non riguarda i nuovi numeri, ma **la scala con cui si misura**. Il benchmark ha tre livelli di difficoltà: **Extended** (150 task, l'intero set), **Main** (i 100 più difficili, incluso Diamond) e **Diamond** (50 task estremamente difficili). Cognition ha lasciato deliberatamente Diamond «in gran parte non saturo»: persino il modello migliore risolve meno del 15% dei task. L'obiettivo è lasciare al benchmark margine per un anno ed evitare che venga saturato in un mese, come accadde a HumanEval. ## Che cosa misura FrontierCode: «Il maintainer integrerebbe questa PR?»
Punto chiave FrontierCode valuta ogni soluzione su 6 assi: se la patch risolve il task, evita di compromettere altro codice, supera i controlli di build e lint, contiene test validi, rispetta l'ambito richiesto e presenta codice leggibile. Per essere considerata integrabile, una patch deve superare tutti e 6 gli assi. Se ne fallisce anche solo uno, la PR non verrà integrata. La valutazione passa così dai test automatici alla decisione di un maintainer reale.
I sei assi di valutazione (dal blog ufficiale di Cognition): 1. **Correttezza del comportamento** — la patch risolve il task? 2. **Sicurezza rispetto alle regressioni** — evita di compromettere il codice esistente? 3. **Pulizia meccanica** — supera i controlli di build, lint e stile? 4. **Correttezza dei test** — i test scritti dall'agente sono validi (i test che passano con qualsiasi codice non contano)? 5. **Ambito** — la patch evita di modificare file non richiesti? 6. **Qualità del codice** — il codice segue le convenzioni del progetto ed è leggibile? Perché una patch sia considerata integrabile, deve superare **tutti e sei gli assi**. Se ne fallisce anche solo uno, non verrà integrata. Questo è il cambiamento principale di prospettiva. «La correttezza ormai è un requisito minimo», afferma Cognition. Prima i benchmark chiedevano: «Il codice ha superato i test?». Ora chiedono: «Un vero tech lead lo integrerebbe nel progetto?». Cognition ha introdotto tre nuove tecniche di valutazione: - **Reverse-Classical**: un test scritto da un agente deve fallire su una versione del codice difettosa. Altrimenti, è un test fasullo. - **Code Scope**: un verificatore automatico controlla che una patch rispetti i file e il numero di righe concordati per il task. - **Adaptive Classical Grading**: lo strumento LLM «mutagent» adatta i test rigorosi a varianti valide della soluzione. ## Perché i vecchi benchmark non funzionano più?
Punto chiave HumanEval (Codex, 2021) e SWE-bench verificano se il codice supera test automatici. Non rilevano i casi in cui il test passa ma nessuno accetterebbe la PR: il codice è brutto, compromette moduli vicini o va oltre l'ambito del task. Nel marzo 2026, uno studio indipendente ha valutato 296 PR generate dall'IA provenienti da SWE-bench Verified con 4 maintainer reali: le decisioni dei maintainer erano in media 24 punti percentuali sotto il punteggio del valutatore automatico. Ciò significa che circa la metà delle PR «riuscite» non verrà integrata in un repository reale.
Gli agenti IA avevano già superato brillantemente HumanEval entro il 2024. SWE-bench Verified è molto simile: nell'agosto 2025, OpenAI ha riconosciuto pubblicamente il problema della contaminazione (i modelli avevano «visto» il dataset durante l'addestramento). I benchmark hanno perso la capacità di distinguere i modelli migliori. Lo studio che ha messo in discussione la vecchia unità di misura è uscito nel marzo 2026. Che cosa hanno fatto: - Hanno selezionato 4 maintainer attivi di 3 repository (scikit-learn, Sphinx, pytest). - Hanno chiesto loro di valutare 296 PR generate dall'IA da SWE-bench Verified: tutte queste PR avevano superato i test automatici. - Hanno confrontato le decisioni dei maintainer con quelle del valutatore automatico. In altre parole, il benchmark dice «superato», mentre il maintainer dice «non lo integro»: accade in media in un quarto dei casi. I 3 motivi principali di rifiuto, dal meno al più grave: 1. **Qualità del codice** — non segue lo stile del repository. 2. **Compromette altro codice** — danneggia il codice adiacente. 3. **Problemi con la funzionalità principale** — non risolve del tutto il task, anche se il test è verde. FrontierCode formalizza proprio questo problema. Cognition ha ripreso questa idea e l'ha ampliata, creando un benchmark completo con oltre 20 maintainer invece di 4. Un altro colpo alla vecchia impostazione arriva da uno studio del dicembre 2025 sulla sicurezza delle patch generate dall'IA. Secondo lo studio, il 61% delle soluzioni di SWE-Agent con Claude 4 Sonnet era funzionalmente corretto, ma solo il 10.5% era sicuro. Il codice supera il test, eppure una patch su due introduce una falla di sicurezza. I benchmark SWE-bench non possono rilevarlo: non misurano la sicurezza. FrontierCode prova almeno a intercettare il problema attraverso gli assi «pulizia meccanica» e qualità del codice. ## La classifica dei modelli: Opus 4.8 al 13.4%, GPT-5.5 al 6.3%
Punto chiave Cognition ha pubblicato una classifica di 12 modelli su tre subset. Claude Opus 4.8 di Anthropic è in testa su Diamond con il 13.4%. Seguono GPT-5.5 al 6.3%, Claude Opus 4.7 al 5.2% e Gemini 3.1 Pro di Google al 4.7%. Il miglior modello open-code è Kimi K2.6 di Moonshot, al 3.8%. Il modello SWE-1.6 di Cognition stessa è nella parte bassa della tabella, al 2.5%. È un argomento importante contro le accuse di autopromozione.
| Modello | Diamond (50) | Main (100) | Extended (150) | |---------------------------------|--------------|------------|----------------| | **Claude Opus 4.8** (Anthropic) | **13.4%** | 34.3% | 51.8% | | GPT-5.5 (OpenAI) | 6.3% | \- | \- | | Claude Opus 4.7 (Anthropic) | 5.2% | \- | \- | | Gemini 3.1 Pro (Google) | 4.7% | \- | \- | | GPT-5.4-mini (OpenAI) | 4.6% | \- | \- | | Kimi K2.6 (miglior modello open-code) | 3.8% | \- | \- | | Claude Sonnet 4.6 | 3.5% | \- | \- | | **SWE-1.6** (Cognition) | **2.5%** | \- | \- | | MiniMax M2.7 | 2.4% | \- | \- | | MiniMax M2.5 | 1.1% | \- | \- | | Kimi K2.5 | 1.0% | \- | \- | | Gemini 3.1 Flash Lite | 0.7% | \- | \- | Che cosa emerge dalla tabella: - **Un leader indiscusso.** Opus 4.8 di Anthropic è circa due volte più avanti del concorrente più vicino. Il divario, difficile da notare su SWE-bench, è evidente su FrontierCode. - **I modelli open non hanno ancora recuperato.** Kimi K2.6, il miglior modello open-code, ottiene il 3.8% su Diamond. È da 3 a 4 volte meno di Opus 4.8. Cognition non ha pubblicato una griglia completa per Kimi K2.6 su Main ed Extended, quindi non è ancora possibile confrontarli sull'intero set. - **Cognition ha inserito onestamente il proprio modello** nella parte bassa della classifica. Il subset Diamond è stato lasciato deliberatamente «non saturo». Cognition ha previsto un margine di sicurezza per gli anni a venire. Se i benchmark precedenti si saturavano in 12–18 mesi, FrontierCode è progettato per avere un limite superiore più alto. ## Che cosa significa «13% integrabile» per chi programma a intuito con Claude Code?
Punto chiave Nell’esecuzione Opus 4.8 riportata sulle 50 attività difficili selezionate di Diamond, il 13.4% delle patch soddisfa i criteri di integrazione e l’86.6% no. Non dimostra che tutte le patch rifiutate sembrassero corrette né che il tasso valga per il normale lavoro di progetto. Nella pratica del vibe coding, questo significa che quando si affrontano modifiche difficili non basta vedere un test verde e fare push. Le modifiche semplici in un progetto appena creato sono un'altra storia: l'IA le gestisce bene. Il confine tra «quando fare push e quando rifinire a mano» si è spostato.
Per prima cosa, è importante riformulare il dato: il set **Diamond** di FrontierCode è volutamente estremo. Nei task ordinari di un progetto startup appena avviato, senza quaranta moduli dipendenti, un agente IA ottiene risultati sensibilmente migliori. Lo stesso Opus 4.8 raggiunge il 51.8% di patch integrabili su Extended (150 task, l'intero set). È un quadro completamente diverso. Il 51.8% riguarda il set Extended di 150 attività. Supera il risultato Diamond, ma nessuno dei due stima l’integrabilità delle patch di ogni modello sulle tue attività. Punteggi Main o Extended mancanti per altri modelli non autorizzano a inventarne le prestazioni. Che cosa significa per chi programma a intuito e porta il codice in produzione: - **Un test verde non significa più «pronto per l'integrazione».** I test scritti dalla stessa IA potrebbero essere inutili: passano con qualsiasi codice. FrontierCode lo misura direttamente tramite Reverse-Classical: se un test non fallisce su una versione difettosa, non conta. - **Lo stile e le convenzioni del repository contano.** Se un progetto segue uno schema consolidato e l'IA non lo rispetta, un collaboratore reale non accetterà la modifica. Nei progetti personali senza regole non è un grosso problema. In un team, è il problema numero uno. - **I test non risolvono i problemi di sicurezza.** Ricorda il dato citato sopra: solo il 10.5% delle patch è sicuro, nonostante il 61% sia corretto. La sicurezza va verificata separatamente, con strumenti che rilevano token, file `.env` e password predefinite. - **Andare oltre il task è un errore tipico dell'IA.** Le chiedi di correggere una funzione di autorizzazione e ottieni una patch che ha anche riscritto il livello interno e il logging. È uno dei 6 assi di FrontierCode.
[Guide Ailoot](https://ailoot.ai/docs/)
## Quali 6 categorie di errori commette l'IA nei task difficili?
Punto chiave I 6 assi di FrontierCode corrispondono a 6 tipi di errori che gli agenti IA commettono regolarmente. Sono schemi prevedibili di risultati scadenti. Se prendi una patch a caso di Claude o Codex e la valuti secondo questi 6 assi, un vero tech lead non l'accetterà se anche uno solo dei criteri non è soddisfatto. Per portare codice in produzione con fiducia, devi verificare personalmente questi 6 assi prima dell'integrazione.
Esaminiamo ogni asse in parole semplici: **1. Correttezza del comportamento — la patch risolve il task?** È l'asse più basilare. Spesso l'IA scrive codice che **sembra** una soluzione, ma risolve il problema sbagliato. Le chiedo di «aggiungere una conferma di lettura al messaggio» e ottengo una funzione `markAsRead`, che però non è stata collegata al componente della chat. Il test della funzione passa. Il task aziendale non è stato risolto. **2. Sicurezza rispetto alle regressioni — evita di compromettere il codice adiacente?** L'IA modifica un modulo e un altro smette di funzionare. Il caso più comune: un agente IA modifica la firma di una funzione, dimenticando che viene chiamata da altri 17 punti. SWE-bench non può rilevarlo: esegue test solo per un file. FrontierCode, invece, esegue **l'intera suite di test del repository**. **3. Pulizia meccanica — supera i controlli di build, lint e stile?** L'IA può produrre codice che compila in locale ma non supera la CI: un import mancante, tabulazioni al posto degli spazi, due spazi finali o un errore in `eslint.config.js`. In un progetto attivo, lo stile non è un capriccio: è una regola del team. **4. Correttezza dei test — i test scritti dall'IA sono validi?** È l'asse più insidioso. L'IA scrive un test che passa, ma **passa con qualsiasi codice, anche con codice difettoso**. L'ho visto succedere tante volte: il test verifica «lo script è andato in errore?», ma non «ha restituito il risultato corretto?». Reverse-Classical di FrontierCode rileva proprio questo caso. **5. Ambito — la patch evita di modificare file non pertinenti?** Le chiedo di correggere una funzione e ottengo una patch per 12 file, compresi file che non c'entrano con il task. È proprio quella «iniziativa» dell'IA che danneggia un progetto di produzione modificando cose che non le avevo chiesto di toccare. In FrontierCode, questo asse è un requisito imprescindibile. **6. Qualità del codice — il codice segue le convenzioni del repository?** L'IA scrive una funzione «da zero» invece di usare gli helper esistenti in `lib/`. Oppure dà alle variabili nomi diversi da quelli dello stile del progetto. O mette la logica nel livello architetturale sbagliato. Dal punto di vista dei test, tutto funziona. Dal punto di vista del tech lead, la patch non verrà integrata. ## Come verificare il codice dell'IA prima del push: 5 passaggi
Punto chiave Una lista di controllo in 5 passaggi che copre i 6 assi di FrontierCode e un controllo di sicurezza. Seguila per ogni patch di Claude o Codex prima del rilascio. I passaggi sono pochi e richiedono pochi minuti ciascuno. Ne vale la pena: dedica 10 minuti alla lista invece di 4 ore a ripristinare un progetto di produzione con git rewind e a recuperare il database da un backup.
1. ### Esegui l'intera suite di test, non solo quelli relativi alla modifica Spesso l'IA modifica codice oltre i limiti del task. Il problema emergerà nei test dei moduli vicini. Eseguo l'intera suite di test (con il singolo comando `npm test`, senza un percorso), non solo i test di un file specifico. Nei progetti grandi è comodo farlo in parallelo usando un git worktree (vedi [Git worktree in Claude Code](https://ailoot.ai/blog/it/claude-code-git-worktree/)). 2. ### Esegui i controlli di lint, stile e tipi Tre comandi in quest'ordine: `eslint .`, `prettier --check .`, `tsc --noEmit`. Un agente IA può non accorgersi sia delle tabulazioni sia di uno spazio finale in più. Se il progetto prevede controlli rigorosi, eseguili in locale prima del rilascio. 3. ### Verifica il test stesso È il più importante dei 5 controlli. Faccio una piccola «rottura» nel codice (cambio `return true` in `return false`). Il test dovrebbe fallire. Se il test **non fallisce**, l'IA lo ha scritto solo per finta e non serve a nulla. Elimino il test e chiedo all'IA di riscriverlo imponendo una condizione: il test deve fallire sulla versione difettosa. 4. ### Controlla quali file ha modificato l'IA Il comando `git diff --stat` mostra quali file sono cambiati e quante righe. Se in risposta a «correggi il modulo dei contatti» l'IA ha modificato 12 file, è andata oltre l'ambito del task. Ripristino le modifiche extra usando un singolo comando per file. 5. ### Esegui un controllo di sicurezza con una skill già pronta I test non rilevano le iniezioni SQL né le password codificate direttamente nel codice. Uso una skill di sicurezza già pronta per Claude Code (vedi 754 skill di sicurezza già pronte). Come minimo, cerco manualmente nel progetto le parole «password», «secret» e «key» e verifico che `.env.example` sia completo. Tutti e 5 i passaggi coprono 5 dei 6 assi di FrontierCode (1–5). Il sesto asse, la qualità del codice, viene verificato automaticamente con il lint e con una revisione umana. ## Che cosa migliora davvero le probabilità di ottenere codice integrabile?
Punto chiave FrontierCode descrive il problema. La soluzione sta nella metodologia di lavoro con l'IA: cambiare modello, da solo, non fa praticamente alcuna differenza. Fanno la differenza tre pratiche: regole del progetto, mappa del progetto e context engineering. Senza queste, persino Opus 4.8 produce spazzatura plausibile. Queste pratiche offrono vincoli più chiari, ma le modifiche difficili richiedono ancora controlli e revisione del repository prima dell’integrazione.
In un progetto non preparato, un agente IA vede **solo il file che hai aperto per lui**. Non conosce la cronologia delle decisioni, le convenzioni né la mappa dei moduli. Per le modifiche semplici non è un grosso problema. Per modifiche difficili la mancanza di contesto del progetto è un rischio da affrontare. Il 13.4% del benchmark non ne isola la qualità come causa. Che cosa devi fare per trasformare quel 13% in qualcosa che puoi davvero portare in produzione: **1. Regole del progetto — così l'IA riproduce il tuo ragionamento invece della media di Internet.** È un insieme delle tue soluzioni già pronte, abitudini e regole apprese, in un formato che l'agente IA legge a ogni richiesta. Quando ci sono più di 30 regole, l'IA smette di inventare la «media del settore» e comincia a proporre soluzioni nel tuo stile. Si può evitare che vada oltre l'ambito del task con una sola riga nelle regole: «non modificare file diversi da quelli indicati esplicitamente nella richiesta». **2. Una mappa del progetto — una cartella che descrive il progetto.** Qui inserisci prodotti, pubblico, economia, metriche e configurazioni. Prima di ogni richiesta, l'agente IA legge l'indice e capisce **su quale parte dell'attività sta lavorando**. Questo affronta automaticamente due dei motivi di rifiuto elencati sopra: stile e codice compromesso. **3. Context Engineering — gestire ciò che l'IA vede prima della richiesta.** Non si tratta di «come formulare un prompt», ma di «che cosa inserire nella finestra di contesto PRIMA del prompt». CLAUDE.md, prerequisiti e link mirati ai file. Questo aiuta a evitare errori di correttezza del comportamento e qualità del codice. Usa questa combinazione per preparare i controlli, non come prova che cinque assi siano già superati. Prima di accettare la patch, verifica su quella effettiva comportamento, regressioni, test, ambito e qualità del codice. Un ulteriore livello è costituito dagli agenti di revisione: - **Cursor Bugbot** — esegue una revisione su ogni PR. Secondo Cursor, lo strumento elabora circa 2 milioni di PR al mese. - **Sottoagenti annidati in Claude Code v2.1.172** — un agente scrive il codice, un secondo lo revisiona e un terzo esegue i test. È la stessa idea di FrontierCode: separare i ruoli di «autore» e «tech lead». Vedi anche: [Vibe Coding Security](https://ailoot.ai/blog/it/vibe-coding-security/), [Come configurare Claude Code affinché non danneggi il tuo progetto di notte](https://ailoot.ai/blog/it/claude-code-safe-overnight-setup/) e Context Engineering come concetto.
### Fonti - [Cognition - Introducing FrontierCode (8 giugno 2026)](https://cognition.com/blog/frontier-code) - [Cursor Bugbot - Code Review Agent](https://cursor.com/bugbot)
Per ulteriori materiali sul lavoro con gli strumenti, consulta la [documentazione di Ailoot](https://ailoot.ai/docs/).
[Guide Ailoot](https://ailoot.ai/docs/)
[Vai ad Ailoot](https://ailoot.ai/)
## Domande frequenti ### 13.4% significa che solo quella quota di tutto il codice IA è pronta per la produzione? No. È il risultato riportato per Opus 4.8 sulle 50 attività difficili selezionate di FrontierCode Diamond. La stessa tabella indica 51.8% sul set Extended di 150 attività: nessuno dei due tassi misura tutto il codice generato dall’IA. ### Perché un test superato non basta a integrare una patch? Il benchmark controlla anche regressioni, build e stile, capacità dei test di rilevare un’implementazione difettosa, ambito e qualità del codice. Esamina il diff e applica i controlli di accettazione del repository: un test verde non dimostra tutti questi requisiti. ## Ailoot · L’azienda e il suo portafoglio di progetti Ailoot si basa su un’esperienza operativa consolidata, un’ampia base di clienti, un servizio stabile e un controllo costante dei KPI. L’azienda e il suo portafoglio di progetti: milioni di clienti; vendite nell’ordine dei miliardi ogni mese. Ailoot mette questa esperienza operativa al servizio dell’accesso API alle funzioni AI nei prodotti dei clienti, negli agenti, nelle applicazioni e nelle automazioni.