Por que as fábricas de software falham

ou: o arnês não é suficiente

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

acho que estamos fazendo loops agora

Estamos todos correndo para colocar codificação com IA em produção. Já se falou muito sobre engenharia de loops, e a sabedoria predominante é que devemos escrever mais loops.

StrongDM escreveu sobre sua fábrica de software sem supervisão, 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, Symphony.

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

é... tá indo

Nosso amigo Mario se levantou no AI Engineer Europe e nos implorou para desacelerar – porque empresas que não têm motivo para ter interrupções devido a acidentes com agentes de codificação estão, bem… tendo interrupções devido a acidentes com agentes de codificação.

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

Não consegui encontrar dados/resultados conclusivos da StrongDM sobre como foi aquela fábrica escura. O relatório 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 bastante.
• Bugs por desenvolvedor aumentaram bastante.

Esse relatório é mais um sinal de correlação do que uma prova definitiva (sim, escolhi essa palavra de propósito, não me façam começar a falar sobre a prosa do Claude), e o objetivo 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á… hmm… 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á chegando lá, prometo que faz parte da progressão. Eu também pensava assim no verão passado.

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

• Engenharia de Contexto Avançada para Agentes de Codificação
• Sem Vibes Permitidos – Resolvendo Problemas Difíceis em Bases de Código Complexas
• Tudo o que Erramos sobre RPI

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

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

Tudo o que precisamos fazer é configurar mais linters e polvilhar 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 arnês 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 – tanto no lado RLVR quanto no lado dos benchmarks.

Neste post, vou abordar:

1. Fábricas de software datam de 1968, como 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 referenciar 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 coisa que vale destacar:

Um desenvolvedor fazendo vibe coding de um projeto paralelo que uma dúzia de pessoas vai executar, 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 maior parte dos conselhos em circulação é realmente um desses dois dizendo ao outro como viver.

Se você ama vibe coding, por favor, continue vibrando. Ainda faço vibe coding de muitas coisas, mas 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 disso é 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 algo em Java de dez anos, mas no ritmo que podemos entregar agora, parece que uma base de código construída por agente começa a ter dificuldades após talvez três a seis meses – você começa a desacelerar, e a forma como aborda adicionar coisas novas tem que mudar.

Uma breve história da fábrica de software

Construí e estudei fábricas de software durante toda a minha carreira, 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 definir nossa "fábrica de software" por volta de 2022, bem antes da IA. Em uma fábrica de software típica:

• Pessoas decidem o que construir – engenheiros, PMs, liderança guiando a visão
• Isso vai para um rastreador – Linear, Jira, seja lá o que for: 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 está nisso
• Pull request – verificações automatizadas, um humano revisa o código, talvez alguém baixe 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 acordar um engenheiro às 3h da manhã quando algo quebra
• Usuários reclamam – pedem coisas, encontram bugs, solicitam funcionalidades → de volta para a equipe adicionar ao rastreador

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

Alinhamento pré-carregado

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 codificação agentica para o cenário.

A fábrica de software agentica

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 agentica 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 arnês, um sandbox, um modelo, uso de computador, etc. Não vou entrar em detalhes sobre isso 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 agentica, para pegar estilo, bugs, segurança.
• Testes de regressão agenticos, para cutucá-lo de fora com navegadores e uso de computador e talvez enviar um vídeo bonitinho quando terminar.

A revisão está 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 acordar alguém às 3h, eles acordam com um PR que talvez já resolva o problema.

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

Nesse ponto, o trabalho é duas perguntas: quanto você pode colocar na fila, e quão rápido você pode revisar e testar o que sai?

O que nos leva à fábrica de software sem supervisão.

A fábrica de software sem supervisão

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? Não, obrigado.

Então, você a descarta 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 lançamento
• Invista na coleta de sinais de feedback dos usuários

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

Isso vai dar certo (não vai)

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

Vamos entrar em por que as fábricas de software falham.

Nós tentamos isso

Em julho de 2025, fomos totalmente sem supervisão. Apenas leia as especificações e os tickets, agentes de fundo para todas as coisas pequenas/médias, tudo.

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

• Você faz uma pesquisa profunda e consciente do 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 cavoucar a base de código que você parou de ler há três meses, tentando descobrir o que está quebrado.

E enquanto isso:

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

Na primeira vez que isso aconteceu conosco, eu deixei pra lá. Mesmo tendo passado a melhor parte de duas semanas cavoucando spaghetti 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 no cursor) construindo todos os padrões manualmente.

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

O que quero chegar é: 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 boa quantidade 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 com 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 – de algumas maneiras. Em outras, estão mais ou menos os mesmos.

• Resolver problemas isolados, 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 tarde.)

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 – você 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 arnês

Claude Code passou 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 anteriores ao Claude Code, todos com ótima engenharia de contexto embutida, 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, Claude Code foi lançado e cresceu verticalmente 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 treinou o modelo com RL dentro do arnês – a primeira vez que um laboratório treinou um modelo contra as ferramentas exatas que iriam enviar com ele. E ele ficou realmente, realmente bom em chamar essas ferramentas em um loop agentico.

Uma coisa é mexer 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 arnês, mas não possui os pesos e não pode treinar o modelo com RL dentro dele, você sempre estará em desvantagem para uma equipe que possui ambos.

RL de Agente de Codificação em 60 segundos

Fiz muitas pesquisas sobre este tópico e preparei 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 traços de agente de codificação para resolver um problema (por exemplo, corrigir meus testes)
2. pontuar os traços com base em alguns critérios (verificador)
3. atualizar os pesos do modelo para tornar os traços bons mais prováveis e os 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?
• PASS_TO_PASS – você fez isso sem quebrar mais nada?

Aqui está uma 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 cai:

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

Durante a avaliação, o modelo

1. começa de um commit base – o repositório verificado no momento exato antes dessa correção ser aplicada
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. Jogamos fora quaisquer edições que ele fez nos arquivos de teste (já 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

Observação – Benchmarks não são verificadores – na verdade, eles devem 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 traço 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ê obtém try catches em torno de tudo:

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

Executar os testes fornece uma aprovação ou reprovação limpa 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 pode 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.

Os testes fornecem 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 podem avaliar. E eu sei, eu sei, RL != Benchmarks, mas se isso fosse resolvido no 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 são 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 "clone 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 de código aberto que nunca foram realmente construídas no mundo real, então, por construção, elas 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 uma jogada inteligente que avalia qualidade deterministicamente – penaliza o modelo por escrever testes que não falham no código anterior ao patch (se você nunca ouviu falar sobre 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 conseguisse distinguir de forma confiável código bom de código ruim, ele poderia ter escrito a versão boa desde o início. O RL precisa de um oráculo rápido e confiável, e ainda não temos um para manutenibilidade.

Se um modelo conseguisse distinguir de forma confiável código bom de código ruim, ele poderia ter escrito a versão boa desde o início, mas a manutenibilidade 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 nível mínimo, pegando os erros mais bobos.

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

Então, eu ainda não apostaria minha base de código em nenhum deles. Mas são as primeiras avaliações que vi que tentam pontuar a manutenibilidade em vez de parar em passar/reprovar.

Parêntese Talvez um modelo futuro simplesmente entenda isso e possamos parar. Se você quiser arriscar prompts até o GPT-7 ser lançado e descobrir, fique à vontade — mas que se dane a lição amarga, temos problemas para resolver agora, e vou explicar como fazemos isso.

Acendendo as luzes novamente

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