Context Engineering

title: "Context Engineering" part: 1 chapter: 2 free: true

Context Engineering é a habilidade de montar e estruturar informações para que a IA produza o resultado certo — na primeira tentativa.

Por que contexto é tudo

Um modelo de linguagem não tem memória entre conversas. Cada prompt é um universo isolado. A qualidade da resposta é proporcional à qualidade do contexto fornecido.

Dar à IA um prompt vago é como contratar um desenvolvedor sênior e não explicar o projeto, a stack, os requisitos e as restrições. Ele vai fazer algo — mas provavelmente não o que você precisava.

Os cinco elementos do contexto

1. Papel (Role)

Quem você quer que a IA seja? Um arquiteto de software? Um revisor de código? Um QA? Definir o papel ativa padrões de resposta específicos.

Você é um engenheiro de backend sênior especializado em Node.js e PostgreSQL.

2. Objetivo (Task)

O que você quer que seja feito — com precisão cirúrgica. Verbos de ação + escopo definido.

Refatore a função abaixo para usar async/await em vez de callbacks.

3. Contexto do código (Code Context)

Arquivos relevantes, interfaces existentes, dependências já instaladas. Não cole código desnecessário — cole o que a IA precisa para tomar decisões corretas.

4. Restrições (Constraints)

O que não pode mudar. A stack, convenções do projeto, limites de complexidade.

Mantenha a interface pública da função idêntica. Não adicione dependências novas.

5. Formato esperado (Output Format)

Como você quer a resposta: código puro, explicação + código, diff, lista de passos.

Context Window vs. Contexto Efetivo

Modelos modernos têm context windows de 128k a 1M tokens. Isso não significa que você deve jogar tudo dentro.

Contexto efetivo é o subconjunto de informações que realmente influencia a resposta. Ruído no contexto dilui a atenção do modelo e piora os resultados.

A regra prática: menos é mais, desde que seja o certo.

CLAUDE.md — contexto persistente

Em projetos com Claude Code, o arquivo CLAUDE.md na raiz do repositório é carregado automaticamente em cada sessão. É onde você define:

• Stack e convenções do projeto
• Decisões arquiteturais importantes
• O que não fazer (gotchas, anti-patterns do projeto)
• Comandos úteis

É o equivalente a um onboarding que o dev (IA) lê antes de começar a trabalhar.