Migramos de Enzyme en 2 semanas. Debería haber tomado cinco años.
Recientemente usamos la IA para finalizar años de trabajo de ingeniería en aproximadamente un sprint. A continuación, te contamos cómo y por qué cambió la forma en que pensamos sobre lo que es posible.
El problema de los cinco años
En 2022, nos propusimos migrar el conjunto de pruebas de frontend de Asana de Enzyme, nuestra antigua biblioteca de pruebas, a React Testing Library (RTL). Enzyme había perdido el apoyo de la comunidad, no funcionaba bien con las versiones más nuevas de React y fomentaba pruebas que estaban estrechamente vinculadas a los detalles de la implementación en lugar de a lo que los usuarios realmente ven y hacen. RTL nos impulsó hacia un modelo mejor: probar el comportamiento, no los componentes internos.
La migración avanzó de manera constante durante años. Se asignaron varios proyectos de varios años de duración con varios ingenieros para ello. Los equipos de producto se ocuparon de las partes que les correspondían. Todo ese trabajo fue importante. Pero al ritmo que íbamos, todavía nos faltaban aproximadamente cinco años para terminar.
Así que establecimos un objetivo intencionalmente irrazonable: ¿qué pasaría si termináramos toda la migración en una semana?
Estuvimos cerca. Tomó alrededor de una semana y media de tiempo de ingeniería. Enzyme ahora ha desaparecido por completo de la base de código.
Cómo fue en realidad
El enfoque fue casi vergonzosamente simple. Utilizamos Codex de OpenAI con modelos de frontera con razonamiento extraalto, ejecutando hasta cuatro agentes a la vez, cada uno apuntando a un directorio diferente. Evitamos que la máquina se pusiera en modo de suspensión, dejamos que los agentes se ejecutaran durante el día y la noche, y revisábamos cada mañana y cada noche para revisar el progreso y abrir solicitudes de extracción.
Esta es la indicación completa:
/objetivo Queremos migrar el repositorio de las pruebas de Enzyme a las pruebas al estilo de la biblioteca de pruebas de React. Sigue las normas existentes y las mejores prácticas en la base de código. Migra todos los archivos en/directory que usan Enzyme para que usen la biblioteca de pruebas de React. Prueba los cambios con [comando de prueba]. En general, prioriza la migración de los archivos fáciles de convertir primero.
Cinco oraciones. Eso fue todo.
También probamos configuraciones más sofisticadas: dividir el trabajo en tickets con seguimiento, hacer que el agente mantuviera un archivo de notas en curso, pedirle que generara subagentes para paralelizar aún más, escribir una indicación mucho más detallada sobre las convenciones de RTL. Casi todo empeoró las cosas. La simplicidad ganó.
Por qué una indicación de cinco oraciones fue suficiente
Esta es la parte que más importa, y es la misma idea sobre la que OpenAI escribió recientemente en Harness engineering: la calidad del resultado de un agente depende en gran medida de la calidad del entorno que le proporciones.
Nuestra base de código ya tenía años de buen gusto incorporados: la decisión original de adoptar RTL, ayudantes de prueba bien diseñados, convenciones claras, ejemplos reales de los que sacar provecho. El modelo no necesitaba que le explicáramos nada de eso; ya estaba ahí para ser leído. Simplemente proporcionamos el objetivo y dejamos que el agente se ejecutara.
La tarea en sí también tenía la forma correcta para que esto funcionara: una definición clara y verificable de “terminado” (no más Enzyme) y ciclos de retroalimentación rápidos (verificación de tipos, linting, pruebas, CI) que podían detectar errores de inmediato. Buen arnés, problema bien definido, se requería una intervención mínima.
Qué se interpuso en el camino
La mayor parte de la fricción no fue culpa del modelo, sino nuestra:
Algunos documentos internos y guías para agentes escritos recientemente seguían señalando a Enzyme como el patrón preferido, lo que llevaba activamente al agente en la dirección equivocada. La documentación obsoleta ya no es solo una pequeña molestia; es material de capacitación engañoso para todos los agentes que lo leen.
Descubrimos que era necesario intervenir más en las herramientas lentas y poco confiables (un paso de lint que ocasionalmente tomaba más de diez minutos, discrepancias entre la CI y las verificaciones locales). El agente rara vez era el cuello de botella: nuestra propia infraestructura lo era.
El arnés es el producto ahora
Una de las lecciones más claras de este proyecto: la IA no elimina la necesidad de buen gusto en la ingeniería, sino que la amplifica. Los ejemplos limpios y las normas claras en la base de código produjeron resultados limpios y bien definidos. También se copiaron patrones incómodos. Lo mismo ocurrió con nuestros documentos: la orientación obsoleta se convirtió en un problema de una manera que nunca lo fue cuando solo los humanos la leían.
La otra cara de la moneda, que es alentadora, es que esto también se intensifica en la otra dirección. Los buenos ejemplos se propagan. La documentación clara guía correctamente a los agentes. Invertir en el “arnés” (los documentos, las normas y los ciclos de comentarios que rodean al código) da sus frutos en todas las migraciones futuras, no solo en esta.
¿Qué sigue?
Somos optimistas sobre lo que esto significa para Asana y sabemos que también puede resultar inquietante: gran parte de la identidad de los ingenieros está ligada a escribir código a mano. Mi esperanza es que esto nos permita preocuparnos más por el oficio, no menos, y ser más ambiciosos con el trabajo pendiente de migraciones de larga duración, reescrituras y problemas de rendimiento que, en silencio, hemos asumido que siempre tomarán años.
No todos esos problemas pasarán de años a una semana. Pero algunos sí. La pregunta que vale la pena hacer no es solo “¿estamos usando IA aquí?” Es “¿realmente intentamos asignar un agente a esto durante un fin de semana y vimos lo que devolvió el lunes?”
Algunos detalles adicionales, para los curiosos:
Toda la migración tomó alrededor de una semana y media de tiempo de ingeniería, distribuida en dos semanas calendario.
El uso del modelo costó aproximadamente $11 000, con otros $1000 en infraestructura
Para poner esos $12 000 en perspectiva (cálculo aproximado): el trabajo finalmente generó beneficios más allá de la migración del marco original en sí. Durante el proceso, también mejoramos la cobertura de las pruebas, corregimos las pruebas deficientes y limpiamos la infraestructura de pruebas heredada. Estimamos que finalizar todo ese alcance manualmente habría representado aproximadamente USD 6 millones en esfuerzo de ingeniería a plena capacidad.
Encontramos algunos logros inesperados en el camino, incluida la limpieza de un marco de pruebas aún más antiguo, anterior a Enzyme, que habíamos olvidado que todavía estaba presente en partes de la base de código.
Esta publicación forma parte de una colaboración y asociación continua entre Asana y OpenAI para explorar cómo Codex puede asumir un trabajo de ingeniería más grande y ambicioso.