A equipe de IA e Infraestrutura do Google publicou algo silenciosamente notável em um post de blog que a maior parte do setor ignorou: uma aceleração de seis vezes na migração de modelos de machine learning de produção do TensorFlow para o JAX, em uma escala que envolve milhares de linhas de código, centenas de camadas e dependências profundas espalhadas por vários arquivos. Sundar Pichai mencionou isso no palco do Google Cloud Next. O número virou manchete. A arquitetura por trás dele é a verdadeira história, e é a mesma arquitetura por trás de toda migração de agente em larga escala que está acontecendo agora, seja o enxame de 8 ou 800 agentes.
Aqui está o detalhe mais importante: eles tentaram primeiro apontar um único agente de IA para a base de código. Falhou. Não parcialmente. Ele perdeu o contexto, alucinou APIs que não existiam e produziu código que não compilava. A solução não foi um modelo mais inteligente. Foi uma arquitetura completamente diferente, com um nome agora: o padrão "dark factory" (fábrica escura), uma base de código onde agentes planejam, implementam, testam e entregam código com zero revisão humana no processo, da mesma forma que uma fábrica totalmente automatizada opera máquinas no escuro porque não há mais ninguém para acender as luzes.
Este artigo é a análise completa desse padrão. Não a versão de marketing. A mecânica real de como centenas de agentes migram uma base de código real sem um humano verificando cada alteração individual, e por que o que torna isso seguro não é a confiança no modelo, mas uma arquitetura especificamente projetada para nunca precisar dessa confiança em primeiro lugar.
Por que um Único Agente Falha em Escala
Antes da arquitetura, entenda exatamente por que a abordagem ingênua quebra, porque cada decisão de design no padrão funcional existe especificamente para corrigir uma dessas falhas.
Um único agente apontado para uma grande base de código enfrenta primeiro um problema de contexto. Mesmo com uma janela de contexto generosa, uma base de código com centenas de arquivos interdependentes, cadeias de chamadas profundas e suposições herdadas entre módulos excede o que qualquer sessão única consegue manter de forma coerente. O agente começa bem nos primeiros arquivos e degrada à medida que o contexto de trabalho se enche de histórico acumulado e semirrelevante.
Então ele encontra um problema de sequenciamento. A migração de código não é uma tarefa paralela por padrão. O arquivo B geralmente depende do arquivo A já ter sido migrado, porque as assinaturas das funções mudaram, os imports foram movidos ou as estruturas de dados mudaram de forma. Um agente sem um mapa de dependências explícito ou adivinha a ordem, o que produz estados intermediários quebrados, ou processa os arquivos na ordem em que aparecem listados, o que é funcionalmente o mesmo que adivinhar.
Então ele encontra um problema de verificação, e este é o que realmente importa mais. Um agente que migra código e depois avalia sua própria migração está verificando seu próprio dever de casa com os mesmos pontos cegos que produziram quaisquer erros em primeiro lugar. Se o agente não entende que uma API específica se comporta de forma diferente em uma nova versão, ele não perceberá esse mal-entendido ao revisar sua própria saída, porque a mesma lacuna de entendimento está presente em ambas as passagens.
A equipe do Google descobriu isso diretamente. A configuração de agente único não conseguia equilibrar as regras estruturais da migração com os detalhes de execução linha por linha simultaneamente. Separar essas duas preocupações em funções distintas é a verdadeira solução, e é a mesma solução que aparece de forma independente no cookbook de migração publicado pela OpenAI, na pesquisa acadêmica sobre loops de migração multiagente e em todos os sistemas de produção que realmente executam isso em escala.
A Arquitetura: Três Funções, Não Um Generalista
O padrão funcional divide o trabalho em funções com trabalhos genuinamente diferentes, não apenas prompts diferentes apontados para o mesmo agente generalista.
Um Planejador que usa ferramentas determinísticas, não um palpite de LLM, para sequenciar o trabalho. Este é o detalhe que separa um sistema que realmente escala de um que parece impressionante em uma demonstração e desmorona em produção. O Planejador do Google não pede a um LLM para descobrir a ordem de migração através do raciocínio. Ele usa análise estática baseada em compilador, a mesma categoria de ferramentas determinísticas que sustenta o software empresarial há décadas, para construir a árvore de dependências real e definir um plano de execução que começa a partir dos nós folha (arquivos dos quais nada mais depende) e sobe em direção aos arquivos dos quais todo o resto depende.
Isso é importante porque a ordenação de dependências não é um problema criativo. É um problema mecânico com uma resposta correta, e usar um LLM para resolver um problema que já tem uma solução determinística apenas introduz uma nova fonte de erro onde nenhuma precisa existir. A regra subjacente a isso: em qualquer lugar onde um problema tem uma resposta algorítmica, use o algoritmo. Reserve o modelo de linguagem para a parte da tarefa que realmente exige julgamento, que é a transformação real do código, não o sequenciamento de qual arquivo vem primeiro.
Um Agente de Migração (ou, em sistemas maiores, centenas deles executando em paralelo, instâncias isoladas e de escopo estreito da mesma função) que faz a transformação real do código. Cada instância recebe uma tarefa com escopo definido, idealmente um arquivo ou um módulo rigidamente delimitado, um único checkout e um resumo de migração explícito descrevendo exatamente o que precisa mudar e por quê. Ele inspeciona o código relevante, faz as edições e produz um patch. Ele não decide se seu próprio patch está correto. Esse não é seu trabalho, e a arquitetura é especificamente projetada para que ele não possa assumir acidentalmente esse trabalho.
Uma Camada de Ambiente e Verificação que constrói, executa e testa o código migrado em um ambiente isolado antes que qualquer coisa seja aceita. É aqui que "pronto é pronto" se torna um fato mecânico em vez de uma opinião. O enquadramento do Google sobre isso é preciso: a indústria historicamente ofereceu duas opções ruins para decidir quando o trabalho de uma IA está realmente concluído: revisão humana que não escala para centenas de arquivos, ou autoavaliação de IA que não pode ser auditada porque não há registro do que foi realmente verificado. A resposta deles é a verificação matemática, código determinístico que confirma que a compilação foi bem-sucedida, os testes passam e o comportamento corresponde a uma especificação definida, substituindo ambas as opções ruins por uma terceira que é realmente inspecionável.
Observe o que está faltando nesta lista: um humano lendo cada diff individual antes de mesclar. Esse é o ponto central do padrão dark factory, e é também exatamente onde a intuição da maioria das pessoas sobre segurança falha, porque parece que o sistema está apenas confiando mais nos agentes. É o oposto. É confiar menos nos agentes, estruturalmente, substituindo o ponto único de julgamento, "o agente disse que isso funcionou", por uma camada de verificação que o agente não pode influenciar ou contornar com argumentos.
A Camada de Isolamento: Por que Cada Agente Tem Sua Própria Sandbox
Executar centenas de agentes contra a mesma base de código simultaneamente cria um risco óbvio: o que acontece quando o agente 47 está no meio de uma edição em um arquivo do qual a alteração do agente 12 depende, e a edição do agente 12 acabou de quebrar a compilação.
A resposta, consistente entre a arquitetura de migração publicada pela OpenAI e o sistema de produção do Google, é o isolamento por padrão. Cada tarefa de migração é executada em seu próprio ambiente em sandbox, geralmente sua própria git worktree, um checkout completo e independente do repositório relevante com escopo para aquela única tarefa. Se um agente nessa sandbox quebrar algo, ele quebra uma cópia isolada, não a base de código compartilhada, e definitivamente não o trabalho em andamento de outro agente.
Esse isolamento faz algo além de apenas prevenir colisões. Torna todo o sistema trivialmente paralelizável, porque não há estado mutável compartilhado para centenas de agentes simultâneos pisarem. Do agente 1 ao agente 800 podem ser executados genuinamente ao mesmo tempo, cada um em um ambiente limpo contendo apenas os arquivos e o contexto relevantes para sua tarefa específica, com risco zero de a alucinação de um agente contaminar o trabalho correto de outro.
O harness, a camada de orquestração que decide qual tarefa vai para qual sandbox e o que acontece com o patch resultante, permanece fora de cada sandbox individual. Esta é uma escolha arquitetônica específica e importante: o processo confiável com acesso a segredos, ferramentas externas e o repositório real vive separadamente do ambiente de execução não confiável onde o código gerado por IA realmente é executado. A sandbox recebe exatamente o que precisa para sua única tarefa, nada mais. O processo host nunca executa código gerado diretamente com suas próprias permissões elevadas. Essa separação é o que torna seguro permitir que o código de um agente seja executado, já que um erro ou até mesmo uma injeção de prompt adversária dentro da sandbox não tem caminho para nada fora dela.
O Loop em Si: Planejar, Executar, Verificar, Refinar
Remova a escala e as ferramentas específicas, e o loop real que está sendo executado por baixo de tudo isso tem quatro estágios, repetindo por tarefa até que ela passe ou esgote seu orçamento de tentativas.
Estágio um: planejamento da migração. O Agente de Migração recebe sua tarefa com escopo definido, um arquivo ou módulo, a especificação de destino específica (versão da linguagem, mudança de framework, requisitos de compatibilidade de API) e produz uma transformação candidata. Este é o único estágio onde o raciocínio criativo e baseado em julgamento do modelo de linguagem está fazendo o trabalho principal, porque decidir como traduzir corretamente um padrão específico em seu equivalente em um novo framework genuinamente requer compreensão, não apenas consulta mecânica.
Estágio dois: configuração automatizada do ambiente. Um componente separado, às vezes chamado de Agente de Ambiente na literatura acadêmica sobre este padrão, constrói autonomamente um ambiente de construção e execução para o código migrado, lidando com a resolução de dependências e configuração para que o patch candidato possa realmente ser compilado e executado sob condições realistas, em vez de avaliado no abstrato.
Estágio três: validação de teste. O código migrado é executado contra o conjunto de testes real, ou contra um equivalente gerado se não existir um conjunto de testes para aquele módulo específico. Esta é a etapa de verificação mecânica, que produz um resultado objetivo de aprovação ou reprovação, em vez de uma impressão. Ou os testes passam ou não passam, e não há ambiguidade para um agente contornar com argumentos.
Estágio quatro: refinamento com feedback. Em caso de falha, as falhas de teste específicas e os logs de diagnóstico são roteados de volta ao Agente de Migração como entrada de correção direcionada, não um vago "isso não funcionou, tente novamente." O agente que possui o patch refina sua lógica específica e mapeamento de dependências com base em evidências concretas do que quebrou, não em uma nova tentativa genérica do zero.
Este ciclo de quatro estágios se repete por tarefa, com um limite definido. Uma versão documentada e funcional deste padrão de loop exato especifica uma condição de parada como "nenhum arquivo corresponde mais ao padrão antigo" junto com uma contagem máxima de iterações, em um exemplo publicado, 200 iterações, após as quais o sistema para automaticamente em vez de ser executado indefinidamente em uma tarefa que não está convergindo.
Esse limite é extremamente importante em escala. Sem ele, uma tarefa estruturalmente impossível de concluir, porque a especificação em si é ambígua ou o padrão de destino genuinamente não tem um equivalente claro, consumiria recursos para sempre em vez de se manifestar como uma falha específica e limitada que um humano pode realmente examinar e resolver.
Por que a Revisão Humana Não Escala, e o que a Substitui
Vale a pena ser preciso sobre por que "nenhum humano revisando cada um" é, na verdade, o design mais seguro aqui, não um atalho sendo tomado.
A pesquisa comparando a revisão de código por agente de IA com a revisão de código humana descobriu algo específico e útil: os comentários de revisão gerados por IA são quase sete vezes mais longos por linha de código do que as revisões humanas e se concentram quase inteiramente na melhoria do código e na detecção de defeitos, enquanto a revisão humana naturalmente se espalha por outras coisas completamente: construir entendimento compartilhado, transferir conhecimento, comunicação social entre colegas de equipe. O vai e vem da revisão humana varia enormemente dependendo do tipo de feedback. A interação de revisão entre IA é muito mais uniforme e mecânica, independentemente do que está sendo sinalizado.
Leia isso corretamente e diz algo importante: a revisão humana e a verificação de IA são boas em coisas estruturalmente diferentes. Pedir a um humano para revisar 800 diffs individuais na velocidade e volume que um enxame de agentes produz não é uma melhoria de segurança, é um gargalo que produz aprovação por carimbo, porque nenhum humano pode manter um escrutínio genuíneo nesse volume. A segurança real no padrão dark factory não vem da remoção da verificação. Vem da substituição de um tipo de verificação, atenção humana lenta, exaustiva e inconsistente espalhada por centenas de diffs repetitivos, por um tipo diferente que escala: validação determinística de construção e teste que produz o mesmo rigor no diff 1 e no diff 800, com zero fadiga de atenção.
Esta é também precisamente a razão pela qual o estágio do Planejador usa análise estática baseada em compilador em vez de julgamento de LLM para sequenciamento. Em qualquer lugar do sistema onde uma verificação determinística pode substituir uma decisão de julgamento, ela deve, porque as verificações determinísticas são a única parte desta arquitetura que é genuinamente auditável posteriormente. Você pode reproduzir exatamente o que um analisador estático encontrou. Você não pode reproduzir completamente por que um modelo de linguagem "sentiu" que uma ordem de migração específica estava correta.
O que Ainda Precisa de um Humano, e Onde a Linha Realmente Está
Este padrão não é "remover humanos completamente e torcer." Cada versão publicada e confiável dele, o sistema de produção do Google, a pesquisa acadêmica Environment-in-the-Loop, o próprio cookbook da OpenAI, traça uma linha explícita sobre onde o julgamento humano permanece obrigatório.
A descoberta consistente em um estudo quantitativo de migrações de bibliotecas orientadas por agentes: os agentes alcançam de forma confiável uma alta cobertura de migração, identificando corretamente quais mudanças de API são necessárias, mas especificamente lutam para preservar o comportamento geral da aplicação nos casos mais complexos, onde uma migração bem-sucedida requer a compreensão da intenção, não apenas a correspondência de padrões de sintaxe. A recomendação que segue diretamente dessa descoberta é um ponto de verificação humano-no-loop especificamente para o subconjunto de arquivos que a verificação determinística sinaliza como de alto risco ou baixa confiança, não para todo o lote.
Na prática, isso produz um sistema em camadas. Arquivos que a análise de dependência estática classifica como pequenos, bem isolados e estruturalmente simples, a maior parte de qualquer migração real, fluem pelo loop totalmente automatizado com zero toque humano além do portão determinístico de construção e teste. Arquivos sinalizados como complexos, profundamente interconectados ou que tocam em lógica crítica de negócios são roteados para uma fila para revisão humana real antes da mesclagem, mesmo dentro de um sistema de outra forma totalmente automatizado.
Esta abordagem em camadas é a versão realista de "800 agentes, zero humanos revisando cada um." Não é que nenhum humano nunca olhe para nada. É que o sistema é especificamente arquitetado para rotear os 95% do trabalho mecânico e de baixo risco através da automação total, enquanto concentra o recurso escasso, o julgamento humano genuíno, exclusivamente na pequena fração de casos onde ele realmente agrega valor que a verificação determinística não consegue replicar.
Construindo Isso para Sua Própria Base de Código
O padrão escala para baixo tão facilmente quanto escala para cima. As mesmas quatro funções se aplicam, quer você esteja executando 800 agentes paralelos contra uma enorme base de código de produção ou um punhado de tarefas de migração sequenciais contra um único repositório.
Comece com o Planejador e resista ao impulso de torná-lo um LLM. Se sua migração tem qualquer tipo de estrutura de dependência, imports de arquivo, interfaces compartilhadas, ordem de construção, use ferramentas reais de análise estática apropriadas para sua linguagem para construir esse grafo de dependências mecanicamente. Esta única decisão é a de maior alavancagem em todo o sistema, porque cada estágio downstream herda quaisquer erros de ordenação que o Planejador cometer.
Defina o escopo de cada tarefa individual o mais estreitamente que o grafo de dependências permitir. Um arquivo, um módulo, uma unidade de mudança claramente delimitada, com um resumo explícito descrevendo exatamente o que precisa acontecer e por quê. Resista a combinar várias mudanças não relacionadas em uma única tarefa puramente por eficiência, porque o escopo estreito é o que torna o julgamento de aprovação ou reprovação do estágio de verificação inequívoco.
Isole a execução de cada tarefa. Uma nova git worktree por tarefa no mínimo, um ambiente completo em sandbox se você estiver executando isso em qualquer escala real. Isso não é uma sobrecarga de infraestrutura opcional. É a coisa que torna a paralelização segura e faz com que o erro de um único agente seja contido em vez de contagioso.
Construa a verificação determinística antes de construir qualquer outra coisa. Sucesso na compilação, taxa de aprovação no conjunto de testes, verificações de equivalência comportamental onde você puder construí-las. Este é o componente que substitui "o agente disse que funcionou" por "realmente funcionou", e é o único componente que a maioria das tentativas de migração caseiras pula completamente, que é exatamente por que essas tentativas falham em qualquer escala significativa.
Limite o loop de repetição explicitamente, com um número, não uma sensação. Defina como é "esta tarefa está travada" antes de executar qualquer coisa, e roteie tarefas travadas para uma fila humana automaticamente, em vez de deixá-las consumir recursos indefinidamente ou, pior, relatar silenciosamente um falso sucesso.
A Verdadeira Lição por Trás do Número da Manchete
Seja qual for o número real em execução em qualquer migração de grande escala específica, 800 agentes ou 80 ou 8.000, o número da manchete é a parte menos interessante da história. A parte interessante é que nenhum desses agentes é individualmente confiável para decidir se seu próprio trabalho está correto, e todo o sistema é projetado em torno dessa desconfiança, e não apesar dela.
Uma dark factory não funciona no escuro porque ninguém está vigiando. Ela funciona no escuro porque a vigilância foi movida inteiramente para dentro da própria maquinaria, para verificações de compilador e conjuntos de testes e grafos de dependências que produzem a mesma resposta rigorosa todas as vezes, no arquivo um e no arquivo oitocentos, sem fadiga e sem a inconsistência que vem de pedir a um humano para fazer o mesmo julgamento repetitivo milhares de vezes seguidas.
Esse é o padrão real por trás de cada versão disso que está funcionando em produção agora. Não uma confiança mais corajosa em modelos maiores. Uma recusa mais disciplinada em deixar qualquer componente único, humano ou IA, ser o único juiz de seu próprio trabalho.
Siga @cyrilxbt para mais conteúdo sobre IA
