Engenharia de prompt acabou: o que veio depois

Ninguém mais ganha dinheiro escrevendo prompt bonito.

Ganha quem decide o que entra na janela de contexto — e o que fica de fora.

Isso não significa que engenharia de prompt virou lixo. Significa algo mais desconfortável: ela deixou de ser a disciplina e virou um pedaço dela. Metade das técnicas que você decorou em 2023 sumiu porque o modelo aprendeu a fazer sozinho. A outra metade sumiu porque virou parâmetro de API. O que sobrou é pouco, é chato e é exatamente o que ninguém ensina.

Neste post você vai ver o que sobreviveu, o que virou folclore, e por que em sistema real o gargalo mudou de lugar: não é mais a frase que você escreve, é o conjunto de tokens que chega ao modelo em cada chamada.

TL;DR

O que morreu: prefill, budget_tokens, "let's think step by step", persona teatral, CAPS LOCK de ameaça.
O que sobreviveu: instrução específica, exemplos, delimitação estrutural, decomposição, critério de saída explícito.
O que mudou de camada: raciocínio virou dial (effort), formato virou schema (output_config.format), memória virou infraestrutura.
Onde o problema real está: ordem, corte e recência do que entra na janela.
Fontes centrais: The Prompt Report (58 técnicas catalogadas), Context Rot / Chroma (18 modelos, todos degradam), Anthropic — context engineering.

As técnicas de prompt que sobreviveram (e as que viraram folclore)

O levantamento mais completo que existe sobre o assunto é The Prompt Report: 31 pesquisadores, revisão sistemática de mais de 1.500 papers, taxonomia com 58 técnicas de prompt em texto, 40 para outras modalidades e 33 termos de vocabulário.

Cinquenta e oito.

Agora responde honestamente: quantas você usa em produção? Provavelmente cinco. Talvez quatro.

As que sobreviveram são as mais sem graça:

Instrução específica com critério de aceite. Não "escreva um resumo bom". E sim "resuma em até 3 bullets, cada um com no máximo 20 palavras, citando o número da cláusula".
Exemplos (few-shot). Continuam sendo a forma mais barata de transferir formato e nuance. Com um porém novo: exemplo ocupa janela, e janela agora tem preço.
Delimitação estrutural. No Claude, tags XML (<contexto>, <tarefa>, <formato>) separam melhor do que markdown solto — a documentação oficial recomenda isso desde sempre e continua valendo.
Decomposição. Quebrar uma tarefa grande em três chamadas pequenas ainda bate uma chamada gigante. Não porque o modelo é burro, mas porque erro composto é mais fácil de isolar.

As que viraram folclore são justamente as que ficaram famosas:

"Let's think step by step". Chain-of-thought deixou de ser truque de texto e virou botão. No Claude você liga thinking: {type: "adaptive"} e regula a profundidade com output_config.effort, que vai de low a max (docs). No GPT-5 é o reasoning_effort. Você não pede mais para o modelo pensar. Você orça quanto ele pensa.
budget_tokens. O antigo teto fixo de tokens de raciocínio está deprecado no Claude Opus 4.6 / Sonnet 4.6 e é rejeitado com HTTP 400 no Opus 5, Sonnet 5, Opus 4.7 e 4.8. Escrever isso hoje não é prompt ruim: é request quebrado.
Prefill. Aquela técnica de começar a resposta do assistant para forçar o formato ({"role": "assistant", "content": "{"}) também retorna 400 em toda a família 4.6+ e nos modelos 5. O que substituiu foi structured output de verdade: output_config.format com JSON Schema, e strict: true na definição da tool.
"Você é um especialista sênior com 20 anos de experiência." Persona teatral não melhora acurácia. O que melhora é descrever a tarefa, o domínio e o formato esperado.
Ameaça e CAPS LOCK. "CRITICAL!", "NEVER EVER", "isso é MUITO IMPORTANTE". A orientação da Anthropic é direta: linguagem agressiva produz resultado pior do que instrução calma e específica. O modelo não tem medo de você.

Tem um padrão aqui, e ele é o ponto do post: toda técnica de prompt que era truque de texto virou parâmetro de API ou virou treino do modelo. Na prática, o que antes você implorava em texto hoje você declara:

{
  "model": "claude-opus-5",
  "thinking": { "type": "adaptive" },
  "output_config": {
    "effort": "high",
    "format": {
      "type": "json_schema",
      "schema": { "type": "object", "properties": { "resumo": { "type": "string" } } }
    }
  },
  "messages": [{ "role": "user", "content": "..." }]
}

Raciocínio, profundidade e formato: três campos. Nenhuma frase mágica. O que sobra para o prompt é só o que a API não tem como saber — a sua tarefa, o seu domínio, o seu critério de aceite.

E é aí que a conversa muda de assunto. Prompt resolve a resposta única; o que ele não resolve é o sistema em volta — tool calling, roteamento, memória, grounding, tracing, evals e custo. É exatamente essa camada que a gente vai montar ao vivo, com código rodando, no AI Engineering Lab 3ª Edição, dia 19 e 20 de setembro, das 9h às 13h.

Por que prompt bom não salva contexto ruim

Agora o dado que quebra a ilusão.

A Chroma publicou em julho de 2025 o relatório Context Rot, de Kelly Hong, Anton Troynikov e Jeff Huber. Eles testaram 18 modelos de fronteira — GPT-4.1, Claude 4, Gemini 2.5, Qwen3 — variando só o tamanho do input. Resultado: todos degradam conforme o contexto cresce. Sem exceção. Em modelos de 1M de tokens, o efeito fica claramente observável entre 300 mil e 400 mil tokens.

Não é bug. É arquitetura. Como a Anthropic explica, o transformer cria relações par a par — n² para n tokens. Existe um "orçamento de atenção" finito. Dobrar a janela não dobra a atenção; dilui.

Traduzindo para uma dor que você já teve:

Você tem um agente de suporte. O prompt de sistema está impecável. Instrução clara, exemplos bons, formato definido, tom calibrado. E ele responde errado.

Não responde errado por falta de instrução. Responde errado porque, junto com o seu prompt perfeito, foram 40 mensagens de histórico e 12 chunks de RAG mal rankeados — e três desses chunks falam do produto errado com vocabulário parecidíssimo. O distrator está semanticamente mais perto da pergunta do que a resposta certa.

Nenhuma frase que você escrever no system prompt conserta isso.

A Anthropic define a disciplina que conserta como "o conjunto de estratégias para curar e manter o conjunto ótimo de tokens durante a inferência do LLM". Repara na palavra: curar. Não escrever. Curar. É trabalho de seleção, não de redação.

O que realmente entra na janela: ordem, corte, recência

Cada chamada é um orçamento. Você tem três decisões — e elas são independentes.

Ordem. Posição importa. O que está no meio de um bloco gigante compete com tudo em volta; o que abre e o que fecha o contexto tem peso desproporcional. Instrução no fim de 200 mil tokens de histórico não é instrução, é sugestão.

Corte. O que você não coloca vale mais que o que coloca. Cinco chunks bem rankeados batem vinte chunks "por garantia" — os quinze extras não são neutros, eles são ruído que disputa atenção com o sinal.

Recência. Histórico de conversa envelhece. Uma decisão tomada no turno 3 pode continuar valendo no turno 40; a saída de tool do turno 3 quase nunca continua. Por isso as APIs ganharam mecanismo nativo pra isso: context editing limpa resultados de tool antigos, compaction resume o histórico preservando decisão e descartando redundância.

Cada uma dessas três decisões tem critério próprio, tem trade-off e dá post inteiro. Eu escrevi um só sobre isso: Engenharia de contexto: o que vai no prompt (e o que NÃO vai) — lá está o detalhamento de cada tipo de conteúdo que disputa a janela.

E quando o histórico estoura mesmo assim, o sintoma é aquele clássico de "a IA esqueceu o que eu falei". Isso tem explicação mecânica e quatro saídas concretas, que destrinchei em Estourou o limite de tokens do ChatGPT: por que a IA esquece.

Aqui o ponto é outro, e é o ponto do hub: ordem, corte e recência não são prompt. São arquitetura.

▪ Clã Beer and Code

Não só acompanhe as novidades — domine. Engenharia de IA na prática, ao vivo, toda semana, na maior comunidade do Brasil.

Entrar no Clã

Prompt de sistema vs. instrução de turno

Tem um erro que aparece em quase todo projeto que eu reviso: enfiar tudo no prompt de sistema. Regra de negócio, exceção de cliente, formato de data, o nome do usuário, a data de hoje. Tudo lá.

E o erro oposto, menos comum e igualmente caro: repetir a mesma regra em todo turno, gastando token com algo que nunca muda.

A régua é simples.

Prompt de sistema é contrato estável. Papel, escopo, limites, formato de saída, o que fazer quando não souber. A Anthropic chama isso de encontrar a "altitude certa": nem lógica frágil hardcoded (que quebra no primeiro caso não previsto), nem vago demais (que não guia nada). Heurística forte, não árvore de decisão.

Instrução de turno é o que muda. A pergunta, os dados recuperados agora, o estado atual da tarefa.

Isso não é preciosismo — é dinheiro. O prompt caching funciona por prefixo, e a ordem de renderização é tools → system → messages. Um byte alterado no prefixo invalida tudo depois dele. Se você injeta datetime.now() no prompt de sistema, você paga input cheio em cada request e nem percebe. O jeito de descobrir é olhar usage.cache_read_input_tokens: se está zerado em requests repetidos, tem um invalidador silencioso no seu prefixo.

Detalhe novo que resolve um caso específico: nos modelos Opus 5 e Opus 4.8 dá pra mandar mensagem de sistema no meio da conversa, como {"role": "system"} dentro do array messages, em vez de editar o campo system do topo. Instrução de operador nova, prefixo cacheado intacto.

Do prompt à arquitetura: o que muda quando engenharia de prompt vira produto

Em demo, o prompt é o produto. Você mexe na frase, roda de novo, a saída melhora, você posta print no Twitter.

Em produção, o prompt é um arquivo de configuração cercado por coisas mais caras. Ele continua importando. Só não é mais onde você passa o tempo.

O que ocupa o lugar dele:

Recuperação com ranking avaliado. Não basta ter RAG. Tem que saber quantos chunks, com qual ranking, e medir se o chunk certo apareceu.
Roteamento. Nem toda pergunta merece o modelo caro no effort alto. Classificar a intenção antes é o corte de custo mais óbvio que quase ninguém faz.
Memória fora da janela. A própria Anthropic descreve o padrão: o agente escreve notas estruturadas persistidas fora do contexto e relê só o que precisa. Memória persistente com overhead mínimo.
Avaliação. Sem um conjunto de casos e uma métrica, "melhorou o prompt" é opinião. Com 50 casos versionados, é medida. Se quiser ver isso com número em cima, tem três experimentos da mesma tarefa medidos em tokens e dólar em Engenharia de contexto vence prompt engineering.
Observabilidade e custo. Tracing por request, tokens por rota, custo por tarefa concluída — não por chamada.

Isso é ferramental, e ferramental tem nome, API e preço. Já mapeei o que eu uso de verdade em Ferramentas de engenharia de contexto que eu uso em produção, com números e o que dá errado em cada uma.

O ponto de virada é esse: quando o sistema tem mais de um turno, mais de uma fonte e mais de uma ferramenta, a pergunta deixa de ser "como eu escrevo isso melhor" e vira "o que deveria estar nessa janela agora, e por quê".

FAQ

Então parei de estudar engenharia de prompt? Não. Você para de estudar truque e passa a estudar especificação. Instrução específica, critério de saída, exemplo bem escolhido — isso continua sendo o que separa saída utilizável de saída medíocre. O que morreu foi a coleção de macetes, não a habilidade de escrever uma tarefa com clareza.

Janela de 1M de tokens não resolve tudo? Não. O relatório da Chroma testou exatamente isso: 18 modelos, todos com degradação conforme o input cresce, e efeito claro em modelos de 1M lá pelos 300–400 mil tokens. Janela grande é orçamento, não licença para gastar.

Vale usar framework de prompt (DSPy, templates, prompt manager)? Vale quando você já tem eval. Framework otimiza o que você consegue medir. Sem conjunto de casos e métrica, ele só automatiza a sua intuição — mais rápido, e igualmente sem base.

Como eu sei se o meu problema é prompt ou é contexto? Teste barato: pegue o caso que falhou, monte a chamada à mão só com o prompt de sistema e o mínimo de contexto correto, e rode. Se acertar, o seu prompt está bom e o problema é o que a sua pipeline está enfiando na janela. Se errar, aí sim é redação.

Prompt engineering em português funciona igual? Funciona, com uma ressalva: instrução em português com dados em inglês (ou vice-versa) tende a produzir saída misturada. Fixe o idioma da saída no critério, não na esperança.

Conclusão

Engenharia de prompt não acabou por fracasso. Acabou por absorção.

As técnicas que valiam viraram parâmetro de API — effort, output_config.format, strict, adaptive thinking. As que não valiam viraram folclore de thread. E o problema difícil desceu uma camada: não é a frase, é o conjunto de tokens que chega ao modelo em cada chamada, com que ordem, com que corte e com que idade.

Isso não é hype. É engenharia. E é a parte que continua sendo trabalho humano, porque nenhuma API decide por você o que é relevante no seu domínio.

Se você quer continuar por aqui, o próximo passo natural é entender o critério de seleção com detalhe: Engenharia de contexto: o que vai no prompt (e o que NÃO vai).