Asana ha eliminado de su código un sistema de tests obsoleto en 2 semanas y por un coste aproximado de 12.000 dólares. La propia compañía había presupuestado ese trabajo en 5 años y un coste de alrededor de 6 millones de dólares. El caso lo cuenta OpenAI, como proveedor del agente que hizo el trabajo, Codex, (así que conviene leerlo con la cautela propia de un caso contado por quien vende la herramienta). Las cifras, eso sí, las firma el director de tecnología de Asana, Amritansh Raghav.
Vi el caso publicado por Digital Brain News y me interesó por un motivo muy concreto: no habla de lo que puede hacer la IA, habla de cómo cambia el cálculo de qué proyectos merece la pena intentar. Y ese cálculo es, exactamente, el que trabajamos en Research Estratégico antes de tocar nada.
¿Qué pasó exactamente? (sin inflar el resultado)
Antes de sacar conclusiones, merece la pena entender la tarea. Asana tenía que retirar Enzyme, una librería de tests de frontend que dejó de mantenerse y que bloqueaba modernizar el resto del stack teconológico. Retirarla significaba reescribir miles de tests, uno a uno, sin romper nada por el camino.
Te puedes hacer a la idea de que es un trabajo mecánico, repetitivo y perfectamente verificable: o los tests pasan, o no pasan. Ese matiz importa más que la cifra de los 12.000 dólares. El montaje, según cuenta el artículo, fue deliberadamente simple: hasta cuatro agentes de Codex trabajando en paralelo, cada uno en su propia copia del repositorio (así, si uno se equivocaba, se descartaba su copia sin arrastrar a la de los demás), arrancados con un prompt de cinco frases. Un ingeniero revisaba el avance dos veces al día y aprobaba cada cambio.
Nada de orquestadores complejos. Un problema bien acotado, una forma automática de comprobar si el resultado era correcto, y un humano haciendo un control de calidad por lotes, en lugar de aprobar cada paso en tiempo real.
El propio artículo original añade un matiz que conviene no saltarse: no sabemos cuántos intentos fallaron, ni si hubo regresiones detectadas después, ni cuánto costó en horas de revisión de ese ingeniero (que no entra en los 12.000 dólares). La comparación enfrenta un coste real, contra una estimación que nunca llegó a ejecutarse. Aun con estas reservas, el orden de la magnitud es difícil de discutir.
El criterio que importa no es la herramienta
Aquí está, para mí, el mejor dato del artículo, en palabras del propio Raghav: la IA puede hacer que el trabajo que antes era imposible merezca la pena intentarlo
.
Esa frase cambia la pregunta. No es «¿qué puede automatizar la IA?». Es «¿esta tarea se puede verificar automáticamente, sin que un humano tenga que leérsela entera para saber si está bien?». Si la respuesta es sí (hay una suite de tests, un checklist objetivo, un criterio de aceptación claro), es candidata a resolverse en paralelo con revisión humana por lotes. Si la respuesta es no, el primer proyecto no es comprar una herramienta de IA: es construir esa verificación.
Casi todas las empresas con las que trabajo tienen su propio «Enzyme». No siempre es código: puede ser un proceso comercial que nadie documenta, un CRM mal alimentado desde hace tres años, un catálogo de producto que ya no refleja lo que venden. Está en la lista de pendientes desde hace tiempo y nunca sube de prioridad porque el coste estimado (en tiempo, personas, dinero…) parece mayor que el beneficio que reportaría.
Cómo aplicamos este criterio antes de tocar nada
No tengo, a día de hoy, un caso propio documentado con estas cifras exactas para ponerte de ejemplo, y prefiero decírtelo así de claro antes que forzar una comparación que no es real. Pero, el principio es justo el que aplicamos, con o sin IA de por medio, en Research Estratégico y en la fase de Pautar del Método EPA:
Antes de decidir cómo resolver un problema atascado, hay que decidir si merece la pena resolverlo, y bajo qué condiciones deja de ser una apuesta y pasa a ser una decisión razonable. Eso significa preguntar, en este orden: ¿el resultado se puede verificar de forma objetiva, o depende de que alguien lo revise entero a ojo? ¿Cuál es el coste real de intentarlo (no sólo de la herramienta, también las horas de revisión, etc.) frente al coste de seguir postergándolo? ¿Qué pasa si sale mal, y es reversible?
Ese filtro no depende de la IA. La IA simplemente ha movido el punto en el que muchos «no compensa» se convierten en «sí compensa». Pero, el criterio para decidirlo es el mismo de siempre, y es el que falta en la mayoría de decisiones de priorización que veo: no falta tecnología, falta un criterio explícito para decidir qué se ataca primero y por qué.
El ejercicio antes de cerrar esta pestaña
Si algo de esto te ha sonado a algo concreto de tu empresa, prueba esto: escribe una lista de las tres cosas que llevan más tiempo en tu «algún día lo arreglamos». Para cada una, responde sólo a esta pregunta: si alguien (persona o agente) lo intentara mañana, ¿cómo sabrías, sin tener que revisarlo entero, que el resultado está bien?
Si tienes una respuesta clara, esa tarea está más cerca de merecer la pena de lo que crees. Si no la tienes, ya sabes cuál es el primer proyecto.
Fuente del caso: Digital Brain News, a partir del artículo publicado por OpenAI.
