- Fábricas de software operam em larga escala envolvendo em um harness loops que repetem coleta de contexto, ação e verificação, e se dividem entre fábricas iluminadas, onde humanos fazem o julgamento, e fábricas escuras, onde até a revisão de código fica a cargo das máquinas
- Geração de código, testes e scans escalam quase sem custo, mas a revisão e o julgamento humanos são difíceis de escalar, então a velocidade de verificar resultados de forma barata e confiável, mais do que o volume gerado, vira o gargalo
- Se as pessoas não leem o código, acumula-se uma dívida de compreensão (comprehension debt) entre o tamanho do código e o entendimento humano, e mesmo que os testes continuem passando, problemas de manutenção podem aparecer mais tarde em sistemas complexos operados por longos períodos
- A automação completa deve ser permitida apenas para loops curtos com critérios de decisão imediatos, estáveis ao longo do tempo e difíceis de manipular, e a revisão humana deve ser mantida em tarefas como autenticação, pagamentos e APIs públicas, onde o custo e o alcance de decisões erradas são grandes
- O papel do engenheiro muda de escrever diretamente mudanças individuais para projetar e proteger o loop externo, verificando as evidências de diagnóstico, implementação e testes feitos pelos agentes, e assumindo responsabilidade pela aprovação e pelos resultados
Do loop à fábrica de software
- A ideia de transformar software em um processo de produção repetível e mensurável remonta a Bob Bemer e ao texto “The economics of program production”, publicado em 1968
- Como não era fácil produzir ideias em série como peças de automóvel, essas tentativas em geral ficaram aquém das expectativas ao longo da última metade de século
- As mudanças dos últimos 2 anos foram grandes o bastante para justificar uma reavaliação da antiga visão de fábrica de software, mas armadilhas do passado podem ser embaladas como novas oportunidades
- O sistema inteiro é composto por três camadas: loop, harness e fábrica
- O loop é a unidade mínima de trabalho em que um agente coleta contexto, age, verifica o resultado e repete até cumprir a condição de encerramento
- A engenharia de loops é uma forma de projetar pequenos sistemas que fornecem prompts ao agente, em vez de depender de humanos digitando prompts toda vez
- O harness inclui o sandbox em que o loop roda, as ferramentas disponíveis, a memória mantida entre execuções e os gates que decidem se algo foi concluído
- Sem um harness, o modelo pode repetir indefinidamente, então é o harness que torna o loop útil e seguro
- A fábrica de software é uma estrutura que recebe itens de uma fila de trabalho, executa vários loops baseados em harness em paralelo e os envia para produção após passarem por gates de revisão
- É mais parecida com um organograma composto de loops do que com um único agente maior
- A unidade de trabalho do engenheiro também passa de mudanças individuais de código para loops, harnesses e o fluxo entre loops
Fluxo de trabalho e gargalos da fábrica
- Sinais vindos da visão da liderança de engenharia, da intenção dos engenheiros, de incidentes e de solicitações de usuários entram em uma única fila de trabalho
- O harness seleciona itens, cria mudanças, e CI, testes, análise estática e vários scans inspecionam essas mudanças em paralelo
- Se o gate de revisão aprovar, a mudança é implantada, e os dados de monitoramento de produção voltam como sinais que disparam novo trabalho
- Geração, testes e scans podem escalar a um custo desprezível, mas o julgamento humano no gate de revisão é difícil de escalar
- A possibilidade de aumentar a velocidade de desenvolvimento e a frequência de deploy depende de como esse gargalo de julgamento é tratado
A fábrica escura e a dívida de compreensão
- Na manufatura, uma fábrica escura é uma instalação operada com as luzes apagadas porque as máquinas não precisam de iluminação
- A FANUC opera esse tipo de fábrica desde 2001, e a Xiaomi também abriu uma fábrica escura altamente automatizada em 2024
- Numa fábrica de software escura, humanos não leem o código, e as mudanças são implantadas apenas com base nas verificações realizadas pela máquina que produziu o código
- Aqui, a escuridão não indica um clima negativo, mas sim que os humanos desapareceram do processo de escrever, revisar e implantar diffs
- Remover a revisão humana faz parecer que as interrupções sumiram e que a vazão vertical da equipe aumentou drasticamente
- Mas custos ocultos tornam mais difícil sustentar esse fluxo de trabalho por longos períodos do que parece à primeira vista
- Orquestração, prototipagem baseada em sandbox e chamadas de ferramentas continuarão ficando mais poderosas, mas só o harness não basta para manter a qualidade de um codebase no longo prazo
- Dívida de compreensão é a diferença entre a quantidade de código existente e a quantidade de código que humanos realmente entendem
- Fábricas escuras acumulam dívida de compreensão rapidamente mesmo enquanto os testes continuam passando
- Diferentemente de mudanças imediatas em pequenas áreas do código ou de projetos de fim de semana, sistemas legados complexos desenvolvidos por mais de 10 anos precisam continuar sendo mantidos em ritmo profissional
- Após operar um projeto automatizado por 3 a 6 meses, pode-se ficar sobrecarregado por código que ninguém leu
- Quando Dex Horthy operou por cerca de 4 meses uma fábrica totalmente automatizada em que humanos não viam o código gerado, encontrar a causa dos problemas exigiu uma depuração manual exaustiva
- Quanto mais se maximiza o uso de tokens, mais silenciosamente diminui o grau de compreensão humana do sistema
- A falha pode chegar tarde e silenciosamente, em vez de aparecer como um colapso súbito do sistema inteiro que antes passava nos testes
Por que a verificação vira a restrição, e não a geração
- Back pressure é o princípio de dar autonomia ao loop apenas até o ponto em que se consegue verificar de forma barata e confiável
- O problema central é a diferença entre uma capacidade de geração quase ilimitada e a atenção humana finita
- Se a faixa de verificação não se ampliar, as mudanças se acumulam; se só se aumenta o volume sem gates confiáveis, surgem PRs de baixa qualidade e defeitos fabricados
- Melhorias no desempenho dos modelos não reduzem automaticamente a distância entre geração e verificação
- O valor de uma boa arquitetura aparece ao longo de meses e anos, não em segundos ou minutos
- É difícil calcular uma função de custo limpa ou um sinal imediato de avaliação para excelência arquitetural, e também é difícil treinar boas decisões de design complexo como exemplos positivos
Como acender as luzes novamente
- Mesmo numa fábrica iluminada, os agentes fazem a maior parte da implementação, mas as luzes ficam acesas nos pontos em que o custo de um julgamento errado é alto, e humanos leem o resultado antes do deploy
- O julgamento humano não deve ficar preso apenas ao code review final; ele precisa ser deslocado para as etapas de produto, design e arquitetura antes de o agente iniciar o loop
- Revisar por 1 hora um plano de 200 linhas antes reduz reviews longas em que se vasculham 2.000 linhas de código gerado depois da implementação para descobrir decisões de design
- Quanto maior o custo e a duração de uma decisão, mais os humanos devem participar antes da implementação; mesmo com revisão prévia, o diff pode ser conferido diretamente quando necessário
- A rede de segurança não é uma técnica nova, mas um conjunto de práticas arquiteturais familiares
- Bons tipos e assinaturas de métodos capturam erros no compilador em vez de em produção
- Seams de teste fixam o comportamento e permitem observar mudanças
- O código deve ser organizado para que tanto humanos quanto modelos encontrem facilmente o que precisam
- A call stack deve permanecer curta e legível
- Limites de componentes devem ser claros para restringir o alcance do impacto de mudanças
- Injeção de dependência deve permitir substituir componentes
- Essa arquitetura cumpre um segundo papel: impedir erros de agentes de coding automático de forma barata e difícil de enganar
- Agentes como Claude Code e Codex recebem reinforcement learning para seu próprio harness e uso de ferramentas, mas não oferecem necessariamente manutenibilidade de longo prazo
- A rede de segurança precisa existir fora do modelo, e investir em arquitetura é uma forma de obter mais autonomia com segurança
- Combinados com infraestrutura segura, alguns loops curtos e de baixo risco podem rodar sem supervisão humana
- Por exemplo, um cron noturno do GitHub Actions pode corrigir exatamente um antipadrão, uma violação de lint ou uma prop opcional desnecessária, fazer um commit e abrir um único pequeno PR
- Alvos com alto custo de falha, como sistemas de autenticação, motores de pagamento e contratos de APIs públicas, precisam ser revisados por humanos com conhecimento do sistema e capacidade de julgamento
Loops que se qualificam para automação
- Para que um loop seja totalmente automatizado, as verificações devem rodar de forma barata e frequente e depender de critérios difíceis de enganar
- Isso inclui juízes que retornam claramente verdadeiro ou falso, type gates, testes baseados em propriedades e agentes de revisão combinados com rubricas reais de avaliação
- O julgamento deve sair imediatamente e não pode sofrer drift ao longo do tempo
- A automação é possível quando o estado de conclusão pode ser provado pela máquina, e não apenas por humanos
- Loops curtos são mais fáceis de verificar do que loops longos
- Segundo a regra prática de Dex, agentes funcionam bem em 3 a 10 etapas, mas começam a perder o fio depois de passar de 20 etapas
- À medida que o contexto se acumula, aumenta a chance de o agente sair do caminho, e loops longos escondem erros nos cantos
- Se o custo de uma resposta errada for alto e só humanos puderem perceber isso, é preciso acender as luzes
- Isso vale para bugs sutis de produção que testes não capturam, impactos amplos e decisões que determinam mais de 1 ano de trabalho
- Nesses casos, a atenção humana é o produto real e um recurso caro, mas indispensável
- Configurar todos os loops no mesmo modo faz os dois lados falharem
- Operar tudo no escuro pode levar à necessidade de desmontar o sistema meses depois
- Operar tudo iluminado transforma a revisão em um gargalo gigantesco
- A habilidade central é decidir em que ponto acender as luzes em cada loop
O grafo e a máquina de estados que envolvem o loop
- O trabalho dos agentes, seja chamado de máquina de estados finitos ou de chamadas condicionais de serviços, muito provavelmente acaba sendo composto por um grafo direcionado
- Cada nó é uma etapa explícita, e as arestas entre nós são condições explícitas
- Todo código pode ser representado como um grafo de fluxo de controle, então a estrutura em si não é nova
- A autonomia do agente fica restrita ao interior de cada nó, e não ao grafo inteiro
- A tentativa nova foi eliminar o fluxograma e deixar o modelo escolher o caminho a cada chamada de ferramenta até declarar por conta própria que terminou
- Depois do choque com codebases antigos, o movimento de retomar o controle do fluxo equivale a restaurar os grafos tradicionais ao redor do loop
- O trabalho de correção de bugs evolui de forma diferente num loop puro e num grafo
- Num loop puro, investigar o problema, alterar o código, escolher e executar testes, decidir tentativas e conclusão são coisas determinadas ao longo da execução
- Num grafo, reproduzir o bug ou pedir mais informações, identificar a causa, corrigir, testar e revisar são caminhos definidos previamente
- Se o teste falha, volta-se à etapa de correção; se passa, vai-se para revisão; só há conclusão em caso de aprovação
- O agente age com inteligência dentro de cada nó, mas não pode desviar por caminhos não permitidos
- O grafo é uma forma de visualizar o back pressure
- Em troca de abrir mão de parte da liberdade do agente, obtêm-se verificações obrigatórias e pontos de falha legíveis
- Se a execução falha, é possível identificar qual nó a interrompeu
- Como na abordagem dos 12-factor agents, muitos sistemas de agentes se aproximam de “código majoritariamente determinístico com etapas de LLM misturadas nos pontos apropriados”
- O mesmo padrão aparece em LangGraph, LlamaIndex Workflows, nos grafos híbridos de fluxo de trabalho sobre agentes de Jerry Liu, e nas máquinas de estados e no modelo de atores conectados por David Khourshid
- Aqui, grafo não significa grafo de conhecimento, e sim um grafo direcionado com fluxo de trabalho e arestas condicionais definidos previamente
Humanos possuem o loop externo
- Em vez de desaparecer da fábrica, humanos saem da linha de execução e passam para o loop externo
- O agente executa o loop interno de investigar bugs, escrever diagnósticos, implementar correções, rodar testes e relatar resultados
- O engenheiro julga se o problema está sendo resolvido da forma correta, valida o diagnóstico e a implementação, aprova a mudança e responde por resultados errados
- Na fronteira entre o loop interno e o loop externo ficam as evidências, como diffs, testes, logs e breves explicações que os conectam
- Com tipos, seams de teste e rubricas de avaliação, é possível supervisionar execuções do agente sem fazer muito trabalho manual a cada mudança
- A posição do engenheiro sai do posto de escrever mudanças diretamente na linha de produção e vai para o de projetar a linha e proteger os gates
- Modelos e harnesses podem melhorar, mas automatizar o julgamento humano capaz de identificar problemas caros no longo prazo continua difícil
- O cenário mais perigoso é transformar todo o espaço de trabalho em escuridão, a ponto de ninguém conseguir ver o que está acontecendo ou sequer encontrar o interruptor da luz
Ainda não há comentários.