Por que as Fábricas de Software Falham

ou: o arreio não é suficiente

Atualização - a versão em palestra deste post está no youtube: https://www.youtube.com/watch?v=Ib5GBkD555M

acho que agora é vez dos loops

Estamos todos correndo para colocar codificação com IA em produção. Muito já se falou sobre engenharia de loops, e a sabedoria predominante é que provavelmente deveríamos escrever mais loops.

A StrongDM escreveu sobre sua fábrica de software sem intervenção humana, onde nenhum humano lê código e nenhum humano escreve código.

A narrativa é mais ou menos assim:

1. Você é o gargalo.
2. Os modelos são bons o suficiente.
3. Código é gratuito.
4. Apenas entregue mais coisas.

Ryan Lopopolo da OpenAI escreveu sobre isso em fevereiro e fez uma palestra em abril sobre a fábrica de software da OpenAI, a Symphony.

Todas essas pessoas são muito inteligentes e tenho um enorme respeito por elas. Mas a interpretação mais cínica aqui seria chamar isso de mais uma desculpa para injetar mais dinheiro de VC no canhão de porcaria.

está... funcionando

Nosso amigo Mario subiu ao palco no AI Engineer Europe e implorou para que desacelerássemos -- porque empresas que não têm motivo algum para ter indisponibilidades devido a acidentes com agentes de codificação estão, bem... tendo indisponibilidades devido a acidentes com agentes de codificação.

Como Matt Pocock disse, as bases de código estão se desfazendo mais rápido do que nunca.

Não consegui encontrar nenhum dado/descoberta definitiva da StrongDM sobre como foi aquela fábrica escura. O weather-report tem algumas atualizações esparsas entre fevereiro e junho deste ano. edição - há alguma conversa com a equipe no hacker news em 23 de julho - parece que podemos ter uma atualização mais formal em breve!

O pessoal da Faros AI publicou um relatório: desde que todos nós2 adotamos essas ferramentas de codificação com IA em janeiro e fevereiro, a qualidade da revisão de pull requests caiu drasticamente.

• Mais comentários, comentários mais longos e toneladas de PRs sendo mescladas sem nenhuma revisão.
• Incidentes aumentaram muito.
• Bugs por desenvolvedor aumentaram muito.

Este relatório é mais um sinal de correlação do que uma prova cabal (sim, escolhi essa palavra de propósito, não me façam começar a falar da prosa do claude), e o objetivo principal deste post é ter cuidado com dados de porcaria, mas parece direcionalmente válido com base no que vi.

"Você está segurando errado" (não está)

Muitas pessoas vão te dizer que isso é um problema de habilidade -- que se você não está obtendo bons resultados, a culpa é sua.

Mas, independentemente de como você está escolhendo... hum... segurando, garanto que estão te dizendo que, se o token-maxxing não está funcionando para você, é um problema de habilidade. Você só precisa gastar mais tokens. Pare de ler o código. E se você está começando agora, prometo que faz parte da progressão. Eu também pensava assim no verão passado.

Infelizmente para o meu ego, algumas coisas idiotas que decidi dizer sobre "como segurar melhor" foram gravadas e agora têm cerca de um milhão de visualizações acumuladas no YouTube. Não estou tentando me gabar aqui, compartilho isso apenas para estabelecer que venho me aprofundando nas melhores formas de usar agentes de codificação há muito tempo, e descobri algumas coisas que muitos outros consideraram genuinamente úteis.

• Advanced Context Engineering for Coding Agents
• No Vibes Allowed -- Resolvendo Problemas Difíceis em Bases de Código Complexas
• Everything We Got Wrong About RPI

De qualquer forma, A promessa de toda essa tagarelice online de "apenas token mais forte" que fomos forçados a suportar é, resumidamente: com engenharia de arreio suficiente, podemos ter o melhor dos dois mundos:

• 10 a 100x mais rápido,
• alta qualidade, e
• ninguém nunca mais precisa fazer aquela coisa que todos odiamos chamada revisão de código

Tudo o que precisamos fazer é configurar mais linters e borrifar algumas palavras mágicas como "revisão adversarial" em bots de revisão de PR suficientes, e nosso software felizmente se construirá sozinho, sem incidentes.

Isso não é um problema de habilidade

O que vou tentar te convencer é que nenhuma quantidade de engenharia de arreio ou loopsmaxxing pode resolver o que é, fundamentalmente, um problema de treinamento de modelo.

Para lidar com isso, tive que mergulhar em como os modelos de codificação são realmente treinados e avaliados -- com relação tanto ao RLVR quanto ao lado dos benchmarks.

Neste post, vou abordar:

1. Fábricas de software datam de 1968, como elas evoluíram e como a IA as mudou
2. Por que os modelos podem gerar montanhas de porcaria apesar de arrasarem nos benchmarks (mesmo os novos benchmarks de "fronteira")
3. Apesar disso, você pode se mover bem rápido sem incendiar sua base de código

Vou tentar cortar o hype de cada plugin de habilidades que surge diariamente e a pandemia de conselhos de ai-psicose-tokenmaxxing, e falar em termos gerais sobre os tipos de coisas que funcionam sem fazer referência a nenhuma habilidade ou estrutura específica.

Versão em Vídeo: este post é baseado (e expande) minha palestra principal no AI Engineer World's Fair 2026.

Agradecimentos a @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, e @jeffreyhuber pelo feedback neste post.

Um parêntese: isso não tem nada a ver com vibe coding

Addy Osmani desembaraçou essa questão que vale a pena destacar:

Um desenvolvedor fazendo vibe coding de um projeto paralelo que uma dúzia de pessoas usará, e uma equipe mantendo um sistema empresarial de dez anos vivo por mais um trimestre, compartilham quase nenhuma restrição que valha a pena nomear, e a maioria dos conselhos em circulação é na verdade um desses dois tipos de pessoa dizendo ao outro como viver.

Se você ama vibe coding, por favor, continue vibrando. Eu ainda faço vibe coding de muitas coisas, só que também mantenho muito software em produção (e, através da HumanLayer, ajudo milhares de outros engenheiros a fazer o mesmo), então o resto deste post é voltado para pessoas resolvendo problemas difíceis em bases de código complexas.

Ouço muito a palavra brownfield para falar sobre essa divisão. Historicamente, isso significava alguma coisa em Java de dez anos atrás, mas no ritmo que podemos entregar agora, parece que uma base de código construída por agentes começa a ter dificuldades após talvez três a seis meses -- você começa a desacelerar, e a forma como aborda a adição de coisas novas precisa mudar.

Uma breve história da fábrica de software

Passei toda a minha carreira construindo e estudando fábricas de software, mas só aprendi isso recentemente: o termo remonta a uma conferência da OTAN em 1968 -- a mesma que nos deu "engenharia de software".

A única outra coisa que acho super interessante desde então é que o Departamento de Defesa dos EUA escreveu um PDF de 31 páginas sobre como o DoD precisa começar a usar jenkins melhor ou algo assim.

A fábrica de software de 2022

Vamos ancorar nossa definição de "fábrica de software" por volta de 2022, pouco antes da IA. Em uma fábrica de software típica:

• Pessoas decidem o que construir -- engenheiros, PMs, liderança conduzindo a visão
• Isso vai para um rastreador -- Linear, Jira, etc.: uma máquina de estados do que precisa ser feito
• Alguém pega um ticket e constrói -- provavelmente faz alguns testes manuais/automatizados enquanto isso
• Pull request -- verificações automatizadas, um humano revisa o código, talvez alguém faça o download para testar
• Algo errado? Volte para "alguém constrói a coisa"
• Envie para produção -- e isso entra em contato com os usuários
• Adicione monitoramento -- existe uma indústria inteira construída em torno de paginar um engenheiro às 3h da manhã quando algo quebra
• Usuários reclamam -- pedem coisas, encontram bugs, registram solicitações de recursos → de volta para a equipe adicionar ao rastreador

E assim por diante. Ainda nem chegamos à IA, e já existem vários loops nesta imagem.

Pré-carregando o alinhamento

Há uma coisa que as equipes descobriram décadas atrás: construir leva horas ou dias, e o mesmo vale para a revisão.

Então, pré-carregamos o trabalho -- planejamento, propostas de arquitetura, planejamento de sprint -- juntos, como equipe. Isso significa:

• menos retrabalho, porque nos alinhamos antes de alguém escrever código
• menos tempo revisando cada linha, se você já leu um PR longo, mas bem-feito, sabe como a revisão é rápida quando está perto da perfeição

Voltaremos a isso mais tarde - vamos ver o que acontece quando você traz a codificação agentiva para a imagem.

A fábrica de software agentiva

Agora, toda empresa e sua mãe --

• Ramp
• Stripe
• WorkOS
• Brex

passou a maior parte deste ano explicando como construiu uma fábrica de agentes que entrega cerca de 75% do seu código.

A fábrica agentiva se parece principalmente com a troca de "alguém constrói a coisa" → "um agente constrói a coisa" -- há algumas coisas aqui, como orquestração, um arreio, uma sandbox, um modelo, uso de computador, etc. Não vou me aprofundar nesses detalhes porque, francamente, estou cansado de ler sobre isso e tenho certeza de que você também está.

Quando o agente constrói a coisa:

• Construir cai de horas ou dias para minutos ou horas.
• A revisão ainda leva horas ou dias. Um humano ainda precisa ler o código e testar a alteração. Então, a revisão agora é o gargalo.

Então, você acelera a revisão também:

• Revisão de código agentiva, para detectar estilo, bugs, segurança.
• Testes de regressão agentivos, para cutucar de fora com navegadores e uso de computador e talvez te enviar um vídeo bonitinho quando terminar

A revisão é mais rápida agora, mas provavelmente ainda é o gargalo. Mas podemos fazer mais loops.

Em seguida, você pode rotear incidentes para a fábrica. Em vez de paginar alguém às 3h da manhã, eles acordam para um PR que talvez já resolva o problema.

Também podemos rotear o feedback do usuário para a fábrica. As pessoas pedem coisas, e elas são construídas.

Nesse ponto, o trabalho se resume a duas perguntas: quanto você consegue enfiar na fila, e quão rápido você consegue revisar e testar o que sai?

O que nos leva à fábrica de software sem intervenção humana.

A fábrica de software sem intervenção humana

Dan Shapiro cunhou este termo e Simon Willison escreveu sobre a implementação da StrongDM -- onde não lemos mais o código.

Você olha para sua linda fábrica de software. Ela está arruinada por aquela etapa irritante de revisão de código, e você diz: quer saber, aquela coisa de um humano ler cada alteração? Dispenso.

Então, você a elimina e coloca o esforço em outro lugar:

• Invista em testes e deixe o agente testar seu próprio trabalho
• Invista em sandboxes e orquestração
• Invista em revisão automatizada
• Invista em monitoramento
• Invista em rollout
• Invista na coleta de sinais de feedback dos usuários

E agora o trabalho realmente é apenas uma pergunta: quanta coisa podemos pedir para o agente construir? Quanto do oceano queremos ferver?

Isso vai dar super certo (não vai)

Vou propor algo potencialmente controverso: a fábrica sem intervenção humana não funciona.

Vamos ver por que as fábricas de software falham.

Nós tentamos isso

Em julho de 2025, ficamos totalmente sem intervenção humana. Apenas leia as especificações e os tickets, agentes em segundo plano para todas as coisas pequenas/médias, tudo isso.

Se você tentou isso seriamente por alguns meses, já sabe como termina. Você encontra pelo menos um problema complicado o suficiente que o agente não consegue resolver -- mesmo com seus prompts e fluxos de trabalho mais avançados.

• Você faz uma pesquisa profunda com consciência de contexto, reunindo todas as partes certas na zona inteligente para o modelo analisar
• Você faz o agente tentar reproduzir de 10 maneiras diferentes

Eventualmente, você tem que engolir o orgulho e ir escavar a base de código que parou de ler há três meses, tentando descobrir o que está quebrado.

E enquanto isso:

• Seu site estava offline.
• Seus usuários estavam irritados.
• E você, se é parecido comigo, estava miserável -- lendo todo o código porcaria que deixou entrar no seu sistema.

Na primeira vez que isso aconteceu conosco, eu ignorei. Mesmo tendo acabado de passar a maior parte de duas semanas escavando espaguete do claude, "o risco negativo valia a velocidade". Na ~terceira vez, em novembro, decidimos que seria mais fácil reescrever do zero, e meu cofundador passou duas semanas inteiras no VS Code (nem cursor) criando todos os padrões manualmente.

modelos degradam a qualidade da base de código ao longo do tempo

O que quero dizer é: os modelos têm uma deficiência. Eles não conseguem manter e melhorar a qualidade da base de código ao longo do tempo -- não sem uma quantidade razoável de direção humana.4

Quando digo mantenabilidade, quero dizer aquela coisa específica em que se torna realmente, realmente difícil mudar uma parte da base de código sem quebrar outra parte. Isso é a cirurgia de espingarda de Martin Fowler.

Não vou dizer muito mais sobre mantenabilidade. Existem vários livros que você pode ler sobre isso

• A Philosophy of Software Design de John Ousterhout
• Clean Code de Robert C. Martin
• Refactoring de Martin Fowler

Então, por que os modelos não conseguem fazer mantenabilidade de software?

"Mas certamente os modelos melhoraram desde então"

Neste ponto, você pode estar morrendo de vontade de dizer: mas Dex, certamente os modelos melhoraram muito desde julho

Melhoraram -- em alguns aspectos. Em outros, estão praticamente os mesmos.

• Resolver problemas pontuais, ou fazer vibe coding de um novo site de marketing? Sim. Muito melhor.
• Melhorar a qualidade da base de código ao longo do tempo? Não muito melhor, pelo que posso perceber.

Não posso provar isso. Você também não pode provar. Não existem bons benchmarks para a capacidade de um modelo de manter a qualidade da base de código. (Mais sobre para onde isso está indo mais adiante.)

NÃO EXISTEM BONS BENCHMARKS para a capacidade de um modelo de manter a qualidade da base de código

Mas se você trabalhou com agentes de codificação por um tempo -- e muitas pessoas estão postando exatamente sobre isso -- provavelmente já tem a sensação: eles tendem a piorar as coisas com o tempo e tornar a base de código mais difícil de trabalhar.

Então, para descobrir por que isso acontece, quero dar um zoom out para o primeiro grande agente de codificação.

Claude Code venceu por causa do Aprendizado por Reforço dentro do arreio

Claude Code foi de nada para ~$4B -- agora algo como ~$9B -- em receita em menos de um ano.

O que é um pouco louco, porque já existiam ótimos agentes CLI. aider, cline, codebuff -- todos antecederam o Claude Code, todos com uma engenharia de contexto genuinamente ótima incorporada, todos com o mesmo conjunto de ferramentas que você poderia atribuir ao claude code: ler, escrever, editar, grep, bash. Eu os usei. Eles eram bons. Mas também, o uso de ferramentas às vezes... falhava -- você o via se debater na mesma edição três vezes e abria seu editor novamente para fazer você mesmo.

O artigo SWE-Agent de 2024 descreve como pequenas mudanças na forma da ferramenta fazem diferenças notáveis, por exemplo, incluir números de linha nos resultados do ReadFile, ou mudar uma ferramenta Edit de localizar/substituir para edições por intervalo de linhas.

Então, o Claude Code foi lançado e cresceu verticalmente muito rapidamente. Você pode atribuir isso à distribuição, mas a explicação canonicamente aceita é que o claude code venceu porque era melhor, e que era melhor porque a Anthropic aplicou RL no modelo dentro do arreio -- a primeira vez que um laboratório treinou um modelo contra as ferramentas exatas com as quais iriam enviá-lo. E ele ficou realmente, realmente bom em chamar essas ferramentas em um loop agentivo.

Uma coisa é brincar com definições de ferramentas e evals até encontrar a forma que o modelo mais gosta -- já passei semanas fazendo isso para vários casos de uso. É um jogo diferente quando você possui os pesos e pode modificar o próprio modelo para ser melhor em um conjunto específico de ferramentas.

A equipe da OpenAI fez uma palestra em novembro que colocou isso muito bem: se você constrói um arreio, mas não possui os pesos e não pode aplicar RL no modelo dentro dele, você sempre estará em desvantagem para uma equipe que possui ambos.

RL de Agente de Codificação em 60 segundos

Pesquisei muito sobre este tópico e criei várias visualizações para tentar explicar as partes que importam, mas descobri que Calvin French-Owen (MTS na equipe codex, fundador da Segment) fez uma palestra no AI Council que fez um trabalho muito melhor e mais limpo, então vou apenas colocar esta animação aqui inspirada em seus slides:

Para tornar um modelo melhor em codificação, você vai:

1. gerar alguns traces de agente de codificação para resolver um problema (ex.: corrigir meus testes)
2. pontuar os traces com base em alguns critérios (verificador)
3. atualizar os pesos do modelo para tornar os traces bons mais prováveis e os traces ruins menos prováveis

E então você faz isso milhões de vezes ao longo de semanas ou meses.

A parte de "pontuação" dessas coisas pode tender a ser caprichosamente unidimensional, no entanto.

Não há penalidade para design ruim

Pegue o SWE-bench Multilingual. As tarefas são pequenas -- cerca de quinze minutos de trabalho cada -- extraídas de repositórios de código aberto como Redis, jq e Django. A recompensa é um ou zero com base em:

• FAIL_TO_PASS - você corrigiu o que foi solicitado a corrigir?
• PASS_TO_PASS - você fez isso sem quebrar mais nada?

Aqui está um exemplo real, fastlane__fastlane-19304, do fastlane -- um projeto Ruby. Sua ação zip pega dois parâmetros opcionais e chama .empty? neles imediatamente, então, no momento em que você deixa include e exclude de fora, ele quebra:

A correção humana que fechou este problema específico tem duas linhas (padrão nils para arrays vazios):

Durante a avaliação, o modelo

1. começa a partir de um commit base -- o repositório verificado no momento anterior àquela correção
2. o relatório de bug - neste caso, 'zip_command': método indefinido 'empty?' para nil:NilClass

O agente vai e escreve algum código com base no problema. Ele não vê o patch dourado ou o patch de teste que serve como avaliador:

Então:

1. Mantemos qualquer patch que ele produziu, depois
2. Descartamos qualquer edição que ele fez nos arquivos de teste (pegamos um modelo silenciosamente comentando o teste com falha ou inserindo um mock que torna o teste inútil)
3. Aplicamos o patch de teste do benchmark por cima, e
4. Executamos toda a suíte: os testes zip existentes (PASS_TO_PASS) mais o novo (FAIL_TO_PASS) para ver se ambos passam

Parêntese - Benchmarks não são verificadores - na verdade, eles precisam ser mantidos separados uns dos outros (não treine no teste, etc.) - quero dizer principalmente isso para transmitir a forma de "julgar a qualidade de um trace de agente de codificação" e suas limitações.

Como o modelo chegou a uma resposta correta não importa. Se os testes passarem, vencemos, mas não há penalidade por corroer a mantenabilidade da base de código.

não há penalidade por corroer a mantenabilidade da base de código

É assim que você acaba com try catches em tudo:

Verificar a qualidade é ordens de magnitude mais difícil do que "os testes passaram"

Executar os testes dá um resultado claro de aprovação ou reprovação em ~segundos. É por isso que o RL pode executar milhões de loops para otimizar cada geração de modelo.

Mas a função de custo de uma arquitetura ruim é medida em semanas, meses, talvez até anos. Acontece na primeira vez que alguém abre aquele arquivo para uma alteração de uma linha e percebe que não consegue fazê-la em uma linha -- alguém vibrou isso um pouco demais, e agora temos que fazer a mesma edição em onze lugares e esperar que nada quebre silenciosamente três arquivos adiante.

Testes dão feedback em segundos, mas a função de custo de uma arquitetura ruim é medida em semanas, meses, talvez até anos

Design ruim é a única coisa que os benchmarks de hoje não conseguem avaliar. E eu sei, eu sei, RL != Benchmarks, mas se isso fosse resolvido em RL, tenho certeza de que começaria a aparecer também em como nossos benchmarks são projetados.

De qualquer forma, eu pessoalmente não confio em nenhuma melhoria nos benchmarks de hoje como um indicador de que os modelos de repente se tornaram bons em não encher sua base de código de porcaria.

A fronteira está melhorando, lentamente

Claro, muitas pessoas inteligentes estão trabalhando nisso. Meu ponto não é que não pode ser feito, é que o hype está ultrapassando a disciplina.

Alguns esforços que acho que estão no caminho certo:

• SWE-Marathon (Abundant AI): tarefas de ~400 horas como "clonar todo o Excel, todos os recursos" -- com um canal de recompensa composto em vez de um único bit de aprovação/reprovação
• DeepSWE (Datacurve): tarefas grandes em repositórios OSS que nunca foram realmente construídos no mundo real, então, por construção, eles não podem já estar no conjunto de treinamento (resolve contaminação, mas não qualidade)
• Frontier Code (Cognition): tarefas de múltiplos PRs, e um movimento inteligente que avalia a qualidade deterministicamente -- penaliza o modelo por escrever testes que não falham no código pré-patch (se você nunca ouviu falar de teste de mutação, prepare-se para uma jornada divertida5). Ele também executa um modelo juiz sobre o diff verificando regras de qualidade de código.

Mas um modelo julgando qualidade só pode ir até certo ponto.

Na verdade, não é difícil imaginar que, se um modelo pudesse distinguir com confiança código bom de código ruim, ele talvez já tivesse escrito a versão boa desde o início. RL precisa de um oráculo rápido e confiável, e ainda não temos um para mantenabilidade.

Se um modelo conseguisse identificar de forma confiável código bom e ruim, ele provavelmente teria escrito a versão boa desde o início, mas mantenabilidade não tem um oráculo rápido, então não podemos recompensá-la durante o RL.

Claro, mais agentes de revisão e mais tokens ajudam — eles elevam o piso, pegando os erros mais bobos.

Mas eles não movem o teto, porque o teto é o que conseguimos ensinar ao modelo durante o RL, e bom design é algo que ainda não sabemos ensinar.

Então, eu ainda não apostaria meu código-fonte em nenhum desses. Mas são os primeiros evals que vi que ao menos tentam pontuar mantenabilidade, em vez de parar no passa/não passa.

Parêntese Talvez um modelo futuro simplesmente entenda isso e possamos parar por aqui. Se você quiser sair usando prompts no estilo YOLO até o GPT-7 ser lançado e ver no que dá, fique à vontade — mas que a lição amarga seja dita, temos problemas para resolver agora, e vou mostrar como fazemos isso.

Acendendo as luzes de novo

Hoje aprendi que os Artigos do Twitter têm um "limite de mídia", então o restante disso vai para uma postagem da parte II — fique ligado.