Flywheels de IA: qué pasa cuando los flujos de trabajo se ejecutan solos

El artículo es el sexto episodio de la serie "The Org Age of AI" de Turing Post, firmado por Will Schenk y Ksenia Se, y presenta el concepto de "AI flywheel" (volante de IA) como el siguiente peldaño lógico tras los workflows descritos en el episodio anterior de la serie. Conviene advertir que el texto descargado corresponde solo a la primera mitad del artículo: al llegar al apartado 'Why this reaches you on a schedule you don't control', el contenido queda bloqueado tras un muro de pago ('UPGRADE TO READ THE REST'), por lo que buena parte del argumento final —incluyendo el detalle sobre los tipos de infraestructura que faltan, cómo priorizar qué loops cerrar primero, y la discusión sobre la 'nueva brecha' de verificación a velocidad de máquina— no está disponible en el material recibido. El resumen que sigue se basa únicamente en la parte accesible.

La pieza construye una escalera conceptual de tres peldaños. En la base está el 'pipeline': una secuencia fija de pasos, mecánica, sin juicio humano real, como un cron job o un script. Un peldaño más arriba está el 'workflow': una secuencia repetida de decisiones y acciones donde, en algunos puntos, un humano ejerce juicio; si se elimina ese juicio, el workflow colapsa de nuevo en un pipeline. Los autores recuerdan que, según el episodio anterior de la serie, a medida que un workflow madura, el humano migra del centro hacia los bordes: define los parámetros al inicio y revisa las excepciones al final, mientras el 'centro' del proceso queda en manos del agente.

El tercer peldaño, y el tema central de este episodio, es el 'flywheel': una colección de workflows encadenados de modo que la salida de uno alimenta al siguiente, orientados hacia un objetivo definido una sola vez, girando de forma continua sin intervención humana entre iteraciones. Un 'closed loop' (bucle cerrado) sería el flywheel más pequeño posible: un solo workflow que se retroalimenta a sí mismo. La diferencia clave entre un pipeline y un flywheel es que el pipeline repite, mientras que el flywheel dirige (steers), y lo que dirige es la medición: el sistema actúa, mide el resultado de su propia acción, y usa esa medición para decidir la siguiente acción. Por eso un flywheel tiene tres tiempos —generar, medir, decidir qué probar a continuación— y no solo uno.

Un punto central del artículo es la distinción entre dos formas de cerrar ese bucle: la manera equivocada, que consiste en quitar el control humano y confiar (esperar que funcione), típica de muchas historias de 'desplegamos agentes autónomos' que terminan mal; y la manera correcta, que consiste en sustituir el punto de control humano por un verificador automático: un conjunto de pruebas (test suite), una validación de esquema, una reconciliación contra totales conocidos, o una métrica de rendimiento. En este segundo caso, el juicio humano no desaparece, sino que se codifica una sola vez dentro del verificador, en lugar de ejercerse manualmente en cada ejecución. Los autores insisten en que los bucles no se cierran porque alguien decida confiar en el modelo, sino porque la verificación se ha vuelto barata, rápida y objetiva; en todos los demás casos, el humano permanece en el proceso. Y señalan algo importante: el flywheel no elimina al humano, sino que lo sube un nivel más —ya no está en medio del trabajo ni coordinando entre workflows, sino situado sobre el propio verificador.

Para ilustrar que estos flywheels ya existen hoy, el artículo pone dos ejemplos concretos. El primero es la programación asistida por agentes: un agente de código moderno no solo escribe código, sino que ejecuta un experimento completo —escribe, corre las pruebas, lee los fallos, reescribe, vuelve a correr las pruebas— sin que nadie revise las iteraciones intermedias; el humano solo revisa el diff final, y en casos de bajo riesgo, ni siquiera eso. Se cita que Anthropic afirma que la mayoría de su propio código ya lo escribe Claude Code, y que OpenAI reportó en febrero que GPT-5.3-Codex fue clave para construirse a sí mismo, depurando sus propios entrenamientos y analizando sus propias evaluaciones. El segundo ejemplo es un 'flywheel de optimización publicitaria' hipotético pero plausible: un workflow genera la creatividad (titular, copy, imagen), otro extrae el rendimiento de la consola de anuncios (impresiones, clics, conversiones), y un tercero decide el próximo experimento (matar al perdedor, escalar al ganador, probar un ángulo nuevo), todo funcionando de forma continua sin humano entre iteraciones, porque la consola de anuncios actúa como verificador objetivo.

El artículo explica por qué la programación fue el dominio donde este ciclo se cerró primero: el software acumuló durante cuarenta años infraestructura de verificación —compiladores, sistemas de tipos, suites de pruebas, integración continua (CI)— que ya codificaba 'qué aspecto tiene lo correcto' en forma ejecutable antes de que llegaran los LLMs. La publicidad tiene una versión más débil del mismo don: cifras de rendimiento objetivas, aunque ruidosas. Se recupera el 'principio Factory AI' del episodio anterior: la facilidad de entrenar un agente en una tarea es proporcional a cuán verificable es esa tarea; por eso el bucle se cerró primero donde el trabajo era más verificable.

Los autores trasladan esta lógica a cualquier organización, planteando una pregunta incómoda: ¿cuáles de tus workflows tienen un test suite? ¿cuáles tienen algo parecido? Para la mayoría de las empresas, la respuesta honesta es que sus workflows tienen humanos: el humano es la capa de verificación y también la capa de coordinación, quien decide qué workflow corre a continuación y si el esfuerzo global está funcionando. Esto implica que el humano es, precisamente, la razón por la que el flywheel no puede girar todavía en la mayoría de las organizaciones: si se le retira sin más, se revela una deuda de infraestructura que nadie había dimensionado.

La parte final visible del artículo se dedica al 'bucle más grande de todos': la propia investigación en IA. Se menciona el proyecto 'The AI Scientist', reportado en Nature en marzo, que automatiza el ciclo de investigación de punta a punta (genera ideas, ejecuta experimentos, escribe resultados y revisa sus propios papers). También se cita una startup llamada Recursive, que esta semana publicó resultados de un sistema que propone una idea de investigación, la implementa, ejecuta el experimento, valida el resultado y usa lo aprendido para elegir el siguiente experimento, ejecutando múltiples hilos durante horizontes largos, con mecanismos explícitos para detectar el 'reward hacking' antes de dar por válida una ganancia. Se menciona un artículo de Anthropic titulado 'When AI builds itself', publicado este mes, que afirma que una porción creciente del desarrollo de IA de la compañía ya se delega a sistemas de IA, y que, llevada al extremo, la tendencia apunta a sistemas que diseñan a sus propios sucesores. Se cita a Jack Clark, quien habría estimado una probabilidad de aproximadamente 60% de que exista, para finales de 2028, un sistema capaz de entrenar a un sucesor más potente sin intervención humana. También se referencia un artículo de Dean Ball titulado 'On Recursive Self-Improvement', de febrero, que sostiene que los laboratorios de frontera están automatizando grandes fracciones de sus operaciones de investigación, y que sus plantillas efectivas de agentes crecerían de miles a cientos de miles en uno o dos años.

Los propios autores introducen matices de cautela ante estas afirmaciones de los laboratorios, señalando que estos tienen incentivos para describir su propio impulso en los términos más contundentes posibles, y que sus previsiones podrían no cumplirse en los plazos indicados. Sin embargo, argumentan que el planteamiento organizacional se sostiene igualmente sin necesidad de asumir la llegada de una superinteligencia: basta con lo que ya está ocurriendo —bucles de trabajo cerrándose en dominios donde la verificación es fuerte— combinado con la observación de que la capacidad tecnológica se difunde y viaja entre dominios.

El texto se corta justo cuando promete abordar 'por qué esto te alcanza en un calendario que no controlas', dejando sin desarrollar en el material disponible los apartados sobre el cuello de botella de la revisión en workflows cerrados, los tres tipos de infraestructura que aún no existen, la doble dirección en que puede girar el flywheel (para bien o para mal), qué bucles conviene cerrar primero, y la nueva brecha entre organizaciones según su capacidad de verificación a velocidad de máquina. No obstante, el propio FAQ final del artículo adelanta pistas sobre estos temas: identifica el riesgo principal de un flywheel como el error compuesto y el reward hacking (dado que cada ejecución alimenta a la siguiente, los errores pequeños se propagan en lugar de quedar aislados, y el sistema puede optimizar una métrica medida perdiendo de vista la intención original), y sugiere como defensas las evaluaciones de regresión, los chequeos canary, la detección de drift, y mantener siempre un humano que revise el verificador en lugar de revisar cada output individual. También adelanta, sin desarrollarlo, que los workflows candidatos a cerrar el loop primero serían los de patrones de sincronización-y-transformación, triaje y monitorización, mientras que el trabajo basado en 'buen gusto' o criterio subjetivo —como redacción de contenido de cara al exterior— debería cerrarse en último lugar, si es que llega a cerrarse.

En conjunto, el fragmento disponible ofrece un marco conceptual claro y bien argumentado —pipeline, workflow, flywheel— y una tesis central potente: la clave de la autonomía segura no es eliminar al humano, sino trasladar su juicio a un verificador robusto, y la fortaleza de ese verificador determina qué tareas pueden automatizarse en bucle cerrado. Para quienes siguen el newsletter de Manuel, el valor práctico inmediato es la pregunta que plantea a cualquier organización: ¿qué workflows tienen ya un verificador equivalente a un test suite, y cuáles dependen todavía enteramente del juicio humano como única capa de control? Esa pregunta, más que las cifras sobre laboratorios de IA, parece ser el verdadero núcleo accionable del artículo, aunque para conocer las recomendaciones concretas de los autores sobre infraestructura y priorización habría que acceder a la versión completa de pago.