Intent engineering: pare de escrever passos, escreva o 'pronto'

Tem uma frase na página de boas práticas de prompt da Anthropic que deveria encerrar a era dos truquezinhos: "um prompt como 'pense com profundidade' costuma produzir um raciocínio melhor do que um plano passo a passo escrito à mão. O raciocínio do Claude frequentemente supera o que um humano prescreveria."

Lê de novo. Não é "seu plano numerado parou de ajudar". É "seu plano numerado perde para duas palavras vagas".

E tem uma versão mais forte na mesma página. Lembra de colar "antes de terminar, confira sua resposta contra os critérios de teste" em tudo? A orientação atual da Anthropic para o Claude Opus 5 é que o modelo já confere o próprio trabalho muito bem, que essas linhas herdadas causam excesso de verificação — mais tokens e mais latência, sem ganho nenhum — e que, na migração, você deve apagar essas instruções em vez de reescrevê-las. O fornecedor pedindo pra você deletar um truque de prompt. É a virada inteira em um item de lista.

Por que os truques pararam de pagar

Porque o planejamento foi pra dentro do modelo. No Claude Opus 5, Sonnet 5, Fable 5 e Mythos 5 o raciocínio já vem ligado, sem configuração nenhuma, e a Anthropic descreve sem rodeios o que acontece ali: o Claude "reafirma o que está sendo pedido, tenta abordagens, checa resultados intermediários e abandona caminhos que não se sustentam". A profundidade é calibrada por duas coisas — o parâmetro effort e a complexidade da sua pergunta — e a Anthropic afirma que, nas avaliações internas, esse raciocínio adaptativo "entrega performance melhor de forma consistente" que o esquema antigo de orçamento fixo.

Ou seja: quando você cola primeiro faça A, depois B, depois C, você não está adicionando rigor. Está sobrescrevendo um planejador que explora, se corrige e volta atrás com uma linha reta que você desenhou antes de olhar o problema. O texto da Anthropic sobre agentes chega no mesmo ponto pelo outro lado: agente vale a pena justamente em problema aberto, onde você "não consegue fixar um caminho no código" nem prever quantos passos o trabalho vai exigir.

Minha regra de bolso como EM: se eu consigo escrever os passos de forma confiável, aquilo não é tarefa de modelo — é script. Na hora que eu me pego sequenciando, ou vou escrever o comando de bash, ou admito que não sei o caminho e entrego o objetivo.

O antes/depois, num ticket de verdade

Mesma missão nos dois casos: o CI fica vermelho em metade das manhãs por causa de testes instáveis, e ninguém é dono disso.

Antes — a pilha de truques. Todos os hábitos de 2023, empilhados:

Você é um especialista em QA de nível mundial. Vamos pensar passo a passo.
Primeiro, leia os arquivos de teste. Depois liste todos os testes instáveis.
Depois, para cada um, explique a causa raiz. Depois ranqueie. Depois proponha
uma correção para cada. Respire fundo e confira sua resposta antes de terminar.
Isso é muito importante para a minha carreira.

Seis verbos em sequência, um crachá de especialista de mentira, uma autoverificação redundante e uma chantagem emocional. Nada ali diz o que é um bom resultado — então você recebe uma tabela belíssima com vinte testes instáveis ranqueados, o modelo se considera pronto, e o que você precisava era um pipeline verde amanhã.

Depois — intenção. Os quatro campos que eu uso pra tudo hoje:

OBJETIVO: fazer o `pnpm test` passar dez execuções seguidas no CI, sem retry.

RESTRIÇÕES: Node 22, Vitest, GitHub Actions. Mexa só em arquivos dentro de
`tests/` e no `vitest.config.ts`. Nenhuma dependência nova. O pipeline
continua abaixo de 8 minutos.

PRONTO QUANDO: você conseguir nomear cada teste que mudou, a corrida ou o
estado compartilhado específico que deixava ele instável, e as dez execuções
verdes consecutivas que provam isso. Se um teste é instável porque o código
testado está realmente errado, pare e me avise em vez de estabilizar o teste.

NÃO FAÇA: não pule testes nem marque como `.todo`, não adicione retry geral,
não adicione sleep, não afrouxe as asserções até elas passarem.

O segundo prompt é mais longo. E é também o único que pode falhar de forma honesta — que é exatamente o ponto.

Os quatro campos

Guarda isso num expansor de snippet e vai preenchendo. Noventa segundos, sempre.

OBJETIVO: [o resultado em uma frase, descrito como resultado — não como método]

RESTRIÇÕES: [stack, arquivos que ele pode tocar, orçamento, prazo, regras
             duras — o que for realmente não negociável]

PRONTO QUANDO: [a condição que outra pessoa consegue conferir sem refazer o
                trabalho. De preferência algo verificável por máquina: um
                comando que sai com código 0, um número que se move, um
                checklist todo marcado]

NÃO FAÇA: [os modos de falha que você já viu na prática — escopo crescendo,
           abstração nova, API inventada, código defensivo pra caso impossível]

Dois desses campos sustentam mais peso do que as pessoas imaginam.

PRONTO QUANDO é o que todo mundo pula. A orientação da Anthropic para tarefas de pesquisa começa exatamente com essa instrução — "forneça critérios claros de sucesso: defina o que constitui uma resposta bem-sucedida" — e é a primeira coisa que falta em quase toda resposta decepcionante que eu já depurei. Um modelo que não sabe quando acabou ou para cedo demais, ou fica lustrando muito depois de valer a pena.

NÃO FAÇA virou campo de primeira classe, não frescura. Esse me surpreendeu: a documentação da Anthropic traz um prompt pronto pra conter super-engenharia, organizado em quatro categorias nomeadas de coisas que não se deve fazer — escopo ("uma correção de bug não precisa limpar o código em volta"), documentação, código defensivo e abstrações. Quando o próprio fornecedor escreve um bloco de "não faça", pega a dica: com modelo capaz, o espaço negativo do seu brief pesa tanto quanto o pedido.

A armadilha: uma condição de pronto que o modelo consegue burlar

Quando você começa a escrever condições de pronto, você vai escrever uma ruim. A minha foi "faça o teste que está falhando passar". Recebi um valor de retorno chumbado que fazia o teste passar.

A Anthropic documenta esse modo de falha — o modelo pode se apoiar demais em fazer os testes passarem em detrimento de uma solução geral — e o prompt de exemplo deles tem a frase que eu roubei em definitivo: "os testes existem para verificar a correção, não para definir a solução." Junto vem "implemente uma solução que funcione corretamente para todas as entradas válidas, não só para os casos de teste" e um convite explícito ao contraponto: se a tarefa é inviável ou o teste está errado, diga isso em vez de dar a volta por cima.

Então a condição de pronto tem duas funções ao mesmo tempo — apertada o bastante pra ser conferida, explícita o bastante sobre o que ela não autoriza. Sempre que a minha pode ser satisfeita com trapaça, eu adiciono a linha anti-trapaça em vez de afrouxar o critério.

Na API, "pronto" também é parâmetro

É aqui que intent engineering deixa de ser estilo de escrita e vira configuração. Dois botões que valem conhecer:

• effort — cinco níveis (low até max), com padrão em high. Ele afeta todos os tokens, inclusive quantas chamadas de ferramenta o Claude faz, e a Anthropic é direta: é "um sinal de comportamento, não um orçamento rígido de tokens". O nível xhigh existe pra trabalho agêntico de longa duração, acima de 30 minutos, com orçamento de tokens na casa dos milhões. E a recomendação para quando o raciocínio parece raso é reveladora: aumente o effort em vez de tentar contornar com prompt.
• task_budget (beta) — você dá ao loop agêntico uma cota de tokens e o modelo passa a ver uma contagem regressiva, injetada no servidor e visível só para o modelo, pra ele se ritmar e fechar o trabalho com elegância em vez de ser cortado no meio de uma ação. O total mínimo aceito é 20.000 tokens, e a documentação traz um aviso afiado: um orçamento visivelmente pequeno para o tamanho do trabalho pode fazer o Claude recusar a tarefa ou parar cedo, em vez de começar algo que não consegue terminar.

Especifique "pronto" de menos e você cai no loop infinito clássico — que é justamente por que a orientação da Anthropic sobre agentes recomenda condições de parada "como um número máximo de iterações". Uma condição de parada é uma condição de pronto, só escrita em infraestrutura em vez de prosa.

Faça isso hoje

Abre o prompt que você mais reutiliza. Apaga todo primeiro… depois…, todo "pense passo a passo", todo "confira antes de terminar". Adiciona uma linha começando com PRONTO QUANDO: que um colega consiga conferir sem você. Depois roda a versão velha e a nova na mesma entrada, uma atrás da outra, e fica com a vencedora. Um prompt, dez minutos — e você para de pagar por instruções que o modelo já superou.

Fontes

• Anthropic — Prompting best practices
• Anthropic — Thinking
• Anthropic — Effort
• Anthropic — Task budgets
• Anthropic — Building effective AI agents