Asana ha utilizzato OpenAI Codex per completare in circa due settimane una migrazione del proprio sistema di test frontend che, mantenendo il precedente ritmo di sviluppo, avrebbe richiesto ancora circa cinque anni. Il progetto riguardava l’eliminazione di Enzyme, una libreria di testing ormai datata e non più adeguatamente supportata dalla community, e il passaggio a React Testing Library, o RTL. Enzyme presentava inoltre problemi di compatibilità con le versioni più recenti di React e favoriva test strettamente legati ai dettagli interni dell’implementazione, mentre RTL adotta un approccio orientato maggiormente al comportamento effettivamente osservabile dall’utente.
La migrazione era iniziata nel 2022 e aveva già assorbito diversi progetti equivalenti a più anni-uomo di lavoro ingegneristico. I diversi team di prodotto avevano progressivamente convertito le parti del codice di propria competenza, ma la quantità di lavoro residua continuava a essere consistente. Sulla base della velocità raggiunta fino a quel momento, Asana stimava che per eliminare completamente Enzyme dalla codebase sarebbero serviti altri cinque anni. Il team ha quindi provato un’impostazione radicalmente diversa, fissando inizialmente l’obiettivo di completare l’intera operazione in una sola settimana. Il risultato finale è stato raggiunto con circa una settimana e mezza di lavoro ingegneristico distribuita su due settimane di calendario, al termine delle quali Enzyme era stato rimosso completamente dal repository.
Per eseguire la conversione sono stati utilizzati gli agenti di OpenAI Codex con modelli frontier impostati su un livello di reasoning particolarmente elevato. Il team ha fatto lavorare contemporaneamente fino a quattro agenti, assegnando a ciascuno una directory differente del progetto. Le sessioni venivano lasciate attive durante il giorno e durante la notte, mentre gli sviluppatori controllavano lo stato dell’avanzamento al mattino e alla sera, revisionando i risultati e aprendo le relative pull request. L’attività non è stata quindi impostata come una singola generazione di codice, ma come un processo continuativo di modifica, verifica e integrazione sul repository reale.
Il prompt utilizzato era volutamente molto breve. In sostanza, Codex riceveva l’obiettivo di migrare i test presenti in una determinata directory da Enzyme allo stile React Testing Library, rispettando le convenzioni e le best practice già presenti nella codebase, verificando le modifiche attraverso il comando di test indicato e dando inizialmente priorità ai file più semplici da convertire. L’intera istruzione era composta da appena cinque frasi. Asana ha sperimentato anche procedure più elaborate, dividendo il lavoro in ticket, facendo mantenere agli agenti file di note, chiedendo loro di creare sotto-agenti per aumentare il parallelismo e fornendo prompt molto più dettagliati sulle convenzioni RTL, ma questi approcci hanno prodotto risultati peggiori rispetto alla configurazione più semplice.
Un elemento determinante è stato il contesto tecnico già disponibile nel repository. Negli anni Asana aveva accumulato esempi corretti di utilizzo di React Testing Library, helper per i test, convenzioni consolidate e implementazioni che gli agenti potevano utilizzare come riferimento. Codex non aveva quindi bisogno di ricevere nel prompt tutte le regole del progetto, perché poteva ricavarle direttamente dalla codebase. Anche il tipo di attività si prestava bene all’automazione: il risultato atteso era facilmente verificabile, perché l’obiettivo finale consisteva nella completa eliminazione di Enzyme, mentre type checking, linting, test automatici e pipeline CI fornivano cicli di feedback rapidi per rilevare immediatamente eventuali errori.
I principali rallentamenti incontrati durante la migrazione non sono stati legati direttamente al modello. Alcuni documenti interni e alcune istruzioni destinate agli agenti erano rimasti obsoleti e continuavano a indicare Enzyme come soluzione da preferire, inducendo Codex a seguire convenzioni che il progetto stava invece cercando di eliminare. Anche alcuni strumenti della pipeline di sviluppo hanno richiesto interventi manuali: in particolare, alcune operazioni di linting potevano superare occasionalmente i dieci minuti ed erano presenti differenze tra i controlli eseguiti localmente e quelli della CI. In questi casi il collo di bottiglia era quindi rappresentato dall’infrastruttura di sviluppo e non dalla generazione delle modifiche da parte dell’agente.
Il costo complessivo del progetto è stato di circa 12.000 dollari, suddivisi in circa 11.000 dollari di utilizzo dei modelli e 1.000 dollari di infrastruttura. Asana ha confrontato questa cifra con una stima del costo necessario per proseguire secondo il piano originario: ipotizzando un team dedicato di tre senior engineer per cinque anni e un costo aziendale complessivo compreso tra circa 350.000 e 450.000 dollari l’anno per ciascun ingegnere nella Bay Area, la spesa sarebbe stata nell’ordine di 5-7 milioni di dollari, con una stima centrale di circa 6 milioni. Il rapporto tra i due valori corrisponde quindi a una riduzione dei costi nell’ordine di 500 volte, senza considerare il costo-opportunità derivante dall’impiego dei tre sviluppatori sul progetto per diversi anni invece che su nuove funzionalità.
Durante il processo Codex ha inoltre permesso di individuare e rimuovere parti ancora più vecchie dell’infrastruttura di testing, precedenti persino all’introduzione di Enzyme e rimaste in alcune sezioni della codebase. L’esperimento rientra nella collaborazione tra Asana e OpenAI finalizzata a verificare fino a che punto Codex possa essere impiegato su attività ingegneristiche di grandi dimensioni, comprese migrazioni, riscritture e interventi tecnici che tradizionalmente vengono pianificati su periodi di diversi anni.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)