O direito de não ler o código

Raphael Moura | 24 de jul. de 2026 min de leitura
O direito de não ler o código

O Uncle Bob construiu a reputação mandando você ler código. É dele a estimativa, no primeiro capítulo do Clean Code, de que a razão entre tempo lendo e tempo escrevendo passa bem de dez para um. Essa semana, respondendo a um desenvolvedor que dizia precisar entender o código pelo qual responde, ele publicou no X que a estratégia atual com os coding agents dele é não ler uma linha do que produzem:

Concordo com praticamente cada palavra. Venho operando essa filosofia há mais de um ano no meu guideline de desenvolvimento com agentes, num domínio onde erro de cálculo vira passivo. O tweet condensa num parágrafo a inversão mais importante do desenvolvimento com agentes. Também é a mais fácil de copiar errado.

O que ele está dizendo de verdade

Lida isolada, a primeira metade soa como negligência. Só que a frase que carrega o peso vem na segunda metade: surround the agents with extreme constraints. Ele tirou a verificação do olho e mudou o endereço dela. A confiança passou a morar no que o código sobreviveu, e gauntlet é isso, o corredor polonês: você só confia em quem atravessou a fileira inteira apanhando.

É o mesmo desenho que a indústria automotiva usa para aprovar carro: nenhum regulador lê o CAD da longarina, o laboratório lança o carro contra uma barreira a 64 km/h com bonecos instrumentados e a nota sai dos sensores. Ninguém chama crash test de negligência. Chamam de engenharia.

E repara que não existe contradição com o resto da obra dele. As três leis de TDD que ele prega há mais de vinte anos já proibiam linha de código de produção sem um teste falhando antes. Gherkin na lista tampouco é acaso: cenário executável é spec com poder de veto, o papel que os acceptance criteria numerados cumprem no meu guideline. O tweet leva o TDD à conclusão lógica, pela mão de quem o transformou em disciplina: a doutrina é a mesma, e o que mudou foi quem digita.

Ler cada linha não escala, e fingir que lê é pior

A literatura clássica de inspeção, o estudo da SmartBear com a equipe da Cisco, recomenda revisar no máximo 200 a 400 linhas por sessão, porque acima disso a taxa de detecção de defeito despenca. Um agente produtivo gera esse volume antes do seu primeiro café. Se a garantia de qualidade é um humano lendo linha a linha, a vazão de merge do time é a vazão de leitura do time, e o Lucas F. Costa já tinha dado nome a esse teto: qualquer fluxo que depende de um humano para pegar os erros da máquina fica limitado pelo humano, não pela máquina. A resposta que ele propôs no mesmo texto chama backpressure: todo não que a máquina consegue dar, ela dá antes de um humano olhar.

O que acontece quando o volume satura o revisor é pior que fila. O review degrada em vez de parar: vira scroll, vira LGTM em diff de oitocentas linhas. Isso é pior que o não-ler assumido, porque produz sensação de controle sem o controle. E mesmo onde a leitura é real, o diff limita o que ela enxerga: a regressão fora do diff, o consumidor distante do campo que mudou, é invisível para quem lê a mudança e trivial para a suite acumulada que roda inteira a cada PR. O leitor vê a mudança; a rede vê o sistema. O Uncle Bob só assumiu em voz alta a conta que o mercado finge que não existe: entre o review teatral e um cerco honesto, ele escolheu o cerco.

A anatomia do cerco

O cerco que funciona tem camadas, e a ordem importa: barato e binário na frente, caro e semântico atrás. Type check, lint e build são o portão de entrada. Depois vêm os testes de unidade, ancorados nos acceptance criteria da spec em vez de espelhar a implementação, porque teste que espelha implementação defende o bug atual contra o conserto. Coverage entra como piso por capability, contract tests seguram as fronteiras entre serviços, e regra que deriva de fonte externa ganha golden tests com input e output de referência, porque revisor humano não recalcula valor contra a norma, nem quando lê o código.

Na lista do tweet, o item que mais gente ignora é o que sustenta os outros: mutation testing. Coverage diz que o código rodou durante os testes; mutation testing diz se os testes perceberiam o código mudando. A ferramenta injeta defeitos deliberados, inverte uma condição, remove uma chamada, e conta quantos mutantes a sua suite mata. Com agente isso importa em dobro, porque agente otimiza contra o gate que você mede: quando a meta é coverage, ele aprende a produzir teste que executa tudo e afirma quase nada. Mutation testing mata essa classe de teste; sem ele, “não leio o código porque tenho 90% de coverage” é autoengano com dashboard. PIT no mundo Java, Stryker em JavaScript e TypeScript, mutmut em Python: a ferramenta existe, o que falta é hábito. E quando ela não existe para a sua stack, você escreve a sua: o próprio Uncle Bob pôs o Claude para escrever um mutation tester em Clojure e fechar os gaps da própria suite.

Acima da camada determinística entra a inferencial, com uma regra de ouro: quem revisa nunca é quem escreveu. Reviewer separado, contexto isolado, read-only por configuração da ferramenta. A Anthropic documentou em primeira mão o viés que justifica isso: agente elogia com confiança o próprio trabalho medíocre. Pedir ao agente que revise o próprio diff é deixar o aluno corrigir a própria prova.

A lista inteira do Uncle Bob tem uma coisa em comum: nenhum item mora num prompt. Tudo roda em CI e devolve vermelho sem pedir licença. Constraint de verdade é enforcement, o modelo esbarra nela e para; se o seu cerco mora no system prompt, você tem um pedido educado.

O cerco em camadas: gates determinísticos na frente, reviewer independente atrás, cada reprovação voltando para o agente antes de qualquer olho humano. O humano recebe o que sobreviveu, mais os diffs de spec, que nunca passam sem ele.

O cerco em camadas: gates determinísticos na frente, reviewer independente atrás, cada reprovação voltando para o agente antes de qualquer olho humano. O humano recebe o que sobreviveu, mais os diffs de spec, que nunca passam sem ele.

O que você lê no lugar do diff

Parar de ler o código não significa parar de ler. O budget de leitura muda de endereço: sai do output e vai para o oráculo. O que recebe seu olho linha a linha passa a ser a spec e os acceptance criteria antes de o agente rodar, os testes que ele escreveu, porque teste é contrato e se lê em fração do tempo da implementação, o mutation score, os findings do reviewer, e todo diff de spec, porque mudança de regra de negócio passa por olho humano sempre. No meu fluxo isso é um flag de requires_human_approval que nenhum CI verde remove.

E o papel muda junto. O Uncle Bob não saiu do loop, ele subiu de posição: de inspetor de peça para projetista do cerco. Cada escape vira trabalho de engenharia: se um bug atravessou o gauntlet, a pergunta madura é qual gate faltou, e a resposta é construí-lo. É o backpressure aplicado ao review, e a atenção humana vai para onde ela é insubstituível, a regra de negócio, a fronteira entre capabilities, a exceção que o cerco cuspiu.

Para onde vai o budget de leitura: antes, o humano entre o agente e o merge, lendo diff em volume; depois, o humano acima do fluxo, escrevendo criteria, lendo spec, teste e score, e recebendo só as exceções.

Para onde vai o budget de leitura: antes, o humano entre o agente e o merge, lendo diff em volume; depois, o humano acima do fluxo, escrevendo criteria, lendo spec, teste e score, e recebendo só as exceções.

Onde o tweet precisa de letra miúda

Primeira ressalva: o direito de não ler se conquista, e o Uncle Bob levou meio século construindo o dele. O homem escreveu as três leis de TDD que a indústria repete e segue publicando, a série Clean AI: Agentic Discipline deste ano abre com a tese de que o maior perigo dos agentes é a indisciplina. O cerco dele é autoral. Copiar a manchete sem construir o cerco é vibe coding com autoconfiança, e te garanto que boa parte das pessoas repetindo “nem leio o código” esta semana não tem um mutation test rodando. No meu guideline isso vira regra operacional: começa com humano aprovando todo PR, e o não-ler avança por classe de mudança, trinta PRs consecutivos limpos qualificam aquela classe, o resto do sistema segue esperando o próprio track record. Confiança global declarada no dia um tem outro nome, fé.

Segunda: o contraponto tem nome e o debate tem histórico. O tweet de julho é o segundo round de uma conversa que começou em abril, quando o Uncle Bob já tinha publicado que não revisa código de agente e mede, no lugar, coverage, estrutura de dependências, complexidade ciclomática, tamanho de módulo e mutation testing. O Grady Booch respondeu em público que revisa todo código gerado, porque métrica dá confiança de funcionalidade e nenhuma confiança de que o agente não introduziu vulnerabilidade, dead code que corrói o entendimento futuro, fatoração perdida com impacto real de performance. Trust but verify, fechou ele. A objeção é séria, e a resposta vem em três partes: validação dinâmica, um agente de QA exercitando a aplicação deployada para enxergar o que nenhuma análise de diff enxerga; security como gate determinístico, SAST, SCA e secret scanning em todo PR; e uma fronteira permanente: no meu sistema, arquitetura e cálculo normativo nunca entram na esteira do não-ler, o primeiro porque é decisão de negócio com forma de código, o segundo porque “very high confidence” não é argumento diante de auditor. O Uncle Bob pode viver com alta confiança; quem responde por regra com fonte normativa precisa de oráculo, e oráculo ali é golden test com humano lendo o diff da spec.

Terceira: o cerco custa caro. Os números que a Anthropic publicou do experimento de harness deles: a tarefa que o modelo resolve sozinho por 9 dólares em 20 minutos custou cerca de 200 dólares e 6 horas com o harness completo, 124 e 4 na segunda versão. O cerco paga quando a tarefa excede o que o modelo entrega sozinho com confiabilidade; abaixo disso é cerimônia. E cerco apodrece: cada gate codifica uma suposição sobre o que o modelo não faz sozinho, cada geração de modelo vence algumas delas, e gate que ninguém re-audita vira peso morto no pipeline.

Quarta, a que menos gente comenta: ler o código era o meio, entender a lógica é o fim, e o cerco só aposenta o meio. O sistema continua seu, e você precisa continuar capaz de explicar por que uma mudança é segura e de desenhar a próxima fronteira. Quem deixa o entendimento ir embora junto com a leitura vira turista no próprio repositório, e turista não projeta cerco. Minha defesa é ritual: walkthrough de cada feature relevante, lido de verdade, mapa do sistema atualizado na cabeça mesmo sem ler cada diff. O loop executa por você. Ele não decide por você.

Fechando

O tweet condensa a inversão que define desenvolvimento com agentes: a confiança saiu da leitura do artefato e mudou para o processo que o artefato sobrevive. O cerco tem anatomia conhecida, determinístico na frente, reviewer independente atrás, mutation testing para manter os testes honestos, enforcement em vez de instrução. E o direito de não ler se conquista por classe, com evidência, com uma fronteira que não se move: regra de negócio, cálculo com fonte normativa e arquitetura continuam passando por olho humano.

O passo que recomendo muito para esta semana: liga mutation testing num módulo crítico de um repositório seu, Stryker, PIT ou mutmut conforme a stack, e compara o score com o coverage que você exibe hoje; a distância entre os dois números é o tamanho da sua ilusão de rede. Depois escreve os acceptance criteria da próxima feature antes de promptar o agente e deixa o cerco devolver PR antes de chegar ao seu olho. Quando isso acontecer com frequência, você entendeu o tweet: a máquina está dizendo não por você. O cerco completo que eu uso, skills, reviewer, hooks e template de spec, está no repositório do guideline.

Referências