🤖 machine learning

IDE-Bench: Evaluating Large Language Models as IDE Agents on Real-World Software Engineering Tasks

IDE-Bench introduce un framework di valutazione completo e Dockerizzato che presenta 80 task attraverso otto repository mai pubblicati prima, per valutare le capacità degli agenti AI per IDE in compiti di ingegneria del software reali e multi-linguaggio attraverso un'interfaccia di strumenti strutturata e nativa per l'IDE.

Autori originali: Spencer Mateega, Jeff Yang, Tiana Costello, Shaurya Jadhav, Nicole Tian, Agustin Garcinuño

Pubblicato 2026-02-02

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Spencer Mateega, Jeff Yang, Tiana Costello, Shaurya Jadhav, Nicole Tian, Agustin Garcinuño

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di assumere un nuovo sviluppatore junior per lavorare sul tuo progetto software. Vuoi sapere se è effettivamente in grado di fare il lavoro: trovare bug, aggiungere nuove funzionalità e correggere codice rotto senza rompere tutto il resto.

Per molto tempo, abbiamo testato gli assistenti di programmazione AI dandogli un singolo enigma da risolvere in una stanza vuota. Ma lo sviluppo software reale non è un enigma in una stanza; è come lavorare in un laboratorio frenetico e tecnologicamente avanzato, pieno di strumenti, progetti e altri lavoratori.

IDE-Bench è un nuovo "laboratorio" progettato per testare i modelli AI esattamente come verranno utilizzati nel mondo reale. Ecco la ripartizione di ciò che il documento ha scoperto, utilizzando analogie semplici.

1. Il nuovo test: dal "carta e penna" al "laboratorio completo"

I test precedenti (come SWE-Bench) erano come dare a uno studente un problema di matematica su un foglio di carta e chiedergli di scrivere la risposta. Non potevano usare una calcolatrice o cercare formule; dovevano solo indovinare la risposta basandosi su ciò che avevano memorizzato.

IDE-Bench è diverso. Fornisce all'AI un laboratorio Dockerizzato (una stanza digitale sicura e isolata) e un set completo di strumenti, proprio come quelli che gli sviluppatori usano in app come Cursor o Windsurf.

Gli Strumenti: L'AI può cercare nel codice, leggere file, modificare righe, eseguire test e persino controllare database.
L'Obiettivo: L'AI deve agire come un vero ingegnere. Non può limitarsi a indovinare; deve esplorare, apportare modifiche, controllare se funzionano e correggere gli errori se rompono qualcosa.

2. I "Libri di Ricette" Segreti

Per assicurarsi che l'AI non abbia semplicemente memorizzato le risposte da internet, i ricercatori hanno creato 80 nuovi compiti attraverso 8 codebase segrete.

L'Analogia: Immagina una competizione culinaria in cui i giudici creano 8 ricette brandamente nuove e mai viste prima. I concorrenti (i modelli AI) devono cucinarle. Poiché queste ricette non sono mai state pubblicate online, l'AI non può barare cercando la soluzione nei suoi dati di addestramento.
La Varietà: Le ricette coprono diverse "cucine" (linguaggi di programmazione): C/C++ (programmazione di sistema), Java (applicazioni enterprise) e MERN (applicazioni web moderne).

3. I Risultati: Chi è lo Chef Maestro?

I ricercatori hanno testato 15 diversi modelli AI. Ecco cosa hanno scoperto:

Il Livello Top (Gli Chef Maestri): Alcuni modelli, guidati da GPT-5.2, hanno risolto circa il 95% dei compiti. Erano come chef che potevano leggere la ricetta, prendere gli strumenti giusti e cucinare il piatto perfettamente al primo colpo.
Il Livello Medio (I Cuochi Competenti): Modelli come Claude Sonnet e Claude Haiku hanno risolto circa l'85–88% dei compiti. Sono molto bravi, ma potrebbero aver bisogno di un secondo tentativo per ottenere la perfezione.
Il Livello Base (I Novizi): Molti modelli open-source hanno faticato, risolvendo meno del 50% dei compiti. Spesso si sono persi nel laboratorio o hanno rotto il codice mentre cercavano di ripararlo.

4. Il Problema dell' "Essere Quasi Arrivati"

Uno dei risultati più interessanti è che i punteggi binari (Pass/Fail) nascondono molta sfumatura.

L'Analogia: Immagina uno studente che sostiene un esame e risponde correttamente a 11 domande su 12. In un sistema di valutazione rigoroso, prende un "F" perché non ha ottenuto il 100%.
La Realtà: In IDE-Bench, molti modelli hanno centrato il cuore del codice ma sono falliti a causa di dettagli minuscoli, come una virgola mancante o un formato leggermente errato. Il documento chiama questi casi "near misses" (quasi successi).
La Lezione: Un modello potrebbe essere al 90% della soluzione, ma se manca i piccoli dettagli, il test lo segna come un fallimento totale. Ciò suggerisce che, per l'uso nel mondo reale, potremmo non dover buttare via il codice e ricominciare da capo; potremmo solo aver bisogno di un essere umano per correggere i piccoli errori di formattazione.

5. Efficienza vs. Accuratezza

Il documento ha anche esaminato quanto fosse "costoso" per l'AI risolvere un compito (misurato in "token", ovvero parole di pensiero).

Il Veloce e il Poco Costoso: Alcuni modelli (come Grok 4.1 Fast) erano molto efficienti. Risolvevano i compiti rapidamente e utilizzavano meno risorse, ma fallivano più spesso.
Il Lento e l'Approfondito: Altri modelli (come Claude Opus) richiedevano molto tempo, leggevano molti file e pensavano profondamente. Erano più propensi al successo, ma costavano molto di più in termini di tempo e potenza di calcolo.
La Conclusione: Non esiste un unico modello "migliore". Se vuoi velocità e basso costo, ne scegli uno tipo. Se hai bisogno di alta affidabilità e non ti dispiace il costo, ne scegli un altro.

6. Come Falliscono

I ricercatori hanno categorizzato il modo in cui i modelli AI falliscono, che è come un meccanico che diagnostica perché un'auto non parte:

Modifica Prematura (63% dei fallimenti): L'AI ha iniziato a modificare il codice prima ancora di aver capito il progetto. Era come cercare di riparare il motore di un'auto senza prima aprire il cofano.
Thrashing (28%): L'AI continuava a cambiare lo stesso file avanti e indietro, annullando il proprio lavoro, come una persona che non riesce a decidere quale strada prendere e continua a camminare in cerchio.
Perdita di Contesto (27%): L'AI ha dimenticato cosa doveva fare a metà del compito, come uno chef che inizia a cucinare una torta ma dimentica che doveva preparare una pizza.

Riassunto

IDE-Bench dimostra che i migliori modelli AI sono ora in grado di agire come veri ingegneri del software in un ambiente complesso e ricco di strumenti. Tuttavia, mostra anche che:

La specializzazione conta: Alcuni modelli sono ottimi per le web app ma scarsi per il codice di sistema a basso livello.
La perfezione è difficile: Arrivare al 99% è comune, ma l'ultimo 1% (i dettagli minuscoli) è dove la maggior parte dei modelli fallisce.
La strategia è importante: Il miglior approccio potrebbe essere quello di usare un modello "veloce" prima, e se fallisce, passare a un modello "approfondito" per finire il lavoro.

Il documento conclude che dobbiamo smettere di guardare a un singolo "punteggio" per giudicare l'AI e iniziare a guardare a come lavorano, in cosa sono bravi e quanto costa completare il lavoro.

Riepilogo Tecnico: IDE-Bench

Definizione del Problema

La rapida adozione di IDE abilitati ad agenti (ad es., Cursor, GitHub Copilot) ha trasformato i flussi di lavoro dell'ingegneria del software, eppure gli benchmark esistenti non riescono a valutare rigorosamente i Large Language Models (LLM) in questo specifico contesto. Gli attuali benchmark come SWE-Bench si affidano al recupero di un contesto statico e a paradigmi single-shot, mentre Terminal-Bench si concentra su comandi shell grezzi. Nessuno dei due cattura la natura interattiva, basata su strumenti e multi-step degli agenti IDE moderni che utilizzano l'editing strutturato dei file, la ricerca nel codebase e il testing full-stack. Inoltre, molti benchmark esistenti soffrono di contaminazione dei dati di addestramento, poiché i task sono spesso derivati da repository GitHub pubblici che i modelli futuri potrebbero aver memorizzato. Esiste una critica necessità di un framework che valuti gli agenti su task di ingegneria del software reali e non contaminate utilizzando un'interfaccia di strumenti nativa per l'IDE che rispecchi gli effettivi ambienti di sviluppo.

Metodologia

IDE-Bench è un framework completo progettato per valutare gli agenti IDE IA su task di ingegneria del software reali attraverso un harness di test containerizzato e Dockerizzato.

1. Design del Benchmark e Dati

Repository: Il benchmark consiste di 80 task distribuiti su 8 nuovi repository. Questi repository non sono mai stati pubblicati su Internet, GitHub o qualsiasi piattaforma pubblica per prevenire la contaminazione dei dati di addestramento.
Stack Tecnologici: I task spaziano in diversi scenari di produzione moderni, inclusi stack C/C++, Java (Javalin/Thymeleaf) e MERN (MongoDB, Express, React, Node.js).
Tipi di Task: I task rispecchiano i flussi di lavoro quotidiani degli sviluppatori, inclusi l'implementazione di funzionalità, la correzione di bug, il refactoring di sistemi legacy e l'ottimizzazione delle prestazioni. Spesso comportano requisiti sottospecificati, debugging multi-file e formattazione dell'output rigorosa.
Struttura di Valutazione: Ogni task include una descrizione, una patch di riferimento (task diff.txt) e una suite di test (task tests.py). La diff è nascosta all'agente durante l'esecuzione.

2. L'Ambiente dell'Harness

L'harness di valutazione simula un ambiente IDE basato su chat (simile a Cursor o Windsurf) utilizzando LiteLLM per l'integrazione del modello e Docker per l'esecuzione isolata.

Interfaccia degli Strumenti: Gli agenti sono dotati di 17 strumenti categorizzati in cinque gruppi, seguendo la specifica di funzione calling di OpenAI:
1. File System & Navigazione del Codice: read_file, list_dir, codebase_search, grep_search, file_search, delete_file.
2. Editing del Codice: edit_file, search_replace, write_file.
3. Esecuzione & Testing: run_terminal_cmd.
4. Testing Full-Stack (specifico per MERN): api_call, database_query, websocket_test, ui_test.
5. Strumenti Specializzati: edit_notebook, web_search, create_diagram (disponibili ma non sempre utilizzati).
Sicurezza: Gli agenti sono bloccati dall'impossibilità di leggere i file di test o le soluzioni ground-truth, costringendoli a ragionare esclusivamente dai requisiti del task.
Workflow: L'agente utilizza iterativamente gli strumenti per esplorare, modificare e testare. Le esecuzioni sono limitate a 100 iterazioni. Il successo è determinato dall'esecuzione di ./run tests.sh e dal confronto delle modifiche apportate dall'agente con la patch di riferimento.

3. Metriche

Il benchmark riporta:

Tasso di Risoluzione del Task (pass@k): La frazione di task risolti in almeno uno di $k$ tentativi indipendenti (specificamente pass@1 e pass@5).
Tasso di Passaggio per Singolo Test: Analisi granulare di quanti singoli test passano, identificando i "near misses" (quasi successi).
Efficienza: Consumo di token per task completato con successo e conteggio delle iterazioni.
Analisi Comportamentale: Sequenze di chiamate agli strumenti, rapporti tra esplorazione ed exploitation, e tassonomie dei modi di fallimento (ad es., editing prematuro, thrashing, perdita di contesto).

Contributi Chiave

Interfaccia Strutturata Nativa per l'IDE: A differenza dei benchmark precedenti, IDE-Bench valuta gli agenti utilizzando le stesse astrazioni di alto livello (ricerca, editing strutturato, testing full-stack) che definiscono il paradigma moderno degli agenti-IDE.
Repository Non Contaminati: La creazione di otto repository inediti assicura che i risultati della valutazione riflettano reali capacità di ragionamento piuttosto che la memorizzazione di dataset pubblici.
Correlazione Sistematica tra Intento e Risultato: Il framework è il primo a correlare sistematicamente l'intento riportato dall'agente con le modifiche di progetto andate a buon fine in un ambiente multi-linguaggio e full-stack.
Analisi Comportamentale Completa: Il benchmark fornisce metriche dettagliate sull'efficienza delle iterazioni, sui pattern di utilizzo degli strumenti e sui modi di fallimento, offrendo approfondimenti che vanno oltre i semplici tassi pass/fail.

Risultati

Il paper ha valutato 15 modelli attraverso 6.000 esecuzioni (80 task × 5 tentativi × 15 modelli).

Stratificazione delle Prestazioni

Livello Top: GPT-5.2 ha ottenuto le prestazioni più elevate con il 95.00% pass@5. Un cluster di modelli che include Claude Sonnet 4.5, Claude Haiku 4.5, Claude Opus 4.5 e GPT-5.1 Codex Max lo ha seguito da vicino, con range compresi tra l'85.00% e l'88.75% pass@5.
Livello Medio: Modelli come Gemini 3 Pro Preview (80.00%), Qwen3 Max (76.25%) e DeepSeek V3.2 (71.25%) hanno mostrato prestazioni moderate.
Livello Inferiore: I modelli a pesi aperti come le varianti di Llama 4 e Command-R+ hanno faticato significativamente, con tassi pass@5 inferiori al 10%.

Osservazioni Chiave

Affidabilità al Primo Tentativo: Claude Sonnet 4.5 è guidato nel pass@1 (87.50%), suggerendo un'alta stabilità. I modelli al di sotto della soglia dell'85% pass@5 mostrano guadagni significativi con i tentativi (ad es., DeepSeek V3.2 è migliorato di 40 punti dal pass@1 al pass@5), indicando un comportamento inconsistente e dipendente dalle iterazioni.
Specializzazione del Task: Le classifiche aggregate nascondevano variazioni significative. Ad esempio, sul task Event Callback System task-4 (TypeScript async), GPT-5.2 e Codex Max hanno ottenuto il 100% di successo, mentre i modelli Claude e Gemini hanno ottenuto lo 0%. Ciò evidenzia che la competenza in framework specifici (ad es., navigazione web Java, sicurezza della memoria C++) è più critica delle classifiche globali per implementazioni specifiche.
Efficienza vs Successo: Il tasso di successo e il costo computazionale non sono strettamente correlati. Grok 4.1 Fast è stato il più efficiente in termini di token (0.37 score di efficienza) ma ha avuto tassi di successo inferiori, mentre Claude Opus ha ottenuto un'alta copertura a un costo di token molto più elevato.
Modi di Fallimento: Il fallimento più comune è stato l'Editing Prematuro (63.0% dei fallimenti), dove gli agenti hanno modificato il codice prima di esplorare sufficientemente il codebase. I modelli frontier tendevano a fallire a causa di Perdita di Contesto o Thrashing in loop lunghi, mentre i modelli a pesi aperti fallivano agendo troppo presto.
Near Misses: Molti modelli hanno ottenuto alti tassi di passaggio per singolo test (ad es., >90%) ma hanno ricevuto lo 0% di credito sotto il pass@5 a causa di errori minori di formattazione o casi limite, suggerendo che la precisione della specifica è spesso più difficile della correttezza algoritmica.

Significato e Rivendicazioni

Il paper sostiene che IDE-Bench fornisce una guida pratica per le attuali integrazioni IDE e stabilisce obiettivi concreti per la prossima generazione di agenti di ingegneria del software.

Oltre le Classifiche: Gli autori sostengono che le classifiche a numero singolo siano insufficienti. Le decisioni di deployment devono tenere conto della specializzazione del task (ad es., indirizzare i task TypeScript a GPT-5.2 e i task Java a modelli specifici), dell'efficienza dei costi e della coerenza (prevedibilità).
Prontezza per la Produzione: Lo studio identifica una soglia dell'85% pass@5 come un divisore naturale tra modelli pronti per la produzione (stabili, successo al primo tentativo) e quelli che richiedono molteplici tentativi, che possono non essere adatti ad ambienti di produzione deterministici.
Limiti della Valutazione Binaria: Il paper evidenzia come i "fallimenti" nei benchmark siano spesso "near misses" in cui l'agente ottiene la sostanza ma manca le specifiche rigorose. Ciò implica che il deployment nel mondo reale potrebbe beneficiare di una correzione del contesto manuale piuttosto che di una rigenerazione completa.
Direzioni Future: Il benchmark rivela che gli agenti attuali faticano con la conformità alle specifiche, la affidabilità in task a lungo raggio e le sfumature di dominio specifico. Suggerisce che i miglioramenti futuri dovrebbero concentrarsi su migliori strategie di esplorazione, recupero dagli errori e comprensione delle specifiche.

Gli autori rilasciano IDE-Bench e una classifica pubblica su ide-bench.com per facilitare ulteriore ricerca e sviluppo.