Asana ha eliminado de su código un sistema de tests obsoleto en dos semanas y por unos 12.000 dólares, un trabajo que la propia compañía había presupuestado en cinco años y alrededor de 6 millones. El caso lo publica OpenAI como cliente de Codex, así que es una historia contada por el proveedor, con las cautelas que eso merece. Las cifras las pone Asana y las firma su director de tecnología.
Puntos clave
- Dos semanas de calendario, con 1,5 semanas de esfuerzo real de ingeniería repartido en ellas.
- 12.000 dólares de coste en modelo e infraestructura, contra una estimación previa de unos 6 millones en plan de personal.
- Hasta cuatro agentes de Codex en paralelo, cada uno en una copia separada del repositorio, arrancados con un prompt de cinco frases.
- Un ingeniero revisaba el avance dos veces al día y aprobaba cada cambio propuesto.
- El trabajo consistía en retirar Enzyme, una librería de tests de frontend abandonada que bloqueaba modernizar el resto del stack.
Qué es exactamente lo que se automatizó
Conviene entender la tarea antes de extrapolar. Enzyme es una herramienta de pruebas de interfaz que dejó de mantenerse activamente y que se había convertido en un tapón: mientras estuviera dentro, Asana no podía actualizar su frontend. Quitarla significa reescribir miles de tests, uno a uno, sin romper nada.
Es trabajo mecánico, repetitivo, enorme y perfectamente verificable: o los tests pasan, o no pasan. Ese es el perfil de tarea donde los agentes de código rinden hoy de forma fiable. No es diseñar una arquitectura nueva ni decidir un producto.
Y es justamente el tipo de proyecto que se queda en el cajón durante años en cualquier empresa con software propio, porque nadie firma dedicar tres ingenieros durante un lustro a algo que el cliente no ve.
El montaje era simple a propósito
El detalle que más me interesa del caso es este: Asana dice que las instrucciones sencillas funcionaron mejor que un montaje más elaborado. Un prompt de cinco frases, hasta cuatro agentes trabajando en paralelo cada uno en su copia del repositorio, y un humano pasando a revisar dos veces al día.
Nada de orquestadores complejos ni de cadenas de veinte pasos. Un problema bien acotado, verificación automática (los tests) y un humano aprobando cada cambio.
La frase de Amritansh Raghav, director de tecnología de Asana, es honesta y merece citarse entera: "No todos los proyectos de años se van a colapsar en semanas. Pero los agentes pueden dar a los ingenieros más espacio para el oficio, y hacer que el trabajo que antes era imposible merezca la pena intentarlo".
Esa segunda parte es la que cambia decisiones. El cálculo de qué proyectos son viables se mueve.
Cuatro agentes en paralelo, cada uno en su copia
El detalle de arquitectura merece pararse. Cada agente trabajaba en una copia separada del repositorio, no todos sobre el mismo código. Eso evita el problema clásico de varios procesos pisándose los cambios, y permite que si uno se equivoca, su copia se descarte sin arrastrar a los demás.
Es el mismo patrón que usan hoy los equipos que trabajan con agentes de código en serio: una rama o un árbol de trabajo por agente, revisión y fusión al final. Nada exótico, pero cambia el resultado.
La cadencia de revisión también importa. Un ingeniero pasaba dos veces al día, no cada quince minutos. Ese es el modelo que hace rentable la automatización: el humano deja de ser el cuello de botella de cada paso y pasa a ser el control de calidad por lotes. Si tienes que aprobar cada cambio en el momento, no has automatizado nada, has cambiado de teclado.
Y todo arrancado con un prompt de cinco frases. Asana subraya que las instrucciones simples funcionaron mejor que los montajes elaborados, lo que encaja con lo que se ve una y otra vez: cuando la tarea está bien acotada y hay una forma automática de saber si está bien, el modelo no necesita que le expliques cómo hacer su trabajo.
Qué no dice el caso
Falta el denominador. No sabemos cuántos intentos fallaron, cuánto tiempo se fue en revisión frente a lo que habría costado escribir los tests a mano, ni si hubo regresiones detectadas después. La comparación de 12.000 contra 6 millones enfrenta un coste real contra una estimación que nunca se ejecutó, y las estimaciones de proyectos de cinco años se hacen con márgenes generosos.
Aun descontando eso, el orden de magnitud es difícil de discutir. Y lo verificable, que es lo que importa, sí está: Enzyme fuera, en dos semanas.
Por qué importa
Casi toda empresa con producto digital tiene su propio Enzyme. Una librería sin mantenimiento, una integración vieja, un formato de datos heredado que nadie se atreve a tocar. Están en la lista de deuda técnica desde hace años y nunca suben de prioridad porque el coste estimado no compensa.
Ese cálculo es el que conviene rehacer este trimestre. La pregunta no es cuánta gente hace falta para la migración, sino si la tarea se puede verificar automáticamente. Si hay una suite de tests, un linter o un script que diga "esto está bien" sin que un humano lo lea entero, es candidata a un agente en paralelo con revisión humana por lotes.
Y si no la hay, el primer proyecto de IA de tu equipo probablemente sea construir esa verificación, no comprar más licencias.
Un apunte sobre el coste que conviene no perder de vista. Los 12.000 dólares son de modelo e infraestructura, no incluyen el sueldo del ingeniero que revisó dos veces al día durante dos semanas. Aun sumándolo, la comparación no se mueve de sitio. Pero es el tipo de partida que desaparece de los casos de éxito y luego aparece en tu factura.
La forma honesta de presupuestar un proyecto así es contar tres cosas: tokens, horas de revisión y el tiempo de montar la verificación automática si no la tienes. Las dos últimas suelen ser mayores que la primera, y son las que deciden si sale a cuenta.
Relacionado
