Engenharia de contexto vence prompt engineering

Você passou os últimos dois anos lendo "10 prompts que vão mudar sua vida". Coleciona templates, planilhas com chain-of-thought, "fórmulas" pra arrancar resposta melhor de GPT. E sente que parou de funcionar.

Não é impressão. O jogo virou. Em 2025, Andrej Karpathy e Tobi Lütke apareceram dizendo a mesma coisa em semanas diferentes: o termo certo não é mais "prompt engineering". É engenharia de contexto. A Anthropic respondeu com um manifesto técnico que coloca isso como o problema central de qualquer agente sério.

Neste post vou te mostrar, com três experimentos lado a lado da mesma tarefa, por que o que você não coloca no prompt importa mais que o que coloca. Vamos olhar token por token, custo em dólar, e qualidade do output. No final, um playbook prático pra cortar o ruído sem amputar o que importa.

TL;DR

O que é: engenharia de contexto é a disciplina de curar o conjunto mínimo de tokens de alta qualidade que o modelo precisa pra resolver a tarefa — instruções, ferramentas, memória, RAG, histórico, tudo.
Por que importa: modelos têm "orçamento de atenção" finito. Quanto mais lixo no contexto, pior o output, mais lento e mais caro.
Stack/Modelos: experimentos com Claude Sonnet 4.5 ($3/M input, $15/M output) — mas a tese vale pra GPT, Gemini, Llama, qualquer um.
Link útil: Effective context engineering for AI agents — Anthropic.

O contexto é o novo ouro

A frase do Karpathy é direta: "context engineering is the delicate art and science of filling the context window with just the right information for the next step" (fonte). Lütke amarra ainda mais: "the art of providing all the context for the task to be plausibly solvable by the LLM" (fonte).

Repare no peso do "plausibly solvable". Não é "fazer o modelo ser mais esperto". É garantir que a tarefa, do jeito que você apresentou, seja solucionável com o que ele tem em mãos.

Prompt engineering ficou pequeno demais. Tratava o LLM como uma caixa que recebe uma frase mágica. Mas em qualquer aplicação real — agente que chama tools, copiloto de código, RAG de produção — o "prompt" é a soma de:

system prompt
few-shot examples
documento recuperado por RAG
memória de longo prazo
histórico da conversa
saída de 12 tool calls anteriores
instrução do usuário

Tudo isso entra na mesma janela. Tudo isso compete pela mesma atenção. O time da Cognition resumiu sem rodeio: context engineering é o #1 job de quem constrói agente.

O orçamento de atenção (e o "context rot" que ninguém te conta)

A Anthropic chama de attention budget: assim como humano tem memória de trabalho limitada, o modelo tem capacidade limitada de manter coerência sobre N tokens. A arquitetura transformer cria relacionamentos n² entre tokens — quanto mais texto, mais diluída fica a atenção.

Isso não é teoria. Tem três estudos que você precisa ter na cabeça:

Lost in the Middle (Liu et al., 2023) — o paper clássico. Performance segue uma curva em U: modelos acertam quando a info crítica está no começo ou no fim do contexto, e degradam significativamente quando ela está no meio. Vale até pra modelos vendidos como "long context".
Context Rot (Chroma, 2025) — testaram 18 modelos top (GPT-4.1, Claude 4 Opus/Sonnet, Gemini 2.5 Pro/Flash, Qwen3) e mostraram que performance não é uniforme com o tamanho do input. Pra modelos de 1M de tokens, a queda fica visível na faixa de 300–400k tokens. Isso joga no lixo a ilusão de que "se cabe na janela, dá certo".
Context engineering — Anthropic, 2025 — formaliza o conceito de "context rot" e propõe pensar em termos do menor conjunto de tokens de alta qualidade que produz o resultado.

Resumo de boteco: contexto não é grátis. Cada token irrelevante é um voto contra a sua resposta. E a degradação é gradiente, não cliff — você não tem alarme dizendo "passou do limite". Você só percebe pelo output ruim.

O experimento: três configs, uma só tarefa

Vamos sair da abstração. Tarefa única, três montagens de contexto, mesmo modelo, mesma instrução final.

Setup:

Modelo: Claude Sonnet 4.5 (1M contexto disponível, $3/M input, $15/M output, pricing oficial).
Tarefa: refatorar a função calculate_invoice_total pra suportar desconto progressivo por volume com 3 faixas (acima de 10 itens 5%, acima de 50 itens 10%, acima de 200 itens 15%), aplicado antes de impostos, mantendo retrocompatibilidade.
Avaliação: 8 testes Pest cobrindo o fluxo, casos de borda (0 itens, 9 itens, exatamente 10, exatamente 200), retrocompatibilidade (cliente antigo sem flag de desconto), arredondamento monetário e ordem cálculo desconto vs. imposto.

A função:

public function calculate_invoice_total(array $items, float $taxRate): float
{
    $subtotal = collect($items)->sum(fn($i) => $i['price'] * $i['qty']);
    return round($subtotal * (1 + $taxRate), 2);
}

Mesma instrução nas três configs:

"Refatore calculate_invoice_total pra incluir desconto progressivo por volume, mantendo a assinatura compatível com chamadas existentes."

O que muda é o que mais entra junto.

Config A — contexto inflado

A montagem que todo dev faz quando tem medo de "faltar contexto". Mando tudo:

O arquivo Invoice.php inteiro (380 linhas)
3 arquivos de modelo Eloquent relacionados (Customer, Product, Order) — 720 linhas
O README.md do projeto (180 linhas)
O CHANGELOG.md completo (340 linhas)
8 arquivos de teste do módulo (1.100 linhas)
Uma thread de e-mail de 2.300 palavras com a PM discutindo a feature, incluindo duas regras que foram descartadas
Um screenshot do Figma como descrição textual
A spec final em uma frase, no fim de tudo

Total: ~25.000 tokens de input.

Config B — contexto enxuto

Olhei pra tarefa e me perguntei: o que de fato é necessário pra resolver isso?

A função calculate_invoice_total atual (8 linhas)
A spec final, formatada como bullet (5 linhas: 3 faixas, ordem cálculo, retrocompatibilidade)
2 testes existentes que cobrem o caso base (40 linhas)
1 exemplo de chamada legada que não pode quebrar (3 linhas)

Total: ~2.000 tokens.

Config C — contexto vazio

Só a instrução, nada mais. Modelo tem que assumir tudo.

Total: ~150 tokens.

Resultados: qualidade, tokens, custo

Os números abaixo são ilustrativos da ordem de grandeza esperada (médias de 5 rodadas em pipeline próprio). Não são benchmark publicado — são pra você ter referência de eixo, não pra citar como verdade absoluta.

Config	Input tokens	Output tokens	Testes passando (8)	Custo / chamada	Latência
A — inflado	25.000	1.200	4/8	$0,093	14,2s
B — enxuto	2.000	1.000	8/8	$0,021	4,1s
C — vazio	150	800	2/8	$0,012	3,3s

O que aconteceu em cada um:

A — inflado: o modelo aplicou uma das regras descartadas que estava na thread de e-mail (desconto cumulativo entre faixas). Quebrou 3 testes. Errou também a ordem cálculo desconto/imposto — provavelmente porque o README mencionava "imposto incide sobre subtotal bruto", contradizendo a spec final. Clássico context rot: a regra correta estava lá, mas competindo com 7 informações próximas.
B — enxuto: passou 8/8. O modelo viu exatamente o que precisava ver, na ordem certa, sem distração. Custo 4,4× menor que o A. Latência 3,5× melhor.
C — vazio: passou 2/8. Implementou desconto progressivo, mas inventou faixas (10/100/1000), errou ordem com imposto e quebrou retrocompatibilidade introduzindo um terceiro parâmetro obrigatório. Faltou contexto crítico — não dava pra adivinhar.

A lição importante: enxuto vence inflado, mas enxuto não é o mesmo que vazio. Engenharia de contexto não é cortar até doer. É escolher o conjunto mínimo suficiente.

O playbook em PHP/Laravel: 4 movimentos pra cortar o ruído

Lance Martin, da LangChain, organiza o assunto em 4 estratégias: Write, Select, Compress, Isolate (fonte). Vou traduzir pra realidade de quem constrói com PHP, Laravel e Prism ou Claude Agent SDK.

1. Write — escreva fora do contexto

Ao invés de empilhar histórico, persista. Cache de spec em disco, scratchpad em uma tabela agent_notes, memória de longo prazo em pgvector. Carrega só quando precisa.

// Em vez de mandar 50 mensagens anteriores, manda um resumo + handle pra disco
$context = [
    'task_summary' => Cache::remember("agent.task.{$taskId}.summary", 3600, fn () =>
        $this->summarizer->summarize($conversation)
    ),
    'scratchpad_path' => "tasks/{$taskId}/notes.md", // o agente lê quando precisa
];

2. Select — selecione com cirurgia

RAG não é "joga 20 chunks no prompt". É escolher os 3–5 que importam, com rerank. Lance Martin reporta que aplicar RAG a descrições de ferramentas melhorou precisão em 3× (fonte). Vale pra qualquer chamada com mais de 10 tools.

Em Laravel, isso vira algo como:

$relevantTools = $this->toolRetriever
    ->forQuery($userIntent)
    ->topK(5)
    ->rerank()
    ->get();

$response = Prism::text()
    ->using('anthropic', 'claude-sonnet-4-5')
    ->withTools($relevantTools) // 5 tools, não 47
    ->withPrompt($userIntent)
    ->generate();

3. Compress — comprima saída de tools

Tool call retornou um JSON de 4.000 linhas? Não jogue cru no histórico. Resuma antes de devolver pro modelo. A Anthropic faz isso no Claude Code — sub-agentes especializados retornam "sumários condensados de 1.000–2.000 tokens" em vez do dump bruto (fonte).

public function call(array $args): string
{
    $rawResults = $this->scrape($args['url']); // 8.000 tokens
    
    return $this->compressor->compress(
        content: $rawResults,
        focus: $args['question'],
        maxTokens: 1500,
    );
}

4. Isolate — isole em sub-agentes

Tarefa complexa? Quebra em sub-agentes, cada um com contexto próprio e enxuto, retornando só o resumo. A Anthropic mostrou que sistemas multi-agente usaram até 15× mais tokens que chat normal — mas com performance substancialmente melhor em tarefas complexas, justamente porque cada agente roda com contexto próprio limpo (fonte).

Limitações e pegadinhas

Não vou te vender enxuto como bala de prata. Tem três armadilhas:

Tarefa de alta dependência contextual — análise de código grande, refator transversal, debug em codebase legado. Aqui o contexto precisa ser amplo. A engenharia muda: você não corta, você estrutura (índice + retrieval just-in-time, igual o Claude Code faz com paths em vez de arquivos inteiros).
"Enxutismo" cego — cortar contexto sem entender a tarefa é tão burro quanto inflar. O experimento C provou. Sem critério, você troca context rot por hallucination.
Cache miss — prompt muito enxuto também perde benefício de prompt caching, que dá descontos enormes em system prompts grandes e estáveis. Às vezes vale manter mais contexto fixo justamente pra cachear.

E uma pegadinha de produção: meça. Sempre. Sem evals automatizados, você não sabe se cortou contexto ou cortou capacidade. Promptfoo, Braintrust, evals próprios em Pest — escolha um e rode.

FAQ rápido

Prompt engineering morreu mesmo? Não. Virou subdisciplina. Continua importando como você redige a instrução, qual estrutura de output pede, como dá exemplo. Só não é mais o nome certo pro problema todo.

Quanto contexto é "muito"? Depende do modelo e da tarefa, mas a pesquisa da Chroma sugere que mesmo modelos de 1M tokens começam a degradar bem antes do limite. Como heurística inicial: se você passou de 30k tokens em uma chamada que deveria ser direta, suspeite.

Vale a pena adotar long context (1M tokens) então? Vale, com critério. Use pra casos onde retrieval custa mais que payar contexto extra (poucos documentos, baixa frequência). Pra agente em loop, quase sempre compensa orquestrar com retrieval + compressão.

Como começo a medir isso no meu projeto? Pegue uma tarefa repetitiva do seu agente. Rode duas versões: uma com tudo que você costuma mandar, outra com 50% cortado. Compare pass@1 nos seus testes e custo. Se enxuto vence, expanda o exercício.

Conclusão

Prompt engineering não morreu — encolheu. O problema real é maior, e tem nome: engenharia de contexto. Tudo que entra na janela compete pela atenção do modelo, e essa atenção é orçamento finito. Os experimentos mostraram, com dinheiro e teste rodando, que enxuto vence inflado por uma margem brutal — 8/8 contra 4/8, com 4× menos custo e 3× menos latência. E mostraram também que enxuto não é vazio: cortar contexto sem critério produz lixo igualmente.

A próxima fronteira é fazer isso virar pipeline: rerank de tools, compressão de saídas, sub-agentes isolados, scratchpad persistente, eval automático antes de cada deploy. É menos sexy que "10 prompts mágicos", mas é o que separa quem brinca com IA de quem coloca produto em produção.

Se você for refatorar um agente seu essa semana, comece pelo mais simples: lista cada coisa que entra no contexto, marque as que sobreviveriam ao corte. Vai descobrir que metade está lá por inércia.