FIXING Opus 5: PROOF that Prompt Engineering IS NOT DEAD

O que foi dito

• Abre listando os incômodos concretos do modelo: respostas longas demais, bordões repetidos (“load-bearing”, “worth stating plainly”, “here’s the honest truth”), o coautor da Anthropic acrescentado às mensagens de commit, e o consumo de tokens de saída maior que o de qualquer modelo anterior.
• Fixa a tese: existem duas superfícies de prompt, a do usuário (a tarefa individual) e a do sistema (a lei de toda tarefa), e a maioria dos engenheiros só mexe na primeira, além de se fixar em skills; cada palavra do system prompt se multiplica por todas as execuções.
• Monta o experimento com duas instâncias do Claude Code no mesmo multiplexador de terminal, uma sem alteração e outra recebendo um arquivo via a opção de acrescentar ao system prompt, ambas resumindo o mesmo texto longo (o post de Zuckerberg sobre o futuro da IA).
• Primeira camada, propósito: escreve à mão uma seção declarando uma relação “sem enrolação, clara, concisa e acionável” e explicando o porquê, sem atribuir papel ao modelo, apenas falando com ele como se fala com outro engenheiro; o efeito é pequeno, os tiques permanecem.
• Segunda camada, padrões positivos e negativos: manda replicar uns e evitar outros. Entre os positivos, pôr o mais importante por último (porque é a primeira coisa que o leitor vê), afirmar cada fato uma única vez, ajustar o nível de detalhe ao da tarefa, contestar diretamente pressupostos errados e explicar por quê, otimizar para clareza e não para frase de efeito, e usar a terminologia mais simples que comprima a informação.
• Entre os negativos, uma lista dos bordões a banir, mais: nada de analogias, moderação com travessões e correntes de travessões, nada de bajular, elogiar ou concordar sem razão, nada de títulos decorativos, emoji ou linguagem motivacional, nada de ponto e vírgula e pontuação fora do padrão.
• Registra que já nessa rodada os bordões somem, os travessões rareiam e o tempo cai, e insiste que o ganho é em tokens de saída, que consomem a maior parte da cota mesmo em assinatura.
• Terceira camada, pontos de referência: pede listas numeradas e códigos curtos (D para decisões, R para riscos, F para achados, P e assim por diante, com continuação livre para categorias não previstas), preservados ao longo da conversa e dispensados em respostas curtas; passa então a interagir dizendo apenas “fale mais sobre R6”, criando uma língua comum com o agente.
• Quarta camada, limites operacionais rígidos: entregar só o que foi pedido no escopo pretendido, não alargar o trabalho para limpeza, refatoração, documentação ou funcionalidades vizinhas, não especular abstrações para requisitos futuros, não alegar conclusão sem evidência, nunca acrescentar coautor à mensagem de commit e não fechar com recapitulação inchada; atribui esse comportamento ao treino por reforço, que ensina o modelo a achar a resposta a qualquer custo e, no caminho, perde foco.
• Quinta camada, aliases: códigos curtos expandidos como se tivessem sido escritos por extenso, com a ressalva de não expandir quando aparecem dentro de uma frase maior; cria “scr” para simplificar, comprimir e repetir a resposta, “eli” para explicar como se ele tivesse 18 anos, “focus” para reduzir ao que importa e “ref” para reescrever com pontos de referência, e demonstra cada um ao vivo.
• Sexta camada, exemplos: pares de resposta boa e ruim para o mesmo pedido, funcionando como dado de treino em contexto; o bom vai direto ao veredito técnico (“não adicione Redis aqui, este processo tem um único escritor, persiste em SQL e não exige coordenação entre hosts”), o ruim começa com “ótima pergunta” ou “você está absolutamente certo”.
• Sugere a técnica que chama de destilação em contexto: rodar o mesmo pedido num modelo cuja voz agrada (ele usa o Fable 5, que considera menos verboso e com menos tiques que o Opus 5), editar a resposta à mão e colá-la como exemplo do que fazer, com a saída do Opus sem ajuste como exemplo do que não fazer.
• Responde ao argumento de que o próprio Claude Code enxugou o system prompt: isso mostra que o modelo já faz muita coisa sozinho, não que o system prompt seja dispensável; quem quer comportamento específico precisa escrevê-lo.
• Defende repetidamente escrever isso à mão e devagar, sem ditado por voz e sem “vibe prompting”, justamente porque o artefato se multiplica sobre todas as execuções seguintes, e encerra dizendo que o gargalo hoje é o desenvolvedor, não o modelo, com a fórmula “manter o smart e largar o ass”.