Il coding con l'AI ha davvero migliorato l'efficienza? Non trattare tre tipi di prove come un'unica conclusione

Uno sviluppatore dice che l'AI lo ha aiutato a costruire un prototipo in dieci minuti; un altro dice che rivedere le modifiche dell'AI è più lento che scriverle da zero. Entrambe le affermazioni possono essere vere allo stesso tempo. Costruire un prototipo, modificare un progetto maturo e fare manutenzione nel lungo periodo non sono lo stesso tipo di lavoro. Senza specificare il task, i criteri di completamento e il metodo di misurazione del tempo, i «guadagni di efficienza» diventano facilmente un dialogo tra sordi.

Per i responsabili tecnici la domanda più utile è: nelle nostre attività, quale parte dello sforzo ha ridotto l'AI e dove ha spostato il lavoro? Questo articolo usa come filo conduttore alcuni studi pubblici di METR per spiegare come leggere conclusioni apparentemente contrastanti e propone un metodo di valutazione che i team possono adottare. I dati sono aggiornati al 2026 9 5; qui non trovi esperimenti interni di EveryInfra sull'efficienza né classifiche di modelli.

Cosa misurava esattamente il «19% più lento»

Nello studio pubblicato a luglio 2025, METR ha fatto completare 246 task reali a 16 sviluppatori che conoscevano bene i rispettivi progetti open source, stabilendo in modo casuale se potessero usare gli strumenti di AI disponibili all'epoca. In queste condizioni di ricerca, il tempo di completamento dei task con l'AI è aumentato del 19%. Lo studio riguarda strumenti di inizio 2025 e scenari di lavoro specifici, non un risultato valido per tutte le attività di sviluppo nel 2026.

Questo limite non serve a sminuire i risultati, ma a preservarne l'utilità. Un maintainer che conosce bene un repository grande conosce già le convenzioni del progetto, i compromessi storici e le aree soggette a errori. Anche se la prima versione delle modifiche proposta dal modello sembra ragionevole, potrebbe dover essere riesaminata alla luce di questo contesto. D'altra parte, entrare in un progetto sconosciuto, eseguire un'elaborazione di dati una tantum o validare rapidamente un'idea possono comportare vincoli diversi.

Per questo, usare l'esperimento per dichiarare direttamente che «il coding con l'AI è inutile» va oltre le prove; interpretarlo come «chiunque sappia scrivere prompt guadagnerà sicuramente in efficienza» è altrettanto infondato. È più utile come promemoria del fatto che la percezione soggettiva e il tempo necessario per completare i task non coincidono necessariamente.

Nella discussione su Hacker News di allora, i lettori hanno sollevato anche dubbi sulla dimensione del campione, sulla familiarità con i progetti e su come misurare il tempo delle rilavorazioni successive. Questi commenti aiutano a completare le domande di valutazione, ma non possono essere trattati come nuovi risultati sperimentali. In particolare, un rapporto empirico suggestivo non va presentato come una regola statistica valida per tutti i progetti.

Perché dai materiali successivi del 2026 non si può ricavare semplicemente una nuova percentuale

Nell'aggiornamento del disegno sperimentale di febbraio 2026, METR ha segnalato esplicitamente che gli esperimenti successivi hanno incontrato un bias di selezione nei partecipanti e nei task, e che l'uso simultaneo di più agenti rendeva più difficile misurare il tempo. Alcuni sviluppatori erano riluttanti a partecipare ad assegnazioni che richiedevano di rinunciare all'AI. I ricercatori hanno osservato che l'aiuto fornito dagli strumenti potrebbe essere in aumento, ma i dati disponibili non bastano a stimarne in modo affidabile l'entità.

Questo non significa che «il vecchio esperimento è stato smentito». Il vecchio esperimento descrive ancora lo scenario studiato all'epoca; i materiali successivi ricordano che nel nuovo contesto stanno cambiando anche i soggetti della ricerca e i metodi di misurazione. Chi usa l'AI più attivamente potrebbe non essere entrato nel campione, e i task più adatti all'AI potrebbero non essere stati sottoposti.

Per i progetti pilota aziendali, questo problema è molto concreto. Contare solo gli utenti disposti a mostrare i risultati fa perdere facilmente i task falliti o abbandonati; far partecipare solo membri che non conoscono l'AI rischia di trasformare l'attrito della fase di apprendimento in un effetto di lungo periodo. Entrambe le scelte possono alterare la conclusione.

Il nostro consiglio è di registrare prima come i task entrano nel pilota, e solo dopo guardare i risultati medi. Tieni traccia di chi non ha partecipato, di quali task sono stati esclusi e per quali motivi. Non serve raccogliere informazioni personali irrilevanti: un registro organizzato per tipo di task spiega più di qualche demo riuscita.

Lavorare veloce, produrre tanto e consegnare valore non sono la stessa metrica

Nel sondaggio tra i lavoratori tecnici di maggio 2026, METR ha distinto ulteriormente velocità e valore. Il sondaggio ha coinvolto 349 lavoratori tecnici: il moltiplicatore mediano del valore del lavoro dichiarato dagli intervistati variava tra 1,4 e 2 volte a seconda della formulazione della domanda, mentre il moltiplicatore mediano della velocità dichiarato era 3 volte. Si tratta di stime soggettive raccolte con un questionario, non di aumenti di produttività dei team confermati da esperimenti randomizzati.

Perché queste due metriche possono divergere? Immagina un team che usa l'AI per generare rapidamente diverse pagine demo interne. Se queste pagine aiutano a confermare un requisito importante, il valore può essere alto; se non entrano in nessuna decisione, il numero di file di codice e di pagine aumenta, ma il valore di business potrebbe non seguire. È un esempio ipotetico, non un campione di ricerca relativo a un'azienda specifica.

Al contrario, se l'AI aiuta gli ingegneri a consultare meno spesso la documentazione e a cambiare strumento meno di frequente, l'esperienza di lavoro può migliorare anche se la data di consegna finale del progetto non cambia in modo significativo. I miglioramenti dell'esperienza vanno registrati, ma non vanno presentati come un risparmio di una quota equivalente del budget per il personale.

Preferiamo porre con chiarezza tre domande separate: lo stesso task è stato completato più in fretta? Quanto impegno manuale è servito per raggiungere lo stesso standard? Il task completato valeva di più la pena? Combinarle in un unico «moltiplicatore di efficienza» elimina proprio le informazioni più utili ai team per adattare il proprio modo di lavorare.

Per la valutazione del tuo team, definisci prima cosa significa «completato»

Prima di introdurre nuovi strumenti, fissa uno standard di completamento condiviso. Ad esempio, un task di integrazione API può richiedere che il percorso principale funzioni, che i fallimenti critici siano spiegabili, che i test necessari passino e che chi riceve il passaggio di consegne comprenda i limiti. I singoli progetti possono aggiungere o togliere condizioni, ma non possono abbassare i requisiti dopo aver visto l'output dell'AI solo per far sembrare migliori i risultati.

Poi registra separatamente due tipi di tempo. Il primo è il tempo di calendario dall'inizio del task all'accettazione, attese comprese; il secondo è il tempo effettivo di lavoro umano, che include comprensione dei requisiti, preparazione del contesto, revisione e rilavorazione. Quando più agenti lavorano in parallelo, i minuti di esecuzione delle singole macchine non si possono sommare direttamente come ore di lavoro umano, né tutte le attese si possono contare come tempo risparmiato.

Per avviare un pilota basta un registro con questi campi:

• Tipo di task, valutazione della complessità e familiarità dei membri con il codebase.
• Strumenti e versioni usati, eventuale assistenza dell'AI e responsabile dell'approvazione finale.
• Tempo di generazione della prima versione, tempo per raggiungere gli standard di completamento stabiliti e impegno umano effettivo.
• Problemi emersi in revisione, numero di cicli di rilavorazione e difetti scoperti in seguito.
• Scopo di business del task; se è stato adottato e, in caso contrario, perché.
• I task interrotti, falliti e abbandonati volontariamente non devono sparire dal registro.

Questa checklist è una nostra proposta di valutazione, non una replica degli esperimenti di METR, e non garantisce conclusioni significative su campioni piccoli. Il suo scopo principale è capire se il lavoro si blocca nella fase di generazione, di verifica o di passaggio di consegne.

Se l'attrito attuale deriva soprattutto da interfacce non allineate, passare a un modello più potente potrebbe non risolvere il problema. Ad esempio, il fatto che un SDK costruisca le richieste non significa che il servizio supporti gli stessi parametri o le stesse modalità di risposta. L'articolo del sito sui limiti della migrazione tra OpenAI SDK e Gemini tratta questo tipo di valutazione di compatibilità; anche questi vincoli di integrazione dovrebbero rientrare nei criteri di completamento dei task del pilota.

I campioni piccoli devono aiutare a decidere, non a fabbricare cifre promozionali

Dopo un periodo di valutazione, suddividi i risultati per tipo di task. Se i task a basso rischio e ben strutturati hanno fatto risparmiare lavoro umano mentre le modifiche trasversali a più moduli hanno richiesto più revisioni, il passo successivo potrebbe essere ridefinire l'ambito d'uso dell'AI, invece di estenderlo o interromperlo su tutti i task.

Nel rivedere i risultati, controlla anche se la difficoltà dei task e i requisiti di qualità sono cambiati. Se prima un task richiedeva una gestione completa degli errori e ora completa solo il percorso principale, i due casi non vanno confrontati direttamente. Se prima un task produceva un piano pronto per il passaggio di consegne e ora genera dieci bozze non adottate, la crescita dell'output non va giudicata solo dal numero.

I costi degli strumenti possono essere una dimensione dell'analisi, ma vanno considerati insieme a revisione umana, rilavorazioni dovute ai fallimenti e impegno di manutenzione. Quando mancano registrazioni affidabili, ammetti che per ora il calcolo non è possibile, invece di presentare il numero di chiamate API o le righe di codice generate come ritorno sull'investimento. Per confrontare insieme adattamento ai task, comportamento in caso di errore e metriche di costo, consulta la guida alla scelta delle API.

METR ha anche una nota sulla comunicazione scientifica dedicata a come presentare risultati di ricerca facili da fraintendere. Lo stesso vale per i contenuti aziendali: per aiutare i lettori a capire se qualcosa fa al caso loro, mantenere i limiti poco attraenti è spesso più efficace che scegliere il numero più eclatante.

«Il coding con l'AI migliora l'efficienza?» non avrà una risposta unica solo perché esce un altro articolo d'opinione. I team però possono rendere la domanda più trattabile: con quali tipi di task, versioni degli strumenti e standard di completamento l'impegno manuale è diminuito, la qualità è cambiata e i risultati sono stati davvero adottati? Ottenere prima risposte circoscritte come queste e poi decidere se estendere l'uso degli strumenti è più utile che discutere di un moltiplicatore di efficienza slegato dai task.