Il benchmark Real-SWE rivela il divario tra i punteggi dell’AI nel coding e il lavoro enterprise

Specific Labs ha pubblicato il benchmark Real-SWE con 640 esecuzioni di agenti, e la configurazione meglio classificata ha risolto soltanto il 38,8% del lavoro assegnato.

Il risultato crea un contrasto scomodo con le classifiche pubbliche sul coding. Gli agenti sembrano sempre più capaci di gestire problemi a livello di repository, ma la maggior parte dei tentativi su Real-SWE è fallita su sistemi di produzione privati.

La differenza non dipende semplicemente dal fatto che Real-SWE contenga rompicapi di programmazione più difficili. I suoi compiti richiedono agli agenti di ricostruire regole di business, orientarsi in architetture sconosciute e coordinare modifiche tra codice e servizi collegati.

Questa distinzione conta perché le aziende non assumono ingegneri del software per risolvere esercizi isolati e privi di contesto. Hanno bisogno di ingegneri in grado di preservare i comportamenti esistenti mentre modificano sistemi che già elaborano dati dei clienti, autorizzazioni, fatturazione e infrastrutture.

Real-SWE mette quindi in discussione la promessa implicita negli alti punteggi dei benchmark pubblici. Chiede se un agente possa entrare in una codebase enterprise sconosciuta e completare un lavoro economicamente utile senza fare affidamento su artefatti pubblici familiari.

La risposta iniziale è sobria. Il benchmark offre prove che i modelli di coding possano produrre patch credibili, ma non sostiene un’implementazione senza supervisione nei workflow enterprise con conseguenze rilevanti.

Cosa ha effettivamente cambiato il benchmark Real-SWE

Real-SWE sposta il bersaglio della valutazione dai problemi nei repository pubblici ai sistemi privati con regole specifiche dell’azienda e dipendenze operative.

Specific Labs ha annunciato il benchmark il 12 settembre 2026. L’azienda lo descrive come una valutazione di modelli frontier su codebase di produzione private concesse in licenza da aziende operative.

La versione iniziale copre dieci task e otto configurazioni di modelli e harness. Ogni configurazione riceve otto tentativi indipendenti per task, per un totale di 640 rollout valutati.

Questo design con esecuzioni ripetute è importante. Una singola patch riuscita può nascondere una notevole incoerenza, mentre otto tentativi mostrano se un agente risolve in modo affidabile la stessa classe di problema.

La classifica pubblicata riporta pass@1, ovvero la probabilità che un singolo tentativo risolva il task. Specific Labs calcola la media di questo risultato sulle otto esecuzioni assegnate a ciascun task.

Fable 5.1 con Claude Code ha guidato la classifica iniziale con il 38,8%. GPT-6 Astra con Codex CLI ha seguito con il 33,8%, mentre Gemini 3.8 Flash con Gemini CLI ha raggiunto il 31,2%.

GLM 5.3 con Claude Code ha registrato il 28,8%. Grok 4.6 e Muse Spark 1.3 hanno raggiunto ciascuno il 23,8% con i rispettivi sistemi agentici.

Kimi K3 con Kimi Code ha raggiunto il 18,8%. GPT-5.6 Sol con Codex CLI ha chiuso al 16,2% in questa specifica valutazione.

Questi risultati valutano combinazioni, non modelli linguistici isolati. Un harness fornisce strumenti, controlla il ciclo di interazione e determina il modo in cui un modello esplora e modifica un repository.

Specific Labs afferma esplicitamente di aver utilizzato harness nativi pensati per riflettere gli attuali workflow di engineering. Questa scelta migliora la rilevanza pratica, ma complica i confronti tra modelli.

Un punteggio più alto può riflettere il ragionamento del modello, il comportamento dell’harness, l’affidabilità degli strumenti o l’interazione tra tutti e tre. La classifica non può isolare nettamente questi effetti.

Il cambiamento più profondo del benchmark riguarda l’esposizione dei dati. I test pubblici di coding utilizzano normalmente repository open source, issue pubbliche e cronologie delle soluzioni visibili.

I repository privati riducono la probabilità che un modello abbia incontrato la patch rilevante durante l’addestramento. Inoltre impediscono a un agente di trovare una risposta attraverso la ricerca pubblica.

Secondo i risultati di Real-SWE pubblicati, ogni task ha avuto origine da lavoro associato a una reale codebase privata. Alcune istruzioni sarebbero state riprese direttamente da attività di engineering effettive.

Questo design rende la valutazione meno simile a un esame costruito per i modelli. La rende più vicina all’inserimento di un nuovo collaboratore esterno in un’organizzazione software sconosciuta.

La distinzione cambia anche il significato del fallimento. Una patch non riuscita può riflettere debolezze nel coding, ma può anche rivelare una scarsa individuazione dei requisiti o una comprensione incompleta del sistema.

È proprio questo il territorio in cui le implementazioni enterprise diventano rischiose. Una patch può compilare, superare test evidenti e tuttavia violare una regola incorporata altrove nel business.

Perché il codice enterprise privato crea un test diverso

La sfida centrale non è generare più codice. È scoprire da quale comportamento il business già dipende e preservarlo attraverso più sistemi.

Un esempio di Real-SWE chiede a un agente di correggere la tassazione delle fatture. La breve descrizione nasconde diverse condizioni che riguardano la configurazione aziendale, le esenzioni dei clienti, le regole geografiche e i servizi fiscali esterni.

L’agente deve determinare quando utilizzare un’aliquota memorizzata e quando calcolare l’imposta in base alla destinazione dell’acquirente. Deve riconoscere gli account che non riscuotono imposte.

Deve inoltre preservare le esenzioni, registrare correttamente i totali delle fatture e segnalare gli indirizzi rifiutati senza bloccare la fattura. Le transazioni regolate devono essere restituite all’autorità fiscale.

Le transazioni europee aggiungono un altro requisito relativo alle registrazioni IVA. Completare il lavoro può coinvolgere un servizio TypeScript, ambienti TaxJar e un registro InfluxDB.

Nessuna di queste singole operazioni rappresenta un algoritmo esotico. La difficoltà deriva dal coordinarle senza trascurare una condizione o danneggiare il comportamento esistente.

Questo schema ricorre in tutto il software enterprise. Una richiesta che sembra locale spesso attraversa API, database, processi in background, configurazione, test e strumenti operativi.

Gli ambienti Real-SWE possono esporre servizi e strumenti che includono Docker, Kubernetes, GitHub, PostgreSQL, MySQL, Redis, Slack, email e sistemi di assistenza clienti.

Ogni task riceve solo i servizi necessari al proprio workflow. Ciononostante, un agente deve decidere quali sistemi contengano prove rilevanti e quali siano distrazioni.

Il benchmark riporta una lunghezza mediana delle istruzioni di 1.742 caratteri. È meno di una specifica dettagliata di implementazione, lasciando agli agenti il compito di dedurre la struttura dal codice e dal contesto disponibili.

Le soluzioni di riferimento hanno modificato una mediana di 11 file. I dati comparativi del benchmark collocano questo valore al di sopra delle mediane di sei file riportate per FrontierCode e DeepSWE.

Questo divario aiuta a spiegare perché la navigazione del repository sia importante. Un modello che trova un punto di implementazione evidente può comunque trascurare validazione, persistenza, configurazione o consumatori downstream.

Specific Labs afferma che sei dei dieci task avevano tassi di risoluzione inferiori al 15%. Nessuna configurazione testata ha risolto tutti i task.

L’analisi dei fallimenti identifica i requisiti mancati come la categoria più comune. Altri fallimenti osservati includevano assunzioni non verificate, errori di integrazione, regressioni e modifiche al file sbagliato.

Queste categorie assomigliano più a normali commenti di code review che a errori di sintassi. Suggeriscono che gli agenti producano spesso modifiche locali plausibili senza costruire un modello completo del sistema.

Il tempo da solo non ha distinto i vincitori dai fallimenti. Il benchmark afferma che 70 dei 98 rollout durati meno di dieci minuti sono falliti, con un tasso di fallimento del 71,4%.

Tra i rollout più lunghi, 398 su 542 sono falliti, pari al 73,4%. Un tempo di esecuzione maggiore non ha quindi corretto automaticamente un’esplorazione debole o assunzioni errate.

Il confronto tra tentativi brevi e lunghi non dovrebbe essere considerato una prova che un ragionamento aggiuntivo non aiuti mai. I task più difficili probabilmente generano tentativi più lunghi, creando un importante fattore confondente.

Tuttavia, il risultato indebolisce una spiegazione comoda. Questi agenti non hanno fallito semplicemente perché ogni esecuzione è terminata prima che il modello potesse finire di digitare una soluzione.

Il meccanismo più credibile è una formazione incompleta del contesto. Un agente deve identificare i requisiti, individuare la relativa implementazione, tracciare le dipendenze e verificare l’intera modifica.

Questo workflow beneficia di una conoscenza duratura del repository. Per lo stesso motivo, i team di engineering mantengono già note architetturali, cronologia degli incidenti, decisioni e documenti tecnici.

Una base di conoscenza per l’engineering ricercabile può ridurre il lavoro di scoperta ripetuto per le persone. I sistemi agentici hanno sempre più bisogno di un livello di contesto equivalente.

Real-SWE non dimostra che una memoria persistente risolverebbe questi task. Mostra però perché la generazione di codice senza stato sia un modello incompleto per l’engineering enterprise.

I punteggi pubblici di coding incontrano la realtà del codice privato

La sfida principale è tra capacità di coding visibile nei benchmark e prestazioni affidabili all’interno di sistemi che i modelli non hanno mai incontrato.

SWE-bench ha cambiato la valutazione del coding chiedendo ai modelli di risolvere reali issue GitHub all’interno di snapshot dei repository. È stato un grande miglioramento rispetto ai test isolati di generazione di funzioni.

Il benchmark originale collegava descrizioni delle issue, stato del repository e valutazione basata sull’esecuzione. Ha contribuito a spostare il settore verso agenti che esplorano, modificano e testano software.

Tuttavia, quei repository e le cronologie delle issue sono pubblici. Man mano che i modelli migliorano e i dati di valutazione circolano, la contaminazione diventa più difficile da escludere.

La contaminazione si verifica quando i dati di addestramento di un modello contengono task del benchmark, patch rilevanti o copie molto simili. Un punteggio elevato può quindi combinare generalizzazione con riconoscimento o memorizzazione.

SWE-bench Verified ha cercato di migliorare la qualità dei task attraverso la revisione umana. Il suo dataset verificato ha mantenuto 500 campioni dopo lo screening delle descrizioni delle issue e dei test.

Quella revisione ha dimostrato di per sé quanto sia difficile costruire valutazioni del coding. OpenAI ha riferito che il 68,3% dei campioni esaminati è stato rimosso per problemi di specifica, testing o questioni correlate.

Il benchmark filtrato è rimasto utile, ma non ha eliminato l’esposizione pubblica. Gli sviluppatori di modelli potevano comunque studiare i repository, i task, il comportamento di valutazione e gli schemi di fallimento comuni.

Audit più recenti hanno aumentato la pressione per nuovi design di valutazione. L’audit dei benchmark di OpenAI del 2026 ha segnalato preoccupazioni relative a design e contaminazione nelle valutazioni di coding ampiamente utilizzate.

L’audit ha inoltre stimato che circa il 30% dei task di SWE-Bench Pro fosse difettoso. I problemi segnalati includevano test rigidi, requisiti mancanti, copertura debole e prompt fuorvianti.

Real-SWE affronta una parte di questo problema mantenendo privati i repository e le soluzioni sottostanti. I modelli non possono recuperare una patch pubblica esatta se quella patch non è mai stata pubblicata.

Tuttavia, i dati privati introducono un diverso compromesso. I ricercatori esterni non possono ispezionare liberamente ogni repository, riprodurre ogni task o verificare test nascosti.

Questo riduce la trasparenza proprio quando un benchmark formula affermazioni commercialmente significative. I lettori devono fidarsi delle procedure dell’operatore del benchmark per licenze, anonimizzazione, costruzione dei task e punteggio.

Real-SWE fornisce esempi di task, risultati aggregati, intervalli di confidenza e una tassonomia dei fallimenti. Queste informazioni aiutano, ma non equivalgono a una valutazione apertamente riproducibile.

La dimensione di dieci task presenta un’altra limitazione. Le esecuzioni ripetute misurano la coerenza tra i tentativi, ma la ripetizione non crea una copertura più ampia dei task.

Un benchmark con dieci task può essere sensibile alla selezione dei task. Un’architettura, una combinazione di linguaggi o un dominio di business possono influenzare materialmente le classifiche.

L’abbinamento tra modello e harness aggiunge ulteriore incertezza. Claude Code compare con più di un modello, mentre Codex CLI compare anch’esso con più modelli.

Questa variazione fornisce informazioni utili sul deployment. Non produce un confronto controllato in cui ogni modello riceve uno scaffold identico e la stessa policy degli strumenti.

L’interpretazione corretta è quindi più circoscritta di una classifica universale dei modelli. Questi punteggi mostrano come configurazioni nominate si sono comportate in questa release di Real-SWE secondo il setup documentato.

Non dimostrano che il modello in cima alla classifica sia il migliore per ogni azienda. Né stabiliscono che la configurazione con il punteggio più basso sia priva di utili capacità di programmazione.

Il benchmark fornisce invece un avvertimento contro il trasferimento diretto dei punteggi pubblici nelle aspettative di deployment privato. Tale avvertimento è in linea con una più ampia rivalutazione nel campo della valutazione.

METR opera una distinzione correlata nella propria metodologia delle attività. Le sue attività autosufficienti forniscono intenzionalmente ai modelli criteri di successo chiari e una dipendenza limitata dalla storia organizzativa.

METR osserva che il lavoro reale dipende spesso da conversazioni precedenti, conoscenza tacita e familiarità con una codebase esistente. La sua metodologia confronta gli agenti più da vicino con contractor che dispongono di poco contesto.

Real-SWE si spinge ulteriormente in questo problema di contesto limitato. Mantiene una valutazione eseguibile introducendo al contempo convenzioni specifiche dell’azienda e relazioni operative.

Questo è il ribaltamento più importante del benchmark. Una solida performance su issue pubbliche non costituisce più prova sufficiente di un’autonomia aziendale affidabile.

La classifica mette sotto pressione gli acquirenti quanto i fornitori di modelli

Real-SWE mette sotto pressione i team aziendali di valutazione perché i punteggi dei fornitori non possono sostituire i test nell’ambiente dell’acquirente.

Un’azienda che valuta agenti di programmazione affronta solitamente un’asimmetria informativa. I fornitori conoscono i propri modelli, mentre gli acquirenti conoscono i propri repository, flussi di lavoro e tolleranza al rischio.

Le classifiche pubbliche offrono a entrambe le parti un riferimento comune. Semplificano il confronto, ma questa semplicità diventa pericolosa quando l’ambiente di deployment differisce da quello del benchmark.

Real-SWE rende visibile la discrepanza. Persino la sua configurazione più solida ha fallito oltre sei tentativi su dieci nell’insieme di attività valutato.

Un acquirente non dovrebbe tradurre direttamente quel numero in un tasso di fallimento previsto in produzione. Dieci attività di benchmark non possono rappresentare ogni repository o organizzazione di ingegneria.

Il numero cambia comunque la conversazione sugli acquisti. I team hanno bisogno di prove dell’affidabilità sul proprio codice, non solo delle prestazioni sulle cronologie delle issue pubbliche.

Questo significa costruire valutazioni interne basate su lavoro rappresentativo, già completato in precedenza. Le attività adatte possono includere correzioni di bug, migrazioni, modifiche alle autorizzazioni e lavoro di integrazione con esiti noti.

La soluzione di riferimento non dovrebbe diventare l’unica implementazione accettabile. I revisori devono distinguere la correttezza funzionale dalla somiglianza superficiale con la patch originale dell’ingegnere.

Anche i test nascosti richiedono esame. Un benchmark può penalizzare un’alternativa valida se il suo verificatore codifica dettagli implementativi non dichiarati.

Gli audit sui benchmark di OpenAI mostrano quanto frequentemente ciò accada. La qualità della valutazione richiede ingegneri esperti che confrontino istruzioni, test, modifiche di riferimento e tracce degli agenti.

Le organizzazioni dovrebbero testare anche le configurazioni complete. La decisione di Real-SWE di valutare coppie modello-harness riflette il modo in cui gli agenti di programmazione operano nella pratica.

Ricerca nel repository, accesso alla shell, esecuzione dei test, gestione del contesto e policy di retry possono modificare materialmente le prestazioni. Misurare soltanto il modello sottostante ignora queste dipendenze.

La sicurezza rientra nella stessa valutazione. L’accesso al codice sorgente privato solleva questioni su conservazione dei dati, controlli del fornitore, esposizione di segreti, logging e autorizzazioni.

Un agente che risolve più attività può comunque essere inadatto se riceve un accesso più ampio di quello che l’organizzazione può concedere in sicurezza. Capacità e rischio di deployment devono essere valutati insieme.

Il carico di revisione rappresenta un’altra misura critica. Una patch che alla fine funziona può richiedere così tante indagini umane da offrire pochi benefici in termini di produttività.

I team dovrebbero registrare con quale frequenza un agente manca i requisiti, crea regressioni o necessita di prompt correttivi. Queste misure corrispondono strettamente alle categorie di fallimento di Real-SWE.

Dovrebbero inoltre monitorare la variabilità. Una dimostrazione riuscita dice poco sulla capacità dell’agente di ripetere il risultato al tentativo successivo.

La discussione sul benchmark su Hacker News ha colto entrambi i lati della questione. Alcuni partecipanti hanno accolto favorevolmente prove ripetute pass@1 perché rivelano la coerenza.

Altri hanno sostenuto che gli strumenti attuali funzionano ancora meglio attraverso una stretta collaborazione umana. In questa prospettiva, l’operatore esperto rimane parte del sistema valutato.

Questo modello “centauro” abbina un essere umano a un agente IA. L’umano fornisce giudizio, contesto e revisione, mentre l’agente gestisce esplorazione, stesura e modifiche meccaniche.

Real-SWE non confronta agenti autonomi con team composti da esperti e agenti. I suoi risultati non dovrebbero quindi essere letti come prova che gli assistenti di programmazione siano privi di valore pratico.

Indicano qualcosa di più specifico. Le configurazioni testate non sostituiscono in modo affidabile il lavoro contestuale e di verifica svolto da ingegneri esperti.

Questa differenza conta per le affermazioni sul deployment. Assistere un ingegnere e assumere autonomamente la responsabilità di una modifica aziendale sono soglie di capacità distinte.

Gli acquirenti dovrebbero richiedere ai fornitori di dichiarare quale soglia sia supportata dalle loro prove. Un punteggio pubblico da solo non può rispondere a questa domanda.

Cosa non dimostrano i numeri di Real-SWE

Il benchmark fornisce un avvertimento significativo, ma il suo piccolo campione privato non può sostenere conclusioni generalizzate su ogni modello o codebase aziendale.

In primo luogo, le attività di Real-SWE provengono da aziende selezionate da Specific Labs. Gli esempi pubblicati includono un’applicazione consumer, una piattaforma fintech e software di vendita per aziende.

Specific Labs afferma che una delle applicazioni rappresentate serve oltre 200.000 utenti. Un’altra piattaforma elaborerebbe più di 100.000 estratti conto bancari.

Questi dettagli stabiliscono la rilevanza commerciale, ma le aziende restano anonime. I lettori non possono valutare in modo indipendente la loro qualità ingegneristica, architettura o complessità di dominio.

In secondo luogo, la privacy del benchmark impedisce una replica pubblica completa. Tale privacy protegge il codice concesso in licenza e riduce la contaminazione diretta, ma concentra l’autorità di validazione.

I valutatori indipendenti necessitano di accesso controllato per confermare provenienza delle attività, qualità dei verificatori, parità degli ambienti e punteggio. Senza questa revisione, una certa incertezza resta inevitabile.

In terzo luogo, la classifica combina modelli diversi con harness nativi diversi. Questo somiglia all’uso effettivo dei prodotti, ma indebolisce le conclusioni sull’intelligenza dei modelli sottostanti.

Una configurazione può perdere perché la sua strategia di ricerca fallisce, le chiamate agli strumenti si interrompono o la gestione del contesto scarta prove rilevanti. Sono fallimenti del prodotto, ma non fallimenti identici.

In quarto luogo, il benchmark usa la risoluzione automatizzata come esito primario. Superare un verificatore è necessario, anche se l’accettabilità aziendale può richiedere di più.

La revisione in produzione può considerare manutenibilità, osservabilità, sicurezza, affidabilità delle migrazioni, stile e futuro carico operativo. Un passaggio binario non può cogliere pienamente queste dimensioni.

Viceversa, una patch valida può fallire un verificatore imperfetto. La storia degli audit di SWE-bench mostra che i test nascosti possono respingere soluzioni ragionevoli o non rilevare quelle incomplete.

Real-SWE afferma che il comportamento richiesto deve essere dichiarato o ragionevolmente individuabile. Questo standard è sensato, ma “ragionevolmente individuabile” richiede comunque giudizio.

In quinto luogo, le attività aziendali anonime possono favorire modelli o harness i cui schemi di esplorazione corrispondono al benchmark. Una diversa struttura del repository potrebbe ribaltare alcune classifiche.

Gli intervalli di confidenza al 95 percento mostrati nella classifica riconoscono la variabilità del campionamento tra le esecuzioni. Non eliminano l’incertezza derivante dalla selezione di sole dieci attività.

In sesto luogo, la pagina di lancio sostiene in modo ampio che la maggior parte dei token aziendali rimane nascosta ai modelli di frontiera. L’affermazione supporta la motivazione del benchmark, ma non presenta dettagli pubblici di misurazione.

Dovrebbe essere trattata come l’inquadramento dell’azienda, non come una statistica stabilita in modo indipendente. La conclusione più prudente è che una parte sostanziale del contesto aziendale rimane privata.

Infine, una bassa risoluzione autonoma non equivale a un basso impatto sulla produttività. Un agente può far risparmiare tempo attraverso indagini, generazione di test, documentazione o bozze di patch senza completare il lavoro in modo indipendente.

Vale anche il contrario. Una patch completata può creare costi di revisione o rischi sottili che compensano la sua apparente velocità.

Questi limiti non rendono Real-SWE irrilevante. Definiscono le condizioni alle quali le sue conclusioni sono utili.

Il benchmark è più solido come prova di un divario nel deployment. È più debole come classifica definitiva dei modelli o previsione dell’occupazione ingegneristica.

Specific Labs è anche un partecipante commerciale nel campo dei dati e della valutazione aziendale. Il suo profilo aziendale descrive un’attività costruita attorno ad ambienti e dataset aziendali realistici.

Questo non invalida il lavoro. Rende più importanti la replica indipendente e una metodologia trasparente.

Un ecosistema di benchmark credibile necessita di più operatori, attività private a rotazione e audit di terze parti. Nessuna singola classifica dovrebbe diventare l’autorità finale.

Tre segnali che determineranno se Real-SWE conta

Real-SWE diventerà rilevante solo se il suo segnale sul codice privato resisterà all’espansione, alla revisione indipendente e alle ripetute release dei modelli.

Il primo segnale è la crescita dell’insieme di attività. Dieci attività possono rivelare modalità di fallimento, ma una raccolta più ampia deve coprire più linguaggi, architetture e domini aziendali.

L’espansione dovrebbe preservare la provenienza privata pubblicando al contempo metadati sufficienti affinché i lettori comprendano la diversità delle attività. Dovrebbe inoltre separare i campioni basati su repository dagli altri formati di attività.

Se le classifiche restano simili su un insieme di test più ampio, l’affermazione di un persistente divario aziendale diventa più solida. Grandi cambiamenti di posizione mostrerebbero che la selezione ha modellato i risultati del lancio.

Il secondo segnale è la valutazione indipendente. Ricercatori esterni o fornitori di modelli necessitano di accesso controllato per verificare attività, verificatori e ambienti di esecuzione.

Un audit utile esaminerebbe se i prompt contengono informazioni sufficienti, se i test nascosti accettano implementazioni alternative e se le soluzioni di riferimento rappresentano autentico lavoro di produzione.

L’accordo di revisori indipendenti rafforzerebbe la fiducia nei tassi di risoluzione riportati. Difetti scoperti nei test restringerebbero o rivedrebbero le conclusioni del benchmark.

Il terzo segnale è il progresso attraverso release ripetute. I benchmark privati perdono valore se le attività trapelano, diventano obiettivi di addestramento o restano statiche mentre i sistemi agentici si adattano.

Specific Labs avrà bisogno di nuove attività riservate e di una chiara gestione delle versioni. I risultati dovrebbero distinguere i miglioramenti dovuti a modelli, harness, retry ed esposizione alle attività.

Un rapido aumento dei punteggi su nuove attività private indicherebbe una migliore generalizzazione. Miglioramenti limitati alle vecchie attività suggerirebbero un’ottimizzazione attorno al benchmark stesso.

Le aziende dovrebbero osservare la composizione dei fallimenti accanto al tasso di superamento principale. Meno requisiti mancati e meno assunzioni non verificate conterebbero più di patch generate più eleganti.

Anche la coerenza dovrebbe migliorare. Un modello che risolve occasionalmente un’attività resta difficile da considerare affidabile quando lo stesso prompt produce spesso una regressione.

I confronti tra umani e agenti aggiungerebbero un altro livello utile. Misurare il tempo di revisione e il tempo totale di completamento potrebbe mostrare dove gli agenti creano già valore senza piena autonomia.

Real-SWE ha posto la domanda giusta davanti agli sviluppatori e agli acquirenti di modelli. Un agente può modificare in sicurezza software la cui storia, le cui convenzioni e la cui logica di business non sono mai state pubbliche?

I suoi primi risultati indicano che i sistemi attuali spesso non possono farlo. La migliore configurazione ha risolto meno di quattro tentativi su dieci, mentre i requisiti non soddisfatti hanno dominato i fallimenti osservati.

Questa conclusione dovrebbe spingere verso valutazioni migliori, non verso un rifiuto indiscriminato. Gli agenti di coding possono continuare a essere preziosi quando gli ingegneri controllano l’ambito, forniscono contesto e verificano le conseguenze.

Il prossimo passo pratico consiste nel testare attività interne rappresentative prima di ampliare le autorizzazioni. I team dovrebbero confrontare le configurazioni, ripetere ogni attività e studiare perché patch apparentemente ragionevoli falliscono.

Il benchmark Real-SWE è importante se modifica il comportamento d’acquisto, passando dalla fiducia nei punteggi pubblici alla richiesta di prove private. La vostra prossima prova di un agente di coding misurerà il codice generato o il lavoro completato che la vostra azienda può accettare in sicurezza?