Dijkstra vs Claude Code: 3 citações que uso na revisão

Tenho um arquivo ~/quotes.txt de umas dez linhas que eu abro toda vez que o Claude Code sugere refatorar uma função que já funcionava. Não é ritual, é freio. Copio três citações de lá, colo no início do prompt seguinte e mando de novo.

As três são todas do século passado. Uma de 1975, uma sem data precisa e uma da palestra do Turing Award de 1981. Não têm nada de novidade e nada de “prompt engineering”. São recados curtos de pessoas que passaram a carreira pensando em complexidade, e que eu uso pra lembrar o modelo — e a mim — de que “melhorar” quase sempre quer dizer “adicionar”, e adicionar quase sempre é a coisa errada.

As três que ficam

1. Dijkstra, EWD498 (1975)

“Simplicity is prerequisite for reliability.”

Escolhi essa primeiro porque a palavra que interessa é prerequisite. Não é “simplicidade é bom”, é “sem simplicidade, confiabilidade não acontece”. Quando o Claude Code me devolve um design com factory + strategy + uma camada de config pra generalizar um if de seis linhas, essa frase me dá vocabulário pra recusar. Não é “eu prefiro simples”, é “você acabou de ferir um pré-requisito”.

2. Ken Thompson

“One of my most productive days was throwing away 1000 lines of code.”

Essa aqui é anti-métrica. Modelos treinados em código público aprenderam que “mais código” parece “mais trabalho, mais valor”. Thompson foi co-criador do UNIX e depois trabalhou no design do Go, e disse com todas as letras que apagar mil linhas foi um dos dias mais produtivos que ele teve. Quando essa linha entra no prompt, muda o critério de sucesso: “melhor” deixa de ser “mais funcionalidade” e passa a ser “menos linha pra fazer o mesmo”.

3. C.A.R. Hoare, Turing Award Lecture (1981)

“There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.”

É a mais longa das três e é a que mais muda o tom da resposta do Claude Code. A diferença entre obviously no deficiencies e no obvious deficiencies é justamente a fronteira que separa código correto de código “onde a gente ainda não achou o bug”. Quando o modelo propõe um desenho de sete camadas pra resolver algo que cabe numa função, essa linha vira pergunta direta: “isso aqui é o obviously no deficiencies ou o no obvious deficiencies?”

O que eu não medi

Vou ser honesto sobre o que este post não é: não é um estudo de N pull requests. Não tenho planilha de linhas adicionadas versus removidas, antes e depois. Não rodei um harness de “três tarefas vezes duas execuções” pra falar em porcentagem. Faz tempo que penso em montar esse experimento, pegar uns diffs reais do meu próprio repo e rodar cada um duas vezes, uma com as três citações no system prompt e outra sem, medindo tokens e linhas do output. Ainda não fiz. No dia em que rodar, boto os dados aqui.

O que este post é: uma prática que eu adotei porque parou de compensar aceitar a “melhoria” do modelo e reverter meia hora depois.

O que muda qualitativamente

Sem citação nenhuma no prompt, o Claude Code, quando eu peço “refatore”, costuma propor três coisas parecidas:

1. Extrair a lógica em uma classe, mesmo pra função de doze linhas
2. Adicionar tratamento defensivo pra caso o input seja None, quando nenhum chamador passa None
3. Introduzir uma camada de configuração “pra flexibilidade futura”

Com as três citações coladas no começo do prompt, os três padrões caem. Não sempre, mas na maioria das vezes. O modelo continua propondo refatoração, só que a proposta muda de forma. Vira mais “renomear essa variável” e menos “criar uma factory”. Vira mais “deletar esse branch morto” e menos “extrair essa duplicação numa base class”. Vira mais “seu for já está claro” e menos “isso poderia virar reduce”.

Não é mágica. É que o critério de sucesso do modelo mudou explicitamente. Sem prompt específico, o critério default parece ser “código que aparenta profissionalismo”. Com as três citações, o critério vira “código que o Dijkstra chamaria de simples e que o Thompson jogaria fora se pudesse”. A resposta muda porque o alvo mudou.

Esse padrão de projetar o critério em vez de escrever proibição é o mesmo que Boris Cherny descreve em não brigue com o modelo: quando você projeta o ambiente pra que o comportamento errado não seja o caminho de menor resistência, para de precisar bloquear caso a caso.

Onde isso falha

Não uso as três citações em todo prompt. Elas atrapalham em pelo menos três situações:

Código de compliance. Se o problema é validação de PII ou log de auditoria, “delete linha” é conselho ruim. Defesa em profundidade é feature, não desperdício. Aqui eu tiro as citações e deixo o Claude Code operar com o critério oposto.

Debug de sistema legado. Quando estou tentando entender por que algo quebrou em produção, quero mais log e mais asserção, não menos. As três citações valem pra escrita, não pra investigação.

Modelo pequeno. Rodo Qwen 4B local pra tarefas rápidas. Ele lê as três citações como decoração, não como critério. Precisa de instrução direta (“não introduza classes novas nesta refatoração”) em vez de filosofia.

Tratar as citações como dogma é o mesmo erro que tratar SOLID como dogma. São ferramentas, cada uma com faixa de aplicação.

Por que essas três e não outras

O livro em que eu peguei elas — a coletânea em PT de 100 frases da engenharia — tem outras que caberiam bem no ~/quotes.txt. YAGNI e KISS estão a duas seções de distância. A frase do Fowler “any fool can write code that a computer can understand” é ótima pra revisar legibilidade. Escolhi essas três porque cobrem três eixos diferentes:

• Dijkstra 1975 → simplicidade como pré-requisito, não como preferência
• Thompson → deletar código é progresso, não regresso
• Hoare 1981 → correção óbvia vs. correção plausível

Se eu enfileirasse três Dijkstras, o modelo trataria como redundância. Três eixos ortogonais, uma frase pra cada, deixa espaço pro modelo triangular em vez de repetir o mesmo argumento em três formatos.

Se quiser ver as outras noventa e sete e o contexto original de cada uma, elas estão organizadas em capítulos por tema (estética do código, bugs, design, times, IA) na coletânea PT que eu montei — justamente porque eu queria esse arquivo ~/quotes.txt no formato de livro, com o contexto de cada frase. Sem esse contexto, “premature optimization is the root of all evil” vira meme, não critério.

---

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews