OpenAI ha pubblicato il 18 agosto 2026 un resoconto sull’esperienza relativa alla rimozione di Enzyme nel codice di Asana con Codex. Il caso studio segnala circa due settimane di calendario, una settimana e mezza di lavoro di ingegneria e 12.000 dollari di costi per modelli e infrastruttura. Questi numeri sono impressionanti, ma devono essere letti come un caso del fornitore, non come una promessa applicabile a ogni migrazione.
1. Ciò che sostiene il caso Asana
Secondo il resoconto pubblicato da OpenAI riguardo ad Asana, il team ha rimosso Enzyme, un sistema di test diventato un debito significativo, in circa due settimane di calendario. Il lavoro umano diretto avrebbe rappresentato una settimana e mezza, mentre il costo dei modelli e dell'infrastruttura sarebbe di circa 12.000 dollari.
L'articolo confronta questo risultato con un vecchio piano che Asana stimava in almeno cinque anni e circa 6 milioni di dollari di personale. Questo confronto proviene dall’organizzazione stessa e dipende dal metodo di stima adottato. Non deve essere trasformato in un rapporto generico di produttività né in un confronto di costi completi indipendentemente verificato.
L'informazione più utile è operativa: a partire da un prompt iniziale di cinque frasi, fino a quattro agenti lavoravano in parallelo in copie separate della base di codice. Un ingegnere verificava i progressi due volte al giorno e ogni modifica proposta era soggetta a revisione.
2. Perché questa migrazione si prestava agli agenti
Sostituire un sistema di test è un problema vasto ma spesso ripetitivo. Le trasformazioni possono seguire schemi: modificare gli import, adattare i helper, sostituire i selettori, riscrivere le asserzioni e correggere i test.
Il risultato atteso è fortemente verificabile. Un test deve compilare, eseguirsi e mantenere un comportamento. Questo ciclo fornisce all'agente un feedback oggettivo, a differenza di una ristrutturazione del business di cui la qualità dipende da intenzioni poco documentate.
La migrazione può anche essere suddivisa per file, cartelle o componenti. Lotti indipendenti limitano i conflitti e permettono di eseguire più agenti in parallelo.
Queste caratteristiche costituiscono una griglia utile: ripetitività, verificabilità, partizionamento e bassa ambiguità commerciale. Più un progetto le riunisce, più è adatto a un'esperimentazione agentica. Questa griglia è una lettura metodologica di Partitech; lo studio di caso OpenAI non dettaglia queste trasformazioni una per una.
3. Il ruolo decisivo della suddivisione
Dare a un agente “elimina tutto il debito tecnico” produce raramente un risultato sfruttabile. Bisogna costruire un inventario: usi della dipendenza, varianti, eccezioni, copertura dei test e ordine di migrazione.
Il deposito può poi essere suddiviso in unità comparabili. Ogni lotto riceve un'istruzione concisa, dei vincoli, un ordine di test e una definizione di completamento. I casi atipici sono isolati invece di contaminare tutti i prompt.
Il feedback di Asana indica che istruzioni più semplici hanno funzionato meglio. Questa constatazione è coerente con una pratica dell’ingegneria: spostare le regole stabili verso script, test e linters, piuttosto che spiegare tutto il progetto in un prompt gigantesco.
4. Il parallelismo controllato
Più agenti possono accelerare il trattamento se i loro perimetri sono indipendenti. Copie separate del deposito evitano che modifichino simultaneamente lo stesso spazio di lavoro.
È comunque necessario gestire le dipendenze. Un agente può creare un helper comune di cui gli altri avranno bisogno. Un team deve decidere quali cambiamenti strutturali vengono integrati per primi e quali lotti possono rimanere autonomi.
Il parallelismo aumenta anche il volume di revisione. Quattro agenti che producono modifiche più velocemente di quanto il team possa verificarle creano una nuova coda. Il numero ottimale dipende quindi dalla capacità di CI e dal controllo umano, non solo dalle licenze disponibili.
5. Perché i test rimangono il vero acceleratore
La pagina OpenAI non documenta né i comandi di test, né l'integrazione continua, né la copertura funzionale della migrazione. Le pratiche descritte in questa sezione costituiscono quindi il nostro metodo di messa in sicurezza di un cantiere agentico, e non un risultato misurato nel caso Asana.
Un agente può modificare molto codice; i test permettono di sapere rapidamente se la modifica è accettabile. Senza una suite affidabile, il team deve leggere ogni riga e ricostruire il comportamento previsto, il che annulla gran parte del vantaggio.
Prima della migrazione, stabilizzate i comandi di test, riducete i casi non deterministici e aggiungete controlli mirati. Un test che fallisce una volta su dieci disturba tanto un agente quanto un umano.
La CI deve produrre messaggi utilizzabili e consentire esecuzioni parziali. L’agente può correggere più efficacemente quando riceve un feedback preciso sul file, sull’asserzione o sul tipo interessato.
6. La rivista umana non è scomparsa
Il caso pubblicato precisa che ogni proposta era rivista e approvata da un essere umano. L'ingegnere controllava il lavoro due volte al giorno e orientava gli agenti quando la strategia doveva cambiare.
La recensione deve riguardare il comportamento, non solo lo stile. Controllate le coperture eliminate, le asserzioni indebolite, i bypass dei tipi, gli snapshot accettati troppo facilmente e le modifiche di configurazione globale.
Un buon agente può proporre una soluzione che fa passare il CI eliminando il test problematico. I criteri di accettazione devono vietare esplicitamente questo tipo di scorciatoia.
7. Ciò che il numero dei costi non dice
I 12.000 dollari annunciati coprono i modelli e l'infrastruttura, ma la pagina non fornisce una ripartizione che permetta di sapere come vengono conteggiati la preparazione del deposito, lo sviluppo degli strumenti interni, il tempo di revisione, l'infrastruttura esistente, le correzioni successive o la capitalizzazione del team.
Al contrario, il confronto con un piano di almeno cinque anni e circa 6 milioni di dollari di personale si basa su una stima di Asana che forse non sarebbe mai stata realizzata in questa forma. I due numeri non sono direttamente confrontabili senza una metodologia dettagliata.
Per il vostro progetto, calcolate il costo completo: modelli, CI, archiviazione, ingegneria, revisione, incidenti e manutenzione degli script. Confrontatelo con uno scenario umano realistico sullo stesso perimetro e con lo stesso livello di qualità.
8. Un metodo ripetibile per il vostro progetto
Iniziate con un'analisi statica e un inventario verificabile. Scegliete poi un lotto pilota di 20-50 trasformazioni rappresentative. Scrivete un'istruzione breve, un comando di test e un elenco di divieti.
Fate eseguire il lotto da un agente in una filiale isolata. Misurate il tasso di accettazione senza ripetizione, il tempo di revisione, gli errori funzionali e il costo. Correggete gli strumenti prima di aumentare il volume.
Quando il pilota è stabile, suddividete il resto del cantiere, limitate il numero di agenti alla capacità di revisione e integrate progressivamente. Conservate un cruscotto: file trattati, test aggiunti, fallimenti, conflitti e debito residuo.
Questo metodo completa il nostro approccio a misura e prioritizzazione del debito tecnico e le salvaguardie presentate in Agenti di sviluppo nel 2026.
9. Le migrazioni da evitare per prime
Non utilizzare come primo pilota una revisione senza test, una logica di business non documentata o una migrazione di dati irreversibile. Gli agenti non compensano l’assenza di definizione del risultato atteso.
Evitate anche un cantiere dove ogni file dipende da un'architettura in movimento. Il conflitto tra agenti, rami e decisioni umane può superare il guadagno di generazione.
Il caso Asana non dimostra che un agente sostituisce un team. Mostra, secondo il resoconto pubblicato da OpenAI, che un team ben attrezzato può trasformare un cantiere ripetitivo in un flusso di migrazione parallelo. La competenza chiave rimane l'ingegneria del sistema di lavoro.
Partitech accompagna le migrazioni tecniche assistite dall'IA: inventario, progettazione dei lotti, prompt e script, rafforzamento dei test, orchestrazione Codex e controllo qualità.