Boris Cherny, criador do Claude Code, foi ao Startup School da Y Combinator em 2026 com uma história que parece erro de lógica: a equipe deletou 80% do system prompt e o produto ficou melhor. Não mais simples de manter. Não mais barato de rodar. Melhor em qualidade de output.
Na mesma época, Robert C. Martin — o Uncle Bob do Clean Code — foi ao live de Matt Pocock e declarou que parou de ler o código que seus agentes produzem. Setenta e três anos de carreira. Começou a programar nos anos 60. E hoje sua estratégia declarada é não revisar a implementação gerada.
Os dois movimentos parecem irresponsabilidade. São, na prática, o oposto.
O prompt que encolheu ficou mais denso
Cherny explicou a lógica da deleção: grande parte do system prompt do Claude Code havia se acumulado como correção de comportamentos inadequados de modelos mais fracos. Cada comportamento inesperado virava uma instrução nova. Com o Opus 5, essas instruções viraram ruído. "A lot of the stuff in the system prompt was correcting for behaviors that the model should have known" — o modelo simplesmente passou a fazer certo sem precisar ser lembrado.
Faz sentido olhando para os números: o Opus 5 saltou de patamares de single digits para 30,2% no ARC-AGI-3, benchmark que mede raciocínio em contextos inéditos. O modelo anterior ao qual Boris se referia como referência tinha 7,8% no mesmo benchmark. Não é uma melhoria incremental.
O que sobrou nos 20% remanescentes do prompt: restrições de segurança, permissões e algumas diretrizes de comportamento essenciais. Nada que compensava limitação de modelo. Só o que define o que o sistema pode e não pode cruzar, independente de quão capaz o modelo seja.
A prática que Cherny recomenda é o que chama de ablações regulares: a cada lançamento de modelo, deletar e reconstruir o prompt do zero. Não acumular. Subtrair. O que o modelo consegue inferir não precisa ser dito, e deixá-lo no prompt faz mal ao resultado.
Uncle Bob não lê o código. De propósito.
Martin, no live com Pocock, foi direto: "My current strategy is to not read any of the code written by my agents." A troca que ele faz é deliberada. Em vez de revisar implementação, concentra energia em dois lugares: especificar o comportamento esperado e construir o que chama de "test gauntlet", um conjunto de testes de aceitação que faz o trabalho que a revisão de código fazia antes.
O que verifica, então, que o agente fez o que devia? Os testes que ele mesmo escreveu antes de mandar o agente trabalhar.
E tem um detalhe que ele menciona e que muda a conversa: "Messy code slows my agents down." Código mal projetado não é só problema de manutenibilidade para humanos. Afeta diretamente a qualidade da geração. O agente navega melhor em código com módulos claros e interfaces simples. Arquitetura virou infraestrutura do agente, não só do time.
O padrão entre os dois
Boris abriu mão das instruções que compensavam limitações do modelo. Uncle Bob abriu mão da revisão linha a linha da implementação. Os dois preservaram o que o modelo não pode substituir.
No caso de Boris: as restrições que definem o perímetro do sistema — segurança, permissões, análise estática. No caso de Uncle Bob: o design que dá ao agente superfície navegável e os testes que especificam o que comportamento correto significa.
Nenhum dos dois abriu mão da intenção. Abriram mão da supervisão da execução.
Onde foi parar o trabalho do engenheiro sênior
O V-Bounce (arXiv 2408.03416) descreve esse movimento no nível estrutural: a IA ocupa o vale da execução, e o valor humano migra para os flancos de especificação e validação. Na minha leitura, Boris e Uncle Bob não estão descrevendo uma teoria — estão contando o que já fizeram e está funcionando.
O engenheiro que ainda acumula instruções no prompt para corrigir comportamentos do modelo provavelmente está compensando limitações de versões anteriores. Com modelos mais capazes, clareza do que se pede é o que vira alavanca. Volume de instrução, não.
O engenheiro que ainda faz code review linha a linha de código gerado por agente está trocando atenção cara por trabalho que o agente já entrega bem. O que passa a valer é o julgamento sobre o que os testes de aceitação precisam garantir.
Especificar comportamento e projetar estrutura sempre foram o trabalho mais difícil da engenharia. Antes ficavam enterrados no meio da execução. Agora são o que sobrou.
Referências
- Boris Cherny – We Cut 80% of Claude Code's Prompt (Y Combinator, Startup School 2026)
- LIVE: Uncle Bob on Software Fundamentals in the Age of AI (Matt Pocock)
- Transcript: Boris Cherny on Claude Code prompt reduction (SozAI)
- Uncle Bob: Skip Code Review, Build a Test Gauntlet (ExplainX.ai, julho 2026)
- Claude Opus 5 – ARC-AGI-3 Results (ARC Prize)
- Cory Hymel – The AI-Native Software Development Lifecycle, V-Bounce (arXiv 2408.03416)