El equipo de IA e Infraestructura de Google publicó algo silenciosamente notable en una publicación de blog que la mayor parte de la industria pasó por alto: una aceleración seis veces mayor al migrar modelos de machine learning de producción de TensorFlow a JAX, a una escala que involucra miles de líneas de código, cientos de capas y dependencias que se extienden a través de múltiples archivos. Sundar Pichai lo mencionó en el escenario de Google Cloud Next. El número se llevó los titulares. La arquitectura subyacente es la verdadera historia, y es la misma arquitectura detrás de cada migración creíble de agentes a gran escala que ocurre ahora mismo, ya sea que el enjambre sea de 8 agentes o 800.
Aquí está el detalle que más importa: primero intentaron apuntar un solo agente de IA al código base. Falló. No parcialmente. Perdió el contexto, alucinó APIs que no existían y produjo código que no compilaba. La solución no fue un modelo más inteligente. Fue una arquitectura completamente diferente, una con un nombre ahora: el patrón de "fábrica oscura", un código base donde los agentes planifican, implementan, prueban y envían código con cero revisión humana en el proceso, de la misma manera que una fábrica totalmente automatizada opera máquinas en la oscuridad porque no queda nadie para encender las luces.
Este artículo es el desglose completo de ese patrón. No la versión de marketing. La mecánica real de cómo cientos de agentes migran un código base real sin que un humano verifique cada cambio individual, y por qué lo que lo hace seguro no es la confianza en el modelo, sino una arquitectura diseñada específicamente para nunca necesitar esa confianza en primer lugar.
Por qué un solo agente falla a escala
Antes de la arquitectura, entiende exactamente por qué el enfoque ingenuo se rompe, porque cada decisión de diseño en el patrón funcional existe específicamente para parchear una de estas fallas.
Un solo agente apuntado a un código base grande se encuentra primero con un problema de contexto. Incluso con una ventana de contexto generosa, un código base con cientos de archivos interdependientes, cadenas de llamadas profundas y suposiciones heredadas entre módulos excede lo que cualquier sesión individual puede mantener de manera coherente. El agente comienza fuerte en los primeros archivos y se degrada a medida que el contexto de trabajo se llena con un historial acumulado y semirelevante.
Luego se encuentra con un problema de secuenciación. La migración de código no es una tarea paralela por defecto. El archivo B a menudo depende de que el archivo A ya haya sido migrado, porque las firmas de las funciones cambiaron, las importaciones se movieron o las estructuras de datos cambiaron de forma. Un agente sin un mapa de dependencias explícito o adivina el orden, lo que produce estados intermedios rotos, o procesa los archivos en el orden en que aparecen, que es funcionalmente lo mismo que adivinar.
Luego se encuentra con un problema de verificación, y este es el que realmente más importa. Un agente que migra código y luego evalúa su propia migración está revisando su propio trabajo con los mismos puntos ciegos que produjeron cualquier error en primer lugar. Si el agente no entiende que una API en particular se comporta de manera diferente bajo una nueva versión, no detectará ese malentendido cuando revise su propio resultado, porque la misma brecha de comprensión está presente en ambas pasadas.
El equipo de Google descubrió esto directamente. La configuración de un solo agente no podía equilibrar las reglas estructurales de la migración con los detalles de ejecución línea por línea simultáneamente. Dividir esas dos preocupaciones en roles separados es la solución real, y es la misma solución que aparece de forma independiente en el libro de cocina de migración publicado de OpenAI, en la investigación académica sobre bucles de migración multiagente y en cada sistema de producción que realmente ejecuta esto a escala.
La arquitectura: tres roles, no un generalista
El patrón funcional divide el trabajo en roles con trabajos genuinamente diferentes, no solo diferentes indicaciones apuntadas al mismo agente generalista.
Un planificador que utiliza herramientas deterministas, no una suposición de LLM, para secuenciar el trabajo. Este es el detalle que separa un sistema que realmente escala de uno que se ve impresionante en una demostración y se desmorona en producción. El planificador de Google no le pide a un LLM que descubra el orden de migración a través del razonamiento. Utiliza análisis estático basado en compilador, la misma categoría de herramientas deterministas que ha sustentado el software empresarial durante décadas, para construir el árbol de dependencias real y definir un plan de ejecución que comienza desde los nodos hoja (archivos de los que nada más depende) y avanza hacia los archivos de los que todo lo demás depende.
Esto importa porque el orden de las dependencias no es un problema creativo. Es uno mecánico con una respuesta correcta, y usar un LLM para resolver un problema que ya tiene una solución determinista solo introduce una nueva fuente de error donde no es necesario que exista. La regla subyacente: en cualquier lugar donde un problema tenga una respuesta algorítmica, usa el algoritmo. Reserva el modelo de lenguaje para la parte de la tarea que realmente requiere juicio, que es la transformación de código real, no la secuenciación de qué archivo va primero.
Un agente de migración (o, en sistemas más grandes, cientos de ellos ejecutándose en paralelo, instancias aisladas y de alcance limitado del mismo rol) que realiza la transformación de código real. Cada instancia recibe una tarea con alcance definido, idealmente un archivo o un módulo estrictamente delimitado, un solo checkout y un resumen de migración explícito que describe exactamente qué necesita cambiar y por qué. Inspecciona el código relevante, realiza las ediciones y produce un parche. No decide si su propio parche es correcto. Ese no es su trabajo, y la arquitectura está diseñada específicamente para que no pueda asumir ese trabajo accidentalmente.
Una capa de entorno y verificación que construye, ejecuta y prueba el código migrado en un entorno aislado antes de que se acepte algo. Aquí es donde "hecho está hecho" se convierte en un hecho mecánico en lugar de una opinión. El planteamiento de Google es preciso: la industria ha ofrecido históricamente dos malas opciones para decidir cuándo el trabajo de una IA está realmente terminado: la revisión humana que no escala a cientos de archivos, o la autoevaluación de la IA que no se puede auditar porque no hay un registro de lo que realmente se verificó. Su respuesta es la verificación matemática, código determinista que confirma que la compilación se realiza correctamente, las pruebas pasan y el comportamiento coincide con una especificación definida, reemplazando ambas malas opciones con una tercera que es realmente inspeccionable.
Observa lo que falta en esta lista: un humano leyendo cada diff individual antes de que se fusione. Ese es el punto central del patrón de fábrica oscura, y también es exactamente donde la intuición de la mayoría de las personas sobre la seguridad se equivoca, porque parece que el sistema solo confía más en los agentes. Es lo contrario. Es confiar menos en los agentes, estructuralmente, al reemplazar el punto único de juicio, "¿dijo el agente que esto funcionó?", con una capa de verificación que el agente no puede influenciar ni eludir.
La capa de aislamiento: por qué cada agente obtiene su propio entorno aislado
Ejecutar cientos de agentes contra el mismo código base simultáneamente crea un riesgo obvio: ¿qué sucede cuando el agente 47 está a medio editar un archivo del que depende el cambio del agente 12, y la edición del agente 12 acaba de romper la compilación?
La respuesta, consistente en la arquitectura de migración publicada de OpenAI y el sistema de producción de Google, es el aislamiento por defecto. Cada tarea de migración se ejecuta en su propio entorno aislado, a menudo su propio worktree de git, un checkout completo e independiente del repositorio relevante con alcance para esa única tarea. Si un agente en ese entorno aislado rompe algo, rompe una copia aislada, no el código base compartido, y ciertamente no el trabajo en curso de otro agente.
Este aislamiento hace algo más que prevenir colisiones. Hace que todo el sistema sea trivialmente paralelizable, porque no hay un estado mutable compartido para que cientos de agentes simultáneos lo pisen. El agente 1 al agente 800 pueden ejecutarse genuinamente al mismo tiempo, cada uno en un entorno limpio que contiene solo los archivos y el contexto relevantes para su tarea específica, con cero riesgo de que la alucinación de un agente contamine el trabajo correcto de otro.
El arnés, la capa de orquestación que decide qué tarea va a qué entorno aislado y qué sucede con el parche resultante, permanece fuera de cada entorno aislado individual. Esta es una elección arquitectónica específica e importante: el proceso de confianza con acceso a secretos, herramientas externas y el repositorio real vive separado del entorno de ejecución no confiable donde se ejecuta el código generado por IA. El entorno aislado obtiene exactamente lo que necesita para su única tarea, nada más. El proceso anfitrión nunca ejecuta código generado directamente con sus propios permisos elevados. Esta separación es lo que hace seguro permitir que el código de un agente se ejecute, ya que un error o incluso una inyección de indicación adversaria dentro del entorno aislado no tiene camino hacia nada fuera de él.
El bucle en sí: planificar, ejecutar, verificar, refinar
Quita la escala y las herramientas específicas, y el bucle real que se ejecuta debajo de todo esto tiene cuatro etapas, repitiéndose por tarea hasta que esa tarea pase o agote su presupuesto de reintentos.
Etapa uno: planificación de la migración. El agente de migración recibe su tarea con alcance definido, un archivo o módulo, la especificación objetivo específica (versión del lenguaje, cambio de framework, requisitos de compatibilidad de API) y produce una transformación candidata. Esta es la única etapa donde el razonamiento creativo basado en el juicio del modelo de lenguaje realiza el trabajo principal, porque decidir cómo traducir correctamente un patrón específico a su equivalente en un nuevo framework requiere comprensión, no solo una búsqueda mecánica.
Etapa dos: configuración automatizada del entorno. Un componente separado, a veces llamado agente de entorno en la literatura académica sobre este patrón, construye de forma autónoma un entorno de compilación y ejecución para el código migrado, manejando la resolución de dependencias y la configuración para que el parche candidato pueda ser realmente compilado y ejecutado en condiciones realistas en lugar de ser evaluado en abstracto.
Etapa tres: validación de pruebas. El código migrado se ejecuta contra el conjunto de pruebas real, o contra un equivalente generado si no existe un conjunto de pruebas para ese módulo específico. Este es el paso de verificación mecánica, el que produce un aprobado o reprobado objetivo en lugar de una impresión. O las pruebas pasan o no, y no hay ambigüedad que un agente pueda eludir.
Etapa cuatro: refinamiento de retroalimentación. En caso de fallo, los fallos de prueba específicos y los registros de diagnóstico se enrutan de vuelta al agente de migración como entrada de corrección dirigida, no un vago "esto no funcionó, inténtalo de nuevo". El agente que posee el parche refina su lógica específica y su mapeo de dependencias basándose en evidencia concreta de lo que se rompió, no en un reintento genérico desde cero.
Este ciclo de cuatro etapas se repite por tarea, con un límite definido. Una versión documentada y funcional de este patrón de bucle exacto especifica una condición de parada como "ningún archivo coincide con el patrón antiguo" junto con un número máximo de iteraciones fijo, en un ejemplo publicado, 200 iteraciones, después del cual el sistema se detiene automáticamente en lugar de ejecutarse indefinidamente en una tarea que no converge.
Ese límite importa enormemente a escala. Sin él, una tarea que es estructuralmente imposible de completar, porque la especificación en sí es ambigua o el patrón objetivo realmente no tiene un equivalente limpio, quemaría recursos para siempre en lugar de surgir como un fallo específico y acotado que un humano pueda mirar y resolver.
Por qué la revisión humana no escala y qué la reemplaza
Vale la pena ser preciso sobre por qué "ningún humano revisando cada uno" es en realidad el diseño más seguro aquí, no un atajo.
La investigación que compara la revisión de código de agentes de IA con la revisión de código humana encontró algo específico y útil: los comentarios de revisión generados por IA son casi siete veces más largos por línea de código que las revisiones humanas y se concentran casi por completo en la mejora del código y la detección de defectos, mientras que la revisión humana se extiende naturalmente a otras cosas por completo: construir comprensión compartida, transferir conocimiento, comunicación social entre compañeros de equipo. La interacción de revisión humana de ida y vuelta varía enormemente según el tipo de retroalimentación. La interacción de revisión de IA a IA es mucho más uniforme y mecánica independientemente de lo que se señale.
Léelo correctamente y dice algo importante: la revisión humana y la verificación de IA son buenas en cosas estructuralmente diferentes. Pedirle a un humano que revise 800 diffs individuales a la velocidad y el volumen que produce un enjambre de agentes no es una mejora de seguridad, es un cuello de botella que produce una aprobación de sello de goma, porque ningún humano puede mantener un escrutinio genuino en ese volumen. La seguridad real en el patrón de fábrica oscura no proviene de eliminar la verificación. Proviene de reemplazar un tipo de verificación, atención humana lenta, agotadora e inconsistente repartida en cientos de diffs repetitivos, con un tipo diferente que escala: validación de compilación y prueba determinista que produce el mismo rigor en el diff 1 y en el diff 800, con cero fatiga de atención.
Esta es también precisamente la razón por la que la etapa del planificador utiliza análisis estático basado en compilador en lugar del juicio del LLM para la secuenciación. En cualquier lugar del sistema donde una verificación determinista pueda reemplazar una llamada de juicio, debería hacerlo, porque las verificaciones deterministas son la única parte de esta arquitectura que es genuinamente auditable después del hecho. Puedes reproducir exactamente lo que encontró un analizador estático. No puedes reproducir completamente por qué un modelo de lenguaje "sintió" que un orden de migración particular era correcto.
Lo que todavía necesita un humano y dónde está la línea
Este patrón no es "eliminar a los humanos por completo y esperar". Cada versión creíble publicada del mismo, el sistema de producción de Google, la investigación académica de Environment-in-the-Loop, el propio libro de cocina de OpenAI, dibuja una línea explícita sobre dónde el juicio humano sigue siendo obligatorio.
El hallazgo consistente en un estudio cuantitativo de migraciones de bibliotecas impulsadas por agentes: los agentes logran de manera confiable una alta cobertura de migración, identificando correctamente qué cambios de API son necesarios, pero específicamente luchan por preservar el comportamiento general de la aplicación en los casos más complejos, donde una migración exitosa requiere comprender la intención, no solo el patrón de sintaxis. La recomendación que sigue directamente de ese hallazgo es un punto de control humano en el bucle específicamente para el subconjunto de archivos que la verificación determinista marca como de alto riesgo o baja confianza, no para todo el lote.
En la práctica, esto produce un sistema escalonado. Los archivos que el análisis de dependencias estático clasifica como pequeños, bien aislados y estructuralmente simples, la mayor parte de cualquier migración real, fluyen a través del bucle totalmente automatizado con cero intervención humana más allá de la puerta de compilación y prueba determinista. Los archivos marcados como complejos, profundamente interconectados o que tocan lógica crítica para el negocio se enrutan a una cola para una revisión humana real antes de fusionarse, incluso dentro de un sistema por lo demás totalmente automatizado.
Este enfoque escalonado es la versión realista de "800 agentes, cero humanos revisando cada uno". No es que ningún humano mire nada nunca. Es que el sistema está específicamente diseñado para enrutar el 95% del trabajo mecánico y de bajo riesgo a través de la automatización completa, mientras concentra el recurso escaso, el juicio humano genuino, exclusivamente en la pequeña fracción de casos donde realmente agrega valor que la verificación determinista no puede replicar.
Construyendo esto para tu propio código base
El patrón escala hacia abajo tan limpiamente como escala hacia arriba. Los mismos cuatro roles se aplican ya sea que estés ejecutando 800 agentes paralelos contra un código base de producción masivo o un puñado de tareas de migración secuenciales contra un solo repositorio.
Comienza con el planificador y resiste la tentación de convertirlo en un LLM. Si tu migración tiene algún tipo de estructura de dependencia, importaciones de archivos, interfaces compartidas, orden de compilación, utiliza herramientas de análisis estático reales apropiadas para tu lenguaje para construir ese gráfico de dependencias mecánicamente. Esta única decisión es la de mayor apalancamiento en todo el sistema, porque cada etapa posterior hereda cualquier error de orden que el planificador cometa.
Define el alcance de cada tarea individual tan estrechamente como lo permita el gráfico de dependencias. Un archivo, un módulo, una unidad de cambio claramente delimitada, con un resumen explícito que describa exactamente qué debe suceder y por qué. Resiste la tentación de combinar múltiples cambios no relacionados en una sola tarea por eficiencia, porque el alcance estrecho es lo que hace que el juicio de aprobado o reprobado de la etapa de verificación sea inequívoco.
Aísla la ejecución de cada tarea. Un worktree de git fresco por tarea como mínimo, un entorno completamente aislado si estás ejecutando esto a cualquier escala real. Esto no es una sobrecarga de infraestructura opcional. Es lo que hace que la paralelización sea segura y que el error de un solo agente esté contenido en lugar de ser contagioso.
Construye la verificación determinista antes de construir cualquier otra cosa. Éxito de compilación, tasa de aprobación del conjunto de pruebas, comprobaciones de equivalencia de comportamiento donde puedas construirlas. Este es el componente que reemplaza "¿dijo el agente que funcionó?" con "¿funcionó realmente?", y es el componente único que la mayoría de los intentos de migración caseros omiten por completo, que es exactamente por qué esos intentos fallan a cualquier escala significativa.
Limita el bucle de reintento explícitamente, con un número, no con una sensación. Define cómo se ve "esta tarea está atascada" antes de ejecutar cualquier cosa, y enruta las tareas atascadas a una cola humana automáticamente en lugar de dejar que consuman recursos indefinidamente o, peor aún, informen silenciosamente un falso éxito.
La lección real debajo del número del titular
Sea cual sea el número real que se ejecute en cualquier migración a gran escala específica, 800 agentes u 80 u 8.000, la cifra del titular es la parte menos interesante de la historia. La parte interesante es que ninguno de esos agentes es confiable individualmente para decidir si su propio trabajo es correcto, y todo el sistema está diseñado en torno a esa desconfianza en lugar de a pesar de ella.
Una fábrica oscura no funciona en la oscuridad porque nadie esté mirando. Funciona en la oscuridad porque la vigilancia se ha trasladado por completo a la maquinaria misma, a las comprobaciones del compilador, los conjuntos de pruebas y los gráficos de dependencias que producen la misma respuesta rigurosa cada vez, en el archivo uno y en el archivo ochocientos, sin fatiga y sin la inconsistencia que proviene de pedirle a un humano que haga la misma llamada de juicio repetitiva miles de veces seguidas.
Ese es el patrón real detrás de cada versión de esto que funciona en producción ahora mismo. No una confianza más audaz en modelos más grandes. Una negativa más disciplinada a dejar que cualquier componente individual, humano o IA, sea el único juez de su propio trabajo.
Sigue a @cyrilxbt para más contenido sobre IA
