Uma fábrica de software é feita de loops contidos em harnesses, operando em escala. Você pode executar o loop com humanos no processo (fábrica iluminada): trocando julgamento e concentração por velocidade e risco de quebra. Ou pode ignorar os humanos (fábrica escura) e deixar que esses agentes escopem, construam e entreguem código, sem que ninguém realmente leia os detalhes. Mas, se as pessoas pararem de ler, elas deixarão de entender o seu software. Seu trabalho mais difícil agora é saber quais verificações construir e quanta autonomia delegar.
Essa ideia de fábrica de software é um termo que remonta ao artigo de Bob Bemer, "The economics of program production", apresentado em 1968. Por meio século, muitos sonharam com um mundo onde o software fosse um processo de produção repetível e instrumentável (análogo a estampar peças de carro em uma fábrica), em vez do ofício isolado de indivíduos. Historicamente, esse sonho geralmente (embora não universalmente) fracassou, em parte devido à dificuldade de "estampar" ideias.
Mas nos últimos dois anos, as coisas mudaram de forma tão drástica que agora faz sentido reexaminar o velho sonho. E como algumas sutilezas podem ser facilmente ignoradas, vale a pena ser um tanto preciso sobre o que realmente é novo e diferente, e o que podem ser armadilhas recorrentes, disfarçadas de novas oportunidades.
@dexhorthy, cofundador da HumanLayer, deu recentemente uma ótima palestra na AI Engineer World's Fair chamada "Harness Engineering is not Enough: Why Software Factories Fail." que vale a pena conferir sobre este tópico.
O loop é o átomo. A fábrica é o loop em escala.
Estrutura é tudo, e tudo começa com unidades pequenas. Toda a pilha é, na verdade, três conceitos empilhados uns sobre os outros: o loop, o harness e a fábrica.
Um loop é um agente fazendo um único trabalho repetidamente: reunir contexto, agir, verificar o resultado e repetir até que alguma condição seja atendida. É a menor unidade de trabalho agentivo, e tudo acima dele são apenas loops empilhados sobre loops.
O objetivo da engenharia de loops é que você pare de dar instruções ao agente turno por turno e, em vez disso, projete o pequeno sistema que dá as instruções por você.
Um harness são as paredes em torno de um loop: a sandbox onde ele é executado, as ferramentas que pode acessar, a memória que persiste entre as execuções e as comportas que decidem o que significa "pronto". O loop é o comportamento; o harness é o ambiente dentro do qual esse comportamento é executado.
Entregue um modelo bruto sem harness e ele ficará felizmente rodando para sempre. O harness é tudo ao redor que o torna útil e seguro de executar.
Uma fábrica de software é muitos loops contidos em harnesses executando simultaneamente, alimentados por uma fila de trabalho e drenados através de um portão de revisão para a produção, com humanos supervisionando tudo de cima. Não é um agente maior; é um organograma feito de loops.
A mudança de paradigma final é passar de escrever código para construir e operar a fábrica que o escreve. A unidade de trabalho sobe um nível, para o loop, o harness e o fluxo entre eles, em vez da diff de código individual.
Loop → harness → fábrica. Uma fábrica não é um agente mais inteligente; são muitos loops contidos em harnesses alimentando um único portão de revisão, com um humano supervisionando o loop externo. A fábrica, desenhada
O slide central em que Dex mais se concentrou foi brilhante porque é um diagrama de fiação esclarecedor que visualiza o que de outra forma seria um loop óbvio. Aqui está minha interpretação:
A fábrica é um loop fechado: a intenção e os sinais de produção alimentam uma fila, o harness constrói, verificações automatizadas e o portão de revisão aprovam, o deploy envia para produção, e o monitoramento transforma a produção de volta em sinais. A intenção flui da visão da liderança de engenharia, e diretamente dos engenheiros, para uma fila de coisas a serem feitas. Sinais gerados por incidentes e solicitações de usuários impulsionam a mesma fila.
O harness é simplesmente a coisa que pega um item da fila e constrói uma alteração para ele. Além do harness, podemos ver todas as verificações automatizadas necessárias para tornar as alterações seguras o suficiente para serem liberadas na produção. Essas verificações automatizadas são executadas de uma vez, sem esforço, sem qualquer envolvimento consciente dos engenheiros, graças a CI, testes, análise estática e varreduras de todos os tipos. O único ponto de decisão aqui é o portão de revisão. Após a aprovação, as alterações são implantadas e monitoradas em produção, com os dados de monitoramento alimentando de volta os sinais que iniciaram o loop.
Em geral, cada caixa neste diagrama tem custo quase zero: geração, testes, varredura. Todas operam em escala por um custo insignificante. Há apenas uma caixa cara que se mostra teimosamente resistente à escala, e esse é o portão de revisão. Aquela caixa âmbar brilhante é o "julgamento", e é onde reside o cerne do argumento sobre se podemos tornar o desenvolvimento mais rápido e mais frequente.
Por que chamamos de "escura"
Uma fábrica escura opera com as luzes fisicamente apagadas, porque as únicas coisas no chão de fábrica são máquinas, e máquinas não precisam de luz para enxergar. Uma fábrica de software escura é o mesmo movimento: código é enviado que nenhum humano leu, verificado apenas por outras máquinas.
A imagem é emprestada da manufatura. Suas origens são físicas, não digitais, enraizadas em instalações onde as luzes são apagadas e o trabalho é realizado por robôs. A FANUC no Japão opera fábricas "lights-out" desse tipo desde 2001; a Xiaomi, em 2024, abriu sua própria fábrica escura altamente automatizada. O que elas têm em comum é um produto montado e enviado sem que um único humano tenha lido qualquer parte dele. O "escuro" surge quando esse ato de leitura é removido do processo.
Não estou pegando o conceito emprestado pela sua vibe ou como um insulto. Apesar de todo o seu zumbido inquietante, "escuro" aqui é uma afirmação física simples: o chão de fábrica original, mas sem luz. Em software, o chão é a diff. Quem quer que tenha escrito a diff, quem quer que a tenha revisado, quem quer que a tenha enviado, esses humanos se foram, e o que resta é uma diff verificada apenas pelas máquinas que a construíram.
Isso é surpreendentemente fácil de fazer, pelo menos no começo. É fácil porque a etapa de revisão ausente atrapalha tudo. Sua ausência faz com que sua percepção da produtividade vertical da sua equipe pareça repentina e radicalmente maior. Parece que você quebrou a barreira do som. Apesar de toda sua aparente facilidade, é mais difícil do que parece sobreviver a esses fluxos de trabalho escuros, com todos os seus custos ocultos.
Harness Engineering não é suficiente
O harness de orquestração, prototipagem em sandbox e chamada de ferramentas, à medida que os modelos interagem com o mundo e entre si, se tornará cada vez mais poderoso e eficaz. No entanto, há uma falha inerente ao modelo ao tentar acompanhar a qualidade do código-fonte no longo prazo e através de mudanças incrementais, e acredito que há boas razões para acreditar que os modelos sozinhos, em última análise, perderão essa batalha contra a dívida de compreensão.
A dívida de compreensão é a lacuna crescente entre quanto código existe e quanto qualquer humano ainda entende. Uma fábrica escura não a reduz; ela a acumula o mais rápido possível, com os testes sempre verdes.
Essa é uma distinção importante porque os modelos se saem bem em algumas tarefas. Mas para qualquer coisa que não seja uma alteração imediata em uma pequena parte de um código-fonte, especialmente em um sistema brownfield complexo, a codificação automatizada apenas por modelo enfrenta um obstáculo intransponível. Aplicativos greenfield, brinquedos de fim de semana e projetos paralelos são semelhantes no sentido de que alguns meses de ciclos de desenvolvimento geralmente são suficientes para colocar as coisas em ordem, ou pelo menos perto o suficiente.
Mas um sistema empresarial que está em desenvolvimento há uma década ou mais é uma fera diferente; ele precisa ser mantido, em um ambiente profissional, em um ritmo profissional. De três a seis meses em um projeto, você já está afogado em código não lido. Esse tipo de ambiente, e especialmente as restrições impostas pelo código de produção, faria até mesmo um agente poderoso ter um desempenho ruim, tudo em contraste com o "vibe-coding" apreciado por desenvolvedores trabalhando em brinquedos de fim de semana.
Dex relata por experiência que esta é uma grande falha, tanto que exigiu uma depuração manual meticulosa para ser identificada. Isso veio da execução de uma fábrica de código totalmente automatizada por cerca de quatro meses, durante os quais nenhum humano olhou para o código que foi escrito. Subjacente a essa experiência está uma troca entre duas métricas conflitantes. Uma é maximizar a utilização de tokens, o número que atualmente tratamos como progresso. A outra, que ela silenciosamente minimiza, é a quantidade do sistema que qualquer participante humano ainda entende em qualquer momento.
Onde a fábrica escura realmente brilha é em sua capacidade de queimar código imaculado enquanto os testes permanecem verdes. O acerto de contas final, quando chegar, não será um momento dramático de "tudo vai pelos ares". Será silencioso e tardio.
Escuro e iluminado são o mesmo pipeline com as luzes em lugares diferentes. A versão iluminada não apenas readiciona a revisão no final - ela move o julgamento humano para upstream, para o design e a arquitetura também. O gargalo nunca foi a geração
A restrição fundamental em uma fábrica de software não é quanto código podemos produzir: é a rapidez com que podemos verificá-lo.
Contrapressão é a regra de que você só pode dar a um loop tanta autonomia quanto você pode verificar de forma barata e confiável, e nem um centímetro a mais. Verificação, não geração, é a verdadeira restrição de uma fábrica.
Como a capacidade de geração ilimitada está em tensão perpétua com o recurso finito e não escalável da atenção humana, o problema central é a lacuna entre geração barata e revisão limitada. Olhe para o funil: enquanto o gargalo que representa a verificação não se alargar, ele vai acumular. Como Dex aponta, o volume sozinho não é o problema: o que realmente sofremos é um excedente de PRs ruins. Quando você tem alto volume sem portões confiáveis, defeitos fabricados são inevitáveis. Isso é apenas contrapressão novamente: a autonomia não pode se expandir além do que pode ser verificado de forma barata e confiável.
O problema de segunda ordem é por que melhorar o modelo não deve fechar automaticamente a lacuna entre o que ele pode gerar e o que pode ser verificado. Treinar em sistemas bem arquitetados é uma proposta discutivelmente mais difícil do que passar em testes simples: lembre-se, as funções de custo que medem a excelência arquitetural não são medidas em segundos ou mesmo minutos, mas em meses e anos. Gradientes organizados são funcionalmente impossíveis de calcular, então um sistema que espera uma avaliação nítida e instantânea de decisões complexas de design não será treinado com bons exemplos.
A geração é uma boca larga; a verificação é o gargalo estreito. Acelerar a boca apenas aprofunda a pilha no gargalo.
Acendendo as luzes novamente
Uma fábrica iluminada é o mesmo pipeline com as luzes acesas onde o julgamento reside. Os agentes ainda fazem a maior parte da construção, mas um humano lê o que sai antes de ser enviado, e as luzes permanecem acesas onde quer que uma decisão errada seja cara.
A versão iluminada não coloca a revisão no final, mas move o ponto de julgamento humano para upstream, para o produto, o design e a arquitetura antes que um agente inicie um loop.
Uma ótima coisa sobre essa hora inicial é que ela leva a menos horas de implementação. Ela transforma uma longa e frustrante revisão de código em uma leitura rápida de um plano de duzentas linhas. Você revisa uma decisão antes que ela seja construída, então depois você não está perseguindo duas mil linhas de código gerado para descobrir qual foi a decisão. Algumas decisões são caras e duradouras o suficiente para que você queira uma pessoa envolvida desde o início, antes que o custo se acumule. Claro, ainda há momentos em que você olha para diffs, mesmo quando gastou tempo no início.
Você pode estar pensando que tudo isso parece sem glamour. Você está certo. A rede de segurança é feita de práticas arquiteturais perfeitamente comuns que sempre conhecemos e na maioria das vezes ignoramos: bons tipos e assinaturas de métodos para que erros sejam pegos pelo compilador em vez de em produção; seams de teste onde podemos fixar o comportamento e tornar a mudança observável; organizar o código para que o próximo leitor, humano ou modelo, saiba onde encontrar o que lhe interessa; manter as pilhas de chamadas curtas e legíveis; manter os limites dos componentes bem definidos para que uma mudança não tenha um enorme raio de explosão; e injeção de dependência para que possamos trocar uma peça por outra. Nada disso é novo. Sempre dissemos que nos importamos com boa arquitetura. Mas agora que estamos usando agentes de codificação automatizados, essa arquitetura está finalmente fazendo um segundo trabalho como uma rede de segurança barata e difícil de falsificar contra os erros que o agente cometerá.
Essa rede de segurança tem que viver fora do modelo, porque o modelo não a fornecerá. Os agentes de codificação que parecem mais capazes, entre eles Claude Code e Codex, são treinados por reforço contra seu próprio harness e ferramentas: fluentes com todas as ferramentas e expressões do ofício, mas não com coisas como maintainabilidade de longo prazo. A arquitetura deliberada sobre a qual sempre falamos é a ferramenta que captura essa dívida, e o investimento que fazemos nela é a forma como compramos de volta nossa autonomia.
Combine isso com uma infraestrutura segura, e existem alguns loops apertados e de baixo risco que você pode executar sem supervisão. Horthy descreveu um em uma postagem recente: um cron do GitHub Actions noturno que corrige exatamente um anti-padrão, uma violação de lint ou uma prop desnecessariamente opcional, faz commit e abre um pequeno pull request, tudo sozinho, para que a equipe acorde com um código-fonte ligeiramente melhor e uma diff curta o suficiente para ser lida. Mas para loops com apostas altas o suficiente, você não quer correr o risco de acordar com um sistema de autenticação quebrado, um mecanismo de faturamento ou um contrato de API pública. Mantenha as luzes acesas lá, e confie que uma pessoa com julgamento e um conhecimento de trabalho real do sistema pegará o erro.
O que faz um loop merecer o escuro
Esta regra se aplica quer você chame de contrapressão, verificação ou o interruptor da luz.
Um loop pode ganhar o status de totalmente automatizado somente se a verificação for barata, executada em alta frequência e depender de algo que não pode ser facilmente enganado. Oráculos verde-ou-vermelho, portões de tipo, testes de propriedade e um agente de revisão acoplado a uma rubrica real se encaixam. Você também precisa que o oráculo responda imediatamente e não mude com o tempo. Quando "pronto" pode ser comprovado não apenas por você, mas por uma máquina, você alcançou a automação.
Loops curtos são mais fáceis de verificar do que longos. A regra prática de Dex: um agente se mantém por três a dez passos, e depois começa a perder o fio da meada após vinte. A razão é o acúmulo de contexto: quanto mais o agente carrega, mais provável é que ele se desvie. Quando um loop é curto, verificá-lo é barato. Loops extensos escondem erros nos cantos, o que é outra forma de dizer que eles nunca mereceram o status de "lights-out".
Manter as luzes acesas é o caso oposto. Um loop precisa ser revisado se uma resposta errada for cara e apenas uma pessoa puder pegá-la. Bugs sutis de produção que não podem ser pegos por testes, grandes raios de explosão e uma decisão que moldará o trabalho de um ano ou mais se qualificam. Nesses casos, sua atenção é o produto real, o custoso e essencial.
O perigo é esquecer de acionar cada interruptor e simplesmente colocar todos no mesmo modo. Tudo escuro, e você fica preso tendo que derrubar tudo quatro meses depois. Tudo iluminado, e ninguém consegue fazer as revisões a tempo, e você fica preso em um gargalo gigantesco. O trabalho difícil e especializado é decidir onde colocar cada interruptor.
Loops, grafos ou máquinas de estado?
Você deveria ler "State machines in 2 minutes" por @DavidKPiano
Quando você entrega uma tarefa a um agente, provavelmente vai construir um grafo em torno dela, quer você chame esse grafo de máquina de estado finito ou de um conjunto de chamadas de serviço condicionalmente vinculadas. É um enquadramento onde o software não está apenas seguindo algumas regras abstratas, mas um fluxo de trabalho estruturado: cada nó é uma etapa explícita, e cada aresta entre nós é uma condição explícita.
Isso parece muita estrutura, mas a maior parte já está presente em qualquer software, já que qualquer código pode ser expresso como um grafo de fluxo de controle. Então, a única novidade real é que um agente insistindo em autonomia está realmente apenas percorrendo um grafo particular, e sua liberdade é restrita ao interior de um nó. E aqui está a parte que as pessoas esquecem, que Dex escreveu há um ano: o software sempre teria essa estrutura. Há uma razão pela qual costumávamos desenhar programas como fluxogramas.
O movimento verdadeiramente novo foi tentar jogar o diagrama fora, apoiando-se em um loop onde o modelo escolhe o caminho, chamada de ferramenta por chamada de ferramenta, até se declarar pronto. Isso parecia libertação, até encontrar um código-fonte de dez anos, e a disciplina que todos estão redescobrindo agora, possuir seu fluxo de controle, é realmente apenas percorrer o grafo de volta ao redor do loop. Então, a questão de se devemos mudar de loops para grafos é quase uma admissão de que precisávamos do fluxograma o tempo todo.
Aqui está como fica na prática. Pegue um bug para corrigir. Como um loop puro, você se senta e pensa: descubra o que está errado, mude algum código, execute os testes, veja o que acontece, e se essa rodada não matar a execução, volte ao início e comece de novo. Toda a jornada é decidida enquanto você avança: qual problema você persegue, o código exato que você muda, quais testes você executa e em que ordem, se você executa testes ou não, e se você tenta novamente ou declara vitória.
Como um grafo, a primeira coisa que você faz é mapear o que deve acontecer. Reproduza o bug ou peça mais informações, encontre a causa, tente uma correção, execute os testes, e deixe uma execução com falha retornar para a correção enquanto uma execução bem-sucedida segue para a revisão, onde apenas uma aprovação chega a "pronto". O agente ainda é inteligente dentro de cada caixa; ele simplesmente não pode vagar pelos caminhos que você não sancionou. Santi explicou isso com um diagrama que torna a diferença óbvia.
O apelo real desse grafo, é claro, é que ele é a contrapressão desenhada como um diagrama. Você abre mão de parte da liberdade do agente e ganha em troca verificações obrigatórias e pontos de falha legíveis, de modo que quando uma execução morre, você pode apontar para o nó que a matou. É o mesmo instinto por trás da linha direta de Dex de que a maioria dos chamados agentes não são muito agentivos, "código principalmente determinístico, com etapas de LLM salpicadas nos pontos certos". E isso não é apenas um artefato de como as pessoas estão construindo as coisas agora: você pode ver o padrão no LangGraph e nos LlamaIndex Workflows, no fluxo de trabalho híbrido-grafo-sobre-agentes de Jerry Liu com um loop externo que cresce partes do grafo à medida que é executado, e no lembrete de David Khourshid de que isso é realmente apenas máquinas de estado e o modelo de ator aparecendo em roupas novas.
Um esclarecimento, porque o termo é terrivelmente sobrecarregado: quando continuo chamando isso de grafo, não quero dizer um grafo de conhecimento. Quero dizer um grafo direcionado predefinido de como o trabalho deve fluir, arestas condicionais e tudo, dando ao loop uma forma que você pode realmente confiar.
Onde o humano realmente se encaixa
Observe que a pessoa nunca saiu da fábrica. Ela se moveu.
Acredito que os engenheiros precisam cada vez mais possuir o loop externo. Os agentes podem investigar um bug, escrever o diagnóstico, implementar uma correção, executar os testes e escrever um relatório. Essa é a execução do loop interno, e eles podem fazer isso com a mesma eficiência de qualquer um. Mas esse nunca foi o trabalho. As partes que você possui são o que eu chamaria de loop externo: decidir se é a maneira certa de abordar o problema, verificar se o diagnóstico e a implementação são sólidos, aprovar a mudança e arcar com as consequências de estar errado. A fronteira entre os dois loops é a evidência: as diffs, os testes, os logs e uma breve explicação que os conecta. Tipos, seams e rubricas tornam possível supervisionar tudo isso sem fazer muito trabalho para cada mudança.
É útil colocar desta forma: você não está mais na linha de produção escrevendo mudanças; você está no final da linha de produção, projetando-a e guardando o portão. Há muito que você pode fazer para melhorar o modelo e tornar o harness mais capaz, mas observei que identificar problemas que são caros a longo prazo não é tipicamente algo que você pode automatizar. A coisa central que ainda é o trabalho é exercer o julgamento humano melhor do que qualquer fluxo de papel e poder computacional.
Robôs funcionam bem no escuro, mas humanos precisam ver o que estão fazendo. Se tudo no chão de fábrica estiver escuro, e você não puder ver nada, e não conseguir nem encontrar o interruptor da luz, é aí que está o perigo.
Pangram pontuou este artigo como 100% escrito por humanos.
