# Abbiamo effettuato la migrazione da Enzyme in 2 settimane. Avrebbero dovuto volerci cinque anni > Di recente abbiamo utilizzato l'IA per completare anni di lavoro di ingegneria in circa uno sprint per migrare da Enzyme. Ecco come il team di Asana ci è riuscito. Source: https://asana.com/it/inside-asana/migrating-off-enzyme-2-weeks ## 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](https://openai.com/index/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._ - [Come abbiamo ridotto di 76 volte il costo di un agente browser e lo abbiamo reso 5 volte più veloce mantenendo intatta la sua cache](/it/inside-asana/cut-browsers-agent-cost) Progettazione Intelligenza artificiale (IA) #### CTO di StackAI Uno studio con GPT-6 Astra in Codex su quattro modelli, dall'analisi del codice alla misurazione dei risultatiPerché abbiamo condotto lo studioAsana sta introducendo l'automazione ... - [Micro-framework nella console di amministrazione](/it/inside-asana/microframeworks-admin-console) Progettazione Ogni distribuzione di Asana ha una Console di amministrazione. È il luogo in cui gli amministratori IT configurano il modo in cui la loro azienda utilizza Asana, ad esempio modifi ... - [Sviluppo basato sulle specifiche: gli aspetti positivi e ciò che abbiamo appreso dopo tre mesi](/it/inside-asana/spec-driven-development) Progettazione #### Staff software engineer Dopo tre mesi, avevamo un quadro più chiaro di quando la struttura aggiuntiva si rivelava utile e quando invece costituiva un ostacolo.Uno dei nostri ingegneri stava preparando un ... - [Sconfiggere la letale tripletta: come Asana pensa alla sicurezza dell'IA agentica](/it/inside-asana/how-asana-thinks-about-agentic-ai-security) Progettazione #### Tecnico di sicurezza del personale L'IA agentica introduce una classe di rischi per la sicurezza che il settore non ha risolto. Ecco cosa pensiamo in Asana e le invarianti di sicurezza che applichiamo a tutte le no ... - [Abbiamo effettuato la migrazione da Enzyme in 2 settimane. Avrebbero dovuto volerci cinque anni](/it/inside-asana/migrating-off-enzyme-2-weeks) Progettazione 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 ... - [Progettazione](/inside-asana/engineering-spotlight)