Uncle Bob Reconstruiu Sua Prática com Agentes. O Arquivo de Instruções Caiu Primeiro.

Pergunte a Robert C. Martin o que acontece com as regras que você escreve no prompt de um agente e ele recorre a uma referência de cinema. Os modelos, disse ele a Matt Pocock em agosto de 2026, “treat those rules in the uh Pirates of the Caribbean sense. They’re more like guidelines, you know, might follow”. Tratam as regras como as do código dos piratas: são mais diretrizes do que regras, e talvez sejam seguidas.

Martin programa desde 1964. Escreveu o livro que a maior parte dos times de engenharia cita quando discute qualidade de código. Entre dezembro de 2025 e agosto de 2026 ele reconstruiu a própria prática em torno de agentes de codificação, e o arquivo de instruções foi a primeira coisa em que parou de confiar.

Ainda hoje defendemos aqui que um verificador determinístico vence um parágrafo no AGENTS.md. Martin chega ao mesmo lugar vindo de cinquenta anos na direção oposta, e então avança para uma conclusão que não tínhamos alcançado: as disciplinas humanas não se transferem para agentes. Só os valores humanos se transferem, e os limiares precisam ser recalculados.

A razão técnica pela qual o prompt se degrada

Martin nomeia uma causa, não uma impressão. O material no começo e no fim de uma janela de contexto carrega mais proeminência do que o material no meio, o efeito que a literatura chama de lost-in-the-middle. Um prompt inicial longo empurra as próprias frases finais para a região que o modelo pesa menos. Uma regra escrita perto do fim de um arquivo de instruções longo cai exatamente nessa região.

A prescrição dele decorre disso. “The key with agents is to trim that initial prompt down to its absolute minimum so that you can get as much of it as possible into its priority”, diz, e “then do deterministic tools after the fact”. Reduzir o prompt inicial ao mínimo absoluto para que o máximo dele caia na região de prioridade, e depois usar ferramentas determinísticas.

A segunda metade é onde a prática mora. Uma ferramenta determinística funciona colocando o agente em um loop: ele precisa continuar mudando o código até a ferramenta dizer que o código está aceitável. Nada nesse mecanismo depende de o modelo ler uma frase e decidir honrá-la. Martin acrescenta uma ressalva honesta. Deve existir um ponto em que verificações suficientes deixam os agentes mais lentos que humanos e o arranjo deixa de compensar. Pelo relato dele, esse ponto ainda não apareceu.

Valores se transferem. Disciplinas, não.

Vale levar esta frase, literal, para a próxima reunião de padrões do seu time: “it’s probably a mistake to impose a human discipline on an agent. It is not a mistake to impose human values on the agent, but there may be thresholds that we need to change”. Impor uma disciplina humana a um agente é provavelmente um erro. Impor valores humanos não é, mas pode haver limiares que precisamos mudar.

Martin então aplica isso à disciplina com a qual ele é mais identificado. Ele defende desenvolvimento guiado por testes para humanos. E não vai impor isso a agentes. Não acha que faça sentido um agente alternar uma linha de teste com uma linha de código de produção, e relata deixar agentes escreverem uma função e depois o teste dela, mesmo em execuções em que instruiu os agentes a fazer TDD.

O valor por baixo do TDD sobrevive a isso. O código chega com testes que o restringem. O ritual que produz esse valor em um humano é outra coisa, e a razão declarada por Martin para deixá-lo de lado é direta: TDD é uma disciplina que existe porque humanos são constituídos de um certo jeito. Agentes são constituídos de outro, então o ritual não compra nada, e pelo relato dele os agentes voltam a escrever função e depois teste independentemente do que ele instrua.

O limiar se move junto. Martin mantém o escore CRAP abaixo de quatro para código escrito por humanos. Para agentes, ele “set this at six”, e diz “maybe I’ll push it to eight”. A razão declarada para o movimento é que agentes carregam uma memória de curto prazo muito maior e, na descrição dele, perfeitamente precisa. Mesmo valor, trabalhador diferente, número recalculado. Ainda não vi um time perguntar quais dos seus limiares são propriedade do padrão e quais são propriedade do humano que tinha de atingi-lo.

Duas ideias do ano 2000 que só agora ficaram viáveis

CRAP é uma métrica do início dos anos 2000 que junta cobertura de testes e complexidade ciclomática em um único escore de quão ruim uma função é. Teste de mutação inverte operadores no código-fonte e exige que a suíte fique vermelha; um mutante que sobrevive marca um buraco nos testes. Martin diz que ambas eram boas ideias que ele deixou de lado por volta do ano 2000, porque o trabalho humano exigido era impraticável.

Agentes mudaram essa aritmética. São rápidos e não se importam com o quanto o trabalho é tedioso. Duas métricas academicamente respeitáveis e operacionalmente mortas agora estão baratas o bastante para rodar em loop, e foi por isso que Martin as pegou de volta.

A mesma mudança explica um achado menor da entrevista que merece atenção de quem roda agentes em uma base antiga. Código bagunçado degrada agentes, não apenas humanos. Martin descreve um agente que mudava uma coisa, quebrava outra sem perceber e começava a andar em círculos, e conta que um agente basicamente desistiu de uma base de código. Agentes são, nas palavras dele, “as subject as humans are to messy code”, tão sujeitos a código bagunçado quanto humanos, possivelmente em um limiar diferente. Isso é confirmação em primeira mão de um dos modos da taxonomia de degradação, não um mecanismo novo.

Ele joga fora o plano e mantém a restrição

A rejeição de Martin ao desenvolvimento guiado por especificação é mais estreita do que a manchete sugere, e essa distinção é o ponto central.

O que ele rejeita é o planejamento pesado feito antes do trabalho. Diz que já tentou isso com agentes e “it’s always a disaster”, sempre um desastre, com o mesmo formato toda vez: no meio da execução os humanos percebem que os agentes não conseguem seguir o plano, porque o plano não antecipou tudo. O trabalho para. O plano é reescrito. Os agentes recomeçam. Ele compara essa tentação com a que produziu o modelo cascata nos anos 1970, e observa que agentes adoram escrever planos e que os planos que escrevem são elaborados.

O que ele mantém é executável. O pipeline dele emite critérios de aceitação em Gherkin e um procedimento de QA. As regras de dependência vivem em um arquivo de especificação persistido que define qual módulo pode depender de qual e como as dependências devem fluir, verificado por um checador que roda ao final e que os agentes precisam satisfazer, em geral invertendo uma dependência, inserindo uma interface ou dividindo um módulo. Ele também pediu a agentes que construíssem um visualizador de arquitetura que renderiza a estrutura de módulos e permite descer até o código.

Especificações escritas ele trata como descartáveis. Diz que suas especificações são efêmeras, que não as guarda no repositório e que trata o resultado final como a especificação. Recomenda que as pessoas apontem os próprios agentes para as ferramentas dele e deixem esses agentes construírem as suas, em vez de baixar as originais.

Uma etapa resiste a tudo isso. Automatizar o desenho dos módulos é onde ele está travado. Descreve interrogar agentes sobre a estrutura de módulos, se alarmar com as respostas e fazer o particionamento ele mesmo. Sobre automatizar essa etapa, pelo próprio relato, ele está “having not a lot of luck” até aqui, sem muita sorte. A concordância dele com John Ousterhout sobre módulos profundos explica parte do que está em jogo: uma interface pequena sobre uma implementação grande e escondida serve bem aos modelos, porque o modelo consegue ler a interface sem ler a implementação. Martin chama isso de vantagem e de perigo, e acrescenta que só vale enquanto o código é consistente. Agentes também leem os testes para descobrir o que o sistema faz, outra razão para o particionamento estar certo antes de soltá-los ali. O enquadramento estratégico contra tático por baixo disso é assunto que já tratamos separadamente.

Quanto custa passar pelo funil

As cinco etapas de Martin rodam em ordem: um especificador que transforma um documento escrito por humano em um teste de aceitação Gherkin e um procedimento de QA escrito do ponto de vista de uma pessoa operando a interface; um codificador que escreve os testes unitários e a implementação; um limpador que roda análise CRAP e revisão geral; um endurecedor que roda teste de mutação e é descrito como implacável quanto a cobertura; e um agente de QA que transforma o documento de QA em um script executável com resultado determinístico.

Os números são dele, tirados da própria prática, sem benchmark por trás. Uma tarefa que um agente único termina em cerca de cinco minutos com resultado questionável leva cerca de uma hora pela cadeia. Uma pessoa leva cerca de meio dia. Ele chama isso de “a factor of four factor of five improvement in productivity”, um ganho de produtividade de quatro a cinco vezes.

Tome isso como o dado de um praticante em favor do argumento de que o ganho de velocidade decai sem verificação no loop, e não como um achado medido. Os cinco minutos e a uma hora são o par interessante. Cerca de doze vezes o custo de relógio compra a diferença entre saída e saída que dá para integrar.

Separe seus padrões esta semana

Pegue seu AGENTS.md, seu manual de engenharia ou qualquer documento que seus agentes deveriam honrar. Percorra linha por linha e coloque cada regra em uma de duas colunas.

Coluna um: valores que seus agentes devem herdar. O código chega com testes. As dependências apontam para dentro, e as funções ficam pequenas o bastante para caber em uma leitura. Essas regras pertencem ao trabalho, não ao trabalhador, e cada uma precisa de um verificador rodando em loop, mais um limiar que você recalculou deliberadamente para um trabalhador com outra memória e outra velocidade.

Coluna dois: disciplinas humanas que você vem impondo por reflexo. Ordem ritual de passos. Granularidade de commit. Qualquer regra cuja justificativa, dita em voz alta, fale sobre como a atenção de uma pessoa se comporta. Essas regras não rendem nada vindas de um agente e consomem prioridade de prompt que uma restrição real poderia estar usando.

Pela minha experiência, a segunda coluna sai maior do que qualquer um espera, e quase nada da primeira coluna acaba sendo imposto por algo além de uma frase. Esse é o trabalho. Governança mora no harness, e uma regra que existe só como prosa é uma regra que o modelo pode tratar como diretriz.

O aviso final de Martin é sobre o que acontece com os fundamentos no meio de tudo isso: “The rules you throw away are the ones you’re going to pick up off the floor in a year and dust off and remember why you need them”. As regras que você joga fora são as que vai catar do chão daqui a um ano, tirar o pó e lembrar por que precisava delas. Ele argumenta que software é a coisa mais complicada que humanos já tentaram fazer, ideia que atribui a Dijkstra dizendo ele próprio que espera errar a atribuição, e que os fundamentos são como essa complexidade se organiza em uma forma que humanos e modelos conseguem sustentar, já que os modelos são modelados a partir de nós.

---

Fontes

• Matt Pocock, em conversa com Robert C. Martin. “LIVE: Uncle Bob on Software Fundamentals in the Age of AI.” Agosto de 2026.

A Victorino ajuda times de engenharia a converter padrões escritos em verificações determinísticas que os agentes não conseguem tratar como diretrizes: contato@victorino.com.br | www.victorino.com.br