Context Engineering: A Habilidade que Substituiu o Prompt Engineering em 2026

Andrej Karpathy disse claramente: «Prompt engineering» é um termo enganoso. Implica que a arte de trabalhar com modelos de linguagem consiste em redigir instruções com cuidado — escrever a frase mágica que desbloqueia o resultado correto. Esse enquadramento sempre subestimou o trabalho real, e em 2026 não descreve mais o que equipes de IA sérias estão realmente fazendo.

O que estão fazendo é context engineering: a prática deliberada e sistemática de construir a informação certa no momento certo no formato certo para ocupar a janela de contexto de um LLM durante a inferência. É parte recuperação, parte gerenciamento de memória, parte design de sistemas e parte UX. Não é um prompt. E equipes que o tratam assim estão deixando a maior parte da capacidade do modelo sem aproveitar.

Por que «Prompt Engineering» Sempre Foi o Enquadramento Errado

A frase «prompt engineering» veio das intuições da era GPT-3: modelos eram opacos, a formulação certa desbloqueava capacidades ocultas, e a habilidade era essencialmente encantação. O modelo funcionava se você escrevesse o encantamento corretamente.

Esse modelo mental quebrou por três razões:

1. Janelas de contexto se expandiram. Quando modelos tinham 4K tokens, prompts eram curtos. Com 128K, 200K e 1M+ tokens, o que você coloca na janela é um problema de design de sistemas, não de escrita.
2. Sistemas se tornaram dinâmicos. Aplicações modernas de IA não usam um prompt estático. Elas recuperam documentos, chamam ferramentas, mantêm memória entre sessões e processam resultados intermediários.
3. O sinal se moveu. Empiricamente, as maiores lacunas de desempenho entre equipes vêm da qualidade do contexto, não da redação do prompt.

As Seis Camadas do Contexto

Context engineering significa pensar deliberadamente sobre seis componentes distintos que podem ocupar a janela de contexto de um modelo durante a inferência:

• Camada 1 — System prompt e instruções. Definição de papel, restrições de tarefas, especificação de formato de saída, esquemas de ferramentas. Fixo e relativamente pequeno — tipicamente 5–10% do orçamento.
• Camada 2 — Exemplos few-shot. Demonstrações de entrada/saída que ancoram formato, tom e tratamento de casos extremos. Bons few-shots fazem trabalho mais confiável que parágrafos de instruções elaboradas.
• Camada 3 — Memória de trabalho / Estado. O rascunho do agente: raciocínio intermediário, progresso da tarefa, esquema de saída estruturada. Esta camada cresce durante uma tarefa.
• Camada 4 — Documentos recuperados (RAG). Conhecimento externo obtido em tempo de inferência: resultados de busca vetorial, consultas de banco de dados, trechos de código base, dados em tempo real.
• Camada 5 — Resultados de ferramentas e ações. A saída de chamadas de API, execução de código, busca e outras invocações de ferramentas. Frequentemente verbosas, precisam de truncamento ou resumo.
• Camada 6 — Histórico de conversa. Turnos anteriores, memória resumida e preferências de usuário persistidas. Conversas longas requerem estratégias de compressão.

O insight chave: um «prompt» é a camada 1 na melhor das hipóteses. Context engineering é a prática de gerenciar todas as seis camadas simultaneamente dentro de um orçamento de tokens finito.

Qualidade do Contexto Supera Tamanho do Modelo

O achado mais praticamente importante na literatura de context engineering é também o mais contraintuitivo: um modelo menor com contexto bem projetado supera rotineiramente um modelo maior com contexto deficiente.

Isso foi demonstrado em múltiplos benchmarks. Em tarefas de geração de código, GPT-4o com few-shots cuidadosamente curados e contexto relevante de base de código supera o3 com um system prompt genérico. Em implantações RAG empresariais, mudar de recuperação naiva de documentos completos para chunking semântico com re-ranking produz ganhos de precisão maiores do que atualizar o modelo.

«Passamos três meses testando diferentes modelos. Um sprint em qualidade de contexto nos deu os mesmos ganhos que estávamos perseguindo por um trimestre.» — Desenvolvedor no Hacker News

O Orçamento de Contexto: Tratando Tokens como Recurso Finito

A mudança de modelo mental mais útil no context engineering é tratar tokens como um orçamento. A janela de contexto é um recurso escasso. Tudo que entra desloca algo mais.

Técnicas de gestão de orçamento que aparecem repetidamente em sistemas de produção:

Recuperação em camadas

Não recuperar documentos completos. Usar um pipeline de duas etapas: um modelo de recuperação rápido e barato seleciona candidatos; um re-ranker de codificação cruzada seleciona as passagens de maior relevância.

Resumo progressivo

Histórico de conversa e estado intermediário crescem sem limites se não forem gerenciados. O padrão de produção é resumir após um limite — tipicamente após cada N turnos ou quando o histórico excede X tokens.

Few-shots dinâmicos

Se você tem uma biblioteca de 200 exemplos, recupere os 3–5 mais semanticamente similares ao input atual. Esta técnica é uma das otimizações de contexto de maior ROI.

O Problema da Qualidade do Retrieval

Erros nos limites dos chunks

O chunking de tamanho fixo frequentemente divide passagens semanticamente coerentes entre chunks, retornando meia-respostas. O chunking consciente de documento supera consistentemente o chunking de tamanho fixo.

Contexto faltante para chunks recuperados

A técnica «Contextual Retrieval» da Anthropic antepõe um resumo de contexto específico do chunk a cada chunk no momento da indexação. Em seus benchmarks, isso reduziu falhas de retrieval em 49% combinado com re-ranking.

Desajuste consulta-documento

HyDE (Hypothetical Document Embeddings) aborda isso gerando uma resposta hipotética à consulta e incorporando isso, em vez de incorporar a consulta bruta.

O que Construir Primeiro

1. Auditar o pipeline de retrieval. Mudar de chunks de tamanho fixo para chunks semânticos ou conscientes de documento. Adicionar um passo de re-ranking.
2. Implementar resumo de conversa. Limitar o histórico de conversa a um limite de tokens e resumir quando for excedido.
3. Adicionar recuperação dinâmica de few-shots. Construir uma pequena biblioteca de exemplos de alta qualidade. Recuperar os top-3 mais similares ao input atual.
4. Externalizar o estado do agente. Para sistemas multi-agente, mover o estado intermediário para stores externos estruturados desde o início.
5. Instrumentar a qualidade do contexto. Adicionar logging para janelas de contexto e resultados.

O Ponto Mais Profundo

Context engineering não é uma técnica. É uma mudança de perspectiva: de tratar modelos de linguagem como geradores de texto que respondem a instruções, para tratá-los como motores de inferência cujo desempenho é limitado pela qualidade das informações fornecidas em tempo de execução.

A lacuna entre o que as equipes estão alcançando e o que é possível é quase sempre uma lacuna de contexto. Essa lacuna é um problema de engenharia. E como todos os problemas de engenharia, responde ao investimento sistemático.

O feitiço nunca foram as palavras. Sempre foi a informação por trás delas.