Abbiamo effettuato la migrazione da Enzyme in 2 settimane. Avrebbe dovuto richiedere cinque anni.

Di recente abbiamo utilizzato l'IA per completare anni di lavoro di sviluppo in circa uno sprint. Ecco come e perché ha cambiato il nostro modo di pensare a ciò che è possibile.

Il problema dei cinque anni

Nel 2022, abbiamo deciso di migrare la suite di test del frontend di Asana da Enzyme, la nostra raccolta di test obsoleta, a React Testing Library (RTL). Enzyme aveva perso il supporto della community, non funzionava bene con le versioni più recenti di React e incoraggiava test strettamente legati ai dettagli di implementazione piuttosto che a ciò che gli utenti vedono e fanno effettivamente. RTL ci ha spinto verso un modello migliore: testare il comportamento, non gli elementi interni.

La migrazione è andata avanti costantemente per anni. Sono stati assegnati diversi progetti pluriennali a più ingegneri. I team di prodotto hanno lavorato sulle parti di cui erano responsabili. Tutto quel lavoro era importante. Ma al ritmo con cui stavamo procedendo, mancavano ancora circa cinque anni al completamento.

Quindi ci siamo posti un obiettivo volutamente irragionevole: e se completassimo l'intera migrazione in una settimana?

Ci siamo andati vicini. Ci è voluta circa una settimana e mezza di lavoro tecnico. Enzyme è ora completamente sparito dal codebase.

Come è andata in realtà

L'approccio è stato così semplice da essere quasi imbarazzante. Abbiamo utilizzato Codex di OpenAI con modelli all'avanguardia per il ragionamento di livello extra-alto, eseguendo fino a quattro agenti alla volta, ciascuno puntato a una directory diversa. Abbiamo impedito alla macchina di andare in standby, abbiamo lasciato che gli agenti lavorassero tutto il giorno e tutta la notte e abbiamo effettuato il controllo ogni mattina e sera per verificare i progressi e aprire le richieste pull.

Ecco l'intero prompt:

/obiettivo Vogliamo migrare il repository dai test Enzyme ai test in stile React Testing Library. Segui le norme e le best practice esistenti nel codebase. Migra tutti i file in/directory che usano Enzyme per usare la raccolta di test React. Testa le modifiche con [test command]. In generale, prediligi la migrazione dei file facili da convertire per primi.

Cinque frasi. Tutto qui.

Abbiamo anche provato configurazioni più sofisticate: suddividere il lavoro in ticket tracciati, far tenere all'agente un file di appunti in esecuzione, chiedergli di generare sub-agenti per un'ulteriore parallelizzazione, scrivere un prompt molto più dettagliato sulle convenzioni RTL. Quasi tutto ha peggiorato le cose. La semplicità ha vinto.

Perché un prompt di cinque frasi era sufficiente

Questa è la parte che conta di più, ed è la stessa idea di cui OpenAI ha scritto di recente in Harness engineering: la qualità dell'output di un agente dipende fortemente dalla qualità dell'ambiente in cui viene inserito.

La nostra base di codice aveva già anni di buon gusto incorporati: la decisione originale di adottare RTL, helper di test ben progettati, convenzioni chiare, esempi reali a cui attingere. Il modello non aveva bisogno che spiegassimo nulla di tutto ciò; era già lì, pronto per essere letto. Abbiamo semplicemente fornito l'obiettivo e lasciato che l'agente si mettesse all'opera.

Anche l'attività stessa aveva la forma giusta per far sì che funzionasse: una definizione chiara e verificabile di completamento (niente più Enzyme) e cicli di feedback rapidi (typechecking, linting, test, CI) in grado di rilevare immediatamente gli errori. Buon harness, problema ben definito, assistenza minima necessaria.

Cosa ha ostacolato il processo

La maggior parte degli attriti non era colpa del modello, ma nostra:

• Alcuni documenti interni scritti di recente e le linee guida per gli agenti indicavano ancora Enzyme come il modello preferito, guidando attivamente l'agente nella direzione sbagliata. La documentazione obsoleta non è più solo un piccolo fastidio; è materiale di formazione fuorviante per ogni operatore che lo legge.

• Gli strumenti lenti e instabili (un passaggio di lint che a volte richiedeva più di dieci minuti, discrepanze tra CI e controlli locali) erano il punto in cui abbiamo scoperto di dover intervenire maggiormente. Raramente l'operatore era il collo di bottiglia: lo era la nostra infrastruttura.

Ora il prodotto è l'harness

Una delle lezioni più chiare di questo progetto: l'IA non elimina la necessità di buon gusto ingegneristico, ma la amplifica. Esempi puliti e convenzioni chiare nel codebase hanno prodotto un output pulito e ben strutturato. Anche i modelli scomodi sono stati copiati. Lo stesso valeva per i nostri documenti: le indicazioni obsolete sono diventate un problema, in un modo in cui non lo erano mai state quando le leggevano solo gli esseri umani.

Il rovescio della medaglia, che è incoraggiante, è che questo si ripercuote anche nell'altra direzione. I buoni esempi si diffondono. Una documentazione chiara guida correttamente gli agenti. Investire nell'“impianto” (la documentazione, le convenzioni e i cicli di feedback che circondano il codice) ripaga in ogni migrazione futura, non solo in questa.

Ecco il prossimo passo

Siamo ottimisti su ciò che questo significa per Asana e sappiamo che può anche essere destabilizzante: gran parte dell'identità degli ingegneri è legata alla scrittura manuale del codice. La mia speranza è che questo ci renda più liberi di dedicarci di più, e non di meno, all'arte del nostro lavoro, e di essere più ambiziosi riguardo al backlog di migrazioni, riscritture e problemi di prestazioni di lunga data che abbiamo silenziosamente dato per scontato che richiederanno sempre anni.

Non tutti questi problemi passeranno da anni a una settimana. Ma alcuni sì. La domanda che vale la pena porsi non è solo “stiamo usando l'IA qui?” È: “Abbiamo davvero provato a far lavorare un agente su questo durante un fine settimana e abbiamo guardato cosa ha prodotto lunedì?”

Alcuni dettagli aggiuntivi, per i curiosi:

• L'intera migrazione ha richiesto circa una settimana e mezza di tempo tecnico, distribuito su due settimane di calendario.

• Il costo di utilizzo del modello è stato di circa 11.000 $, con altri 1.000 $ per l'infrastruttura

• Per mettere in prospettiva quei 12.000 $ (calcolo approssimativo): il lavoro alla fine ha portato benefici che vanno oltre la migrazione del Framework originale. Nel frattempo, abbiamo anche migliorato la copertura dei test, corretto i test scadenti e ripulito l'infrastruttura di test legacy. Stimiamo che il completamento manuale di quell'ambito completo avrebbe richiesto un impegno ingegneristico totale di circa 6 milioni di dollari.

• Lungo il percorso abbiamo ottenuto alcuni successi inaspettati, tra cui la pulizia di un Framework di test ancora più vecchio, precedente a Enzyme, che avevamo dimenticato fosse ancora presente in alcune parti del codebase.

Questo post fa parte di una collaborazione e partnership in corso tra Asana e OpenAI, che esplora come Codex possa affrontare un lavoro di ingegneria più ampio e ambizioso.