Migramos do Enzyme em duas semanas. Deveria ter levado cinco anos.

Equipe de engenharia da AsanaEngineering Team
7 de agosto de 2026
4 minutos de leitura
facebookx-twitterlinkedin
Destaque da engenharia da Asana

Recentemente, usamos a IA para concluir anos de trabalho de engenharia em cerca de um sprint. Veja como e por que isso mudou a nossa maneira de pensar sobre o que é possível.

O problema de cinco anos

Em 2022, decidimos migrar o conjunto de testes de front-end da Asana da Enzyme, a nossa antiga biblioteca de testes, para a React Testing Library (RTL). A Enzyme havia perdido o apoio da comunidade, não funcionava bem com as versões mais recentes do React e incentivava testes que estavam intimamente ligados aos detalhes da implementação, e não ao que os usuários realmente veem e fazem. A RTL nos levou a um modelo melhor: testar o comportamento, não os componentes internos.

A migração progrediu de forma constante por anos. Vários projetos de vários engenheiros e anos foram alocados para isso. As equipes de produto trabalharam nas partes sob sua responsabilidade. Todo esse trabalho foi importante. Mas, no ritmo em que estávamos, ainda faltavam cerca de cinco anos para terminar.

Então, definimos uma Meta intencionalmente irracional: e se terminássemos toda a migração em uma semana?

Chegamos perto. A engenharia levou cerca de uma semana e meia. O Enzyme agora foi totalmente eliminado da base de código.

Como realmente aconteceu

A abordagem foi quase embaraçosamente simples. Usamos o Codex da OpenAI com modelos de ponta em raciocínio extra-alto, executando até quatro agentes por vez, cada um apontado para um diretório diferente. Evitamos que a máquina entrasse em modo de suspensão, deixamos os agentes em execução durante o dia e a noite e fazíamos verificações todas as manhãs e noites para revisão do progresso e abertura de pull requests.

Este é o comando completo:

/goal Queremos migrar o repositório dos testes do Enzyme para os testes no estilo da React Testing Library. Siga as normas e boas práticas existentes na base de código. Migre todos os arquivos em/directory que usam o Enzyme para usar a React Testing Library. Teste as alterações com [test command]. Geralmente, priorize a migração de arquivos fáceis de converter primeiro.

Cinco frases. Foi isso.

Também tentamos configurações mais sofisticadas: dividir o trabalho em tickets rastreados, fazer com que o agente mantivesse um arquivo de anotações em andamento, solicitar que ele gerasse subagentes para paralelizar ainda mais, escrever um prompt muito mais detalhado sobre as convenções da RTL. Quase tudo piorou as coisas. A simplicidade venceu.

Por que um comando de cinco frases foi suficiente

Esta é a parte mais importante, e é a mesma ideia sobre a qual a OpenAI escreveu recentemente em Harness engineering: a qualidade do resultado de um agente depende muito da qualidade do ambiente que você oferece a ele.

Nossa base de código já tinha anos de bom gosto incorporados — a decisão original de adotar RTL, auxiliares de teste bem projetados, convenções claras, exemplos reais para se inspirar. O modelo não precisava que explicássemos nada disso; já estava lá para ser lido. Nós apenas fornecemos a meta e deixamos o agente trabalhar.

A própria tarefa também tinha a forma certa para que isso funcionasse: uma definição clara e verificável de concluído (chega de Enzyme) e ciclos de feedback rápidos — verificação de tipo, linting, testes, CI — que poderiam detectar erros imediatamente. Bom harness, problema bem definido, necessidade mínima de orientação.

O que atrapalhou

A maior parte do atrito não foi culpa do modelo, mas nossa:

  • Alguns documentos internos e orientações para agentes escritos recentemente ainda apontavam para o Enzyme como o padrão preferencial, conduzindo ativamente o agente na direção errada. A documentação desatualizada não é mais apenas um pequeno incômodo; é um material de treinamento enganoso para todos os agentes que o leem.

  • Ferramentas lentas e instáveis (uma etapa de lint que ocasionalmente levava mais de dez minutos, incompatibilidades entre a CI e as verificações locais) eram o que mais precisávamos corrigir. O agente raramente era o gargalo — a nossa própria infraestrutura era.

O harness é o produto agora

Uma das lições mais claras deste projeto: a IA não elimina a necessidade de bom senso em engenharia, ela a amplifica. Exemplos limpos e convenções claras na base de código produziram resultados limpos e bem estruturados. Padrões estranhos também foram copiados. O mesmo aconteceu com os nossos documentos: as orientações obsoletas se tornaram um risco de uma forma que nunca foi quando apenas humanos as liam.

O lado positivo e encorajador é que isso também se aplica na outra direção. Bons exemplos se espalham. Documentos claros orientam os agentes corretamente. Investir na “estrutura” — a documentação, as convenções e os ciclos de feedback em torno do código — compensa em todas as migrações futuras, não apenas nesta.

O que vem em seguida

Estamos otimistas quanto ao que isto significa para a Asana e sabemos que também pode parecer inquietante — grande parte da identidade da engenharia está ligada à escrita manual de código. A minha esperança é que isso nos liberte para nos preocuparmos mais com a arte, e não menos, e para sermos mais ambiciosos em relação ao backlog de migrações de longa duração, reescritas e problemas de desempenho que silenciosamente presumimos que sempre levarão anos.

Nem todos esses problemas passarão de anos para uma semana. Mas alguns vão. A pergunta que vale a pena fazer não é apenas “estamos usando IA aqui?” É: “Será que realmente tentamos direcionar um agente para isso durante um final de semana e vimos o que ele nos devolveu na segunda-feira?”


Alguns detalhes adicionais, para os curiosos:

  • Toda a migração levou cerca de uma semana e meia de tempo de engenharia, distribuída por duas semanas de calendário.

  • O uso do modelo custou cerca de US$ 11 mil, com mais US$ 1 mil em infraestrutura

  • Para colocar esses US$ 12 mil em perspectiva (fazendo as contas de cabeça): o trabalho acabou gerando benefícios que foram além da migração original do framework em si. Ao longo do processo, também melhoramos a abrangência dos testes, corrigimos testes inadequados e organizamos a infraestrutura de testes legada. Estimamos que concluir todo esse escopo manualmente teria representado cerca de US$ 6 milhões em esforço de engenharia total.

  • Encontramos algumas conquistas inesperadas ao longo do caminho, incluindo a limpeza de uma estrutura de testes ainda mais antiga, anterior ao Enzyme, que tínhamos esquecido que ainda estava presente em partes da base de código.

Esta publicação faz parte de uma colaboração e parceria contínuas entre a Asana e a OpenAI para explorar como o Codex pode realizar trabalhos de engenharia maiores e mais ambiciosos.