Um buzzword em retirada
Em 2023, de repente todo mundo tinha um novo cargo no LinkedIn: prompt engineer. Havia cursos de 2.000 dólares, „prompt libraries" vendidos como produtos SaaS e vagas anunciando salários acima de 200.000 dólares. A narrativa: quem encontrasse as palavras certas para um modelo teria uma vantagem competitiva decisiva.
Três anos depois, sobrou pouco desse hype. Não porque o problema de base desapareceu – mas porque ficou claro que a escolha das palavras era só uma parte minúscula do trabalho. A alavanca real está em outro lugar.
O que prompt engineering acertou
Seria injusto descartar prompt engineering em retrospecto. O termo popularizou uma ideia importante: LLMs não são mecanismos de busca, são sistemas de linguagem que respondem a contexto. A forma como você formula uma pergunta afeta dramaticamente a resposta. Few-shot examples, instruções claras, descrições de tarefas estruturadas – tudo isso virou parte do kit padrão de qualquer desenvolvimento sério com IA.
O problema não foi a ideia. O problema foi reduzir a disciplina inteira a um único bloco de texto – como se o trabalho consistisse em polir três frases num campo de input. Aplicações reais não funcionam assim. Elas têm system prompts, ferramentas, dados recuperados, histórico de conversa, formatos de output estruturados, estratégias de cache e caminhos de escalonamento. O „prompt" é talvez dez por cento disso.
O que context engineering significa de fato
Context engineering é o termo mais amplo para o que realmente acontece quando você coloca um LLM em produção. Cobre tudo que entra na janela de contexto antes do modelo responder:
System prompt: O papel, as regras, o guia de estilo. Raramente é a alavanca que decide sucesso ou fracasso, mas é a base sobre a qual o resto se apoia.
Retrieval: Quais documentos, datasets ou trechos de código são puxados de fontes internas antes do modelo responder. A qualidade desse passo importa mais, na maioria das aplicações, do que qualquer ajuste de prompt.
Ferramentas: Quais funções o modelo pode chamar – queries de banco, chamadas de API, cálculos, buscas. A ferramenta certa no momento certo substitui páginas de instruções no prompt.
Estado da conversa: O que é carregado de turnos anteriores, o que é resumido, o que é descartado. Em sessões longas, muitas vezes o fator decisivo de consistência.
Schema de output: Respostas em JSON estruturado em vez de prosa livre. Economiza parsing, reduz erros, deixa pipelines robustos.
Memória: Informação persistente entre sessões – preferências do usuário, decisões anteriores, contexto específico do projeto. Hoje é um subsistema próprio, não faz mais parte do prompt.
Quando alguém fala em „prompt engineering" hoje, geralmente está se referindo a uma dessas áreas – ou misturando elas. Context engineering separa tudo de forma limpa.
Onde está a alavanca real
Na nossa prática, a ordem de prioridade é clara: dados melhores ganham de palavras melhores. Em concreto:
Retrieval melhor > redação melhor. Um sistema RAG que recupera os três documentos certos vai gerar respostas melhores com um prompt mediano do que um prompt perfeitamente redigido com as fontes erradas. Já vimos várias vezes dias inteiros gastos em prompt tuning quando o problema real era um vector store mal configurado.
Ferramentas certas > instruções inteligentes. Se um agente precisa fazer aritmética, dê uma calculadora. Se precisa de dados atuais, dê uma chamada de API. Mil palavras de prompt tentando convencer o modelo a fazer matemática direito podem ser substituídas por uma definição de ferramenta de dez linhas – e o resultado é mais confiável.
Output estruturado > parsear prosa. „Responda no seguinte formato JSON" é uma gambiarra. Schemas de output forçados via API são o padrão. Se você ainda roda expressões regulares em cima de output de LLM em produção, tem um problema de arquitetura, não de prompt.
Estratégia de eviction > entupir a janela. Mesmo com um milhão de tokens, você precisa decidir o que entra. Resumir turnos antigos, descartar outputs irrelevantes de ferramentas, carregar memória de forma seletiva. Quem joga tudo dentro tem resultados piores, custos mais altos e respostas mais lentas.
Por que janelas de contexto longas não mataram a disciplina
Em 2024, muita gente achou que o problema ia se resolver sozinho. Se um modelo aguenta um milhão de tokens, é só jogar o wiki inteiro da empresa lá e pronto. Isso se mostrou uma falácia.
Primeiro, modelos sofrem com problemas de atenção em contexto cheio – informação relevante perdida no meio de 800.000 tokens muitas vezes não é encontrada de forma confiável. Segundo, custo e latência explodem. Terceiro, o efeito „lost in the middle" está empiricamente documentado: o que fica entre o começo e o fim recebe sistematicamente menos peso.
Contextos longos não acabaram com context engineering, eles deslocaram a disciplina. Em vez de „como fazer tudo caber?", a pergunta agora é „o que vai onde, para o modelo conseguir usar?". Isso é mais trabalho, não menos.
Erros comuns
Dos nossos projetos, padrões emergem que dão errado de novo e de novo:
Contexto entupido: Times jogam tudo que pode ser relevante, por garantia. O modelo fica mais lento, mais caro e menos preciso. Menos é quase sempre mais.
Sem estratégia de eviction: Em sessões longas, o contexto cresce sem controle até bater no limite. Aí algo é descartado de forma aleatória – geralmente a coisa errada. Quem não cuida ativamente da eviction entrega essa decisão pro acaso.
Papéis misturados: System prompt, input do usuário e outputs de ferramentas são jogados num único bloco de texto em vez de separar os papéis com clareza. Modelos são sensíveis a isso – e brechas de segurança como prompt injection ficam muito mais difíceis de evitar.
Retrieval estático: Uma busca vetorial única no começo da conversa e nada depois. Em tarefas complexas, a necessidade de informação muda – retrieval precisa ser dinâmico e em múltiplas etapas.
Sem log do contexto: Quando um output dá errado e ninguém sabe o que estava de fato na janela de contexto, debugar é impossível. Logar o contexto completo não é opcional, é pré-requisito para sistemas estáveis.
O que os times precisam agora
As skills que fazem diferença hoje não são bruxaria de prompt. São disciplinas clássicas de engenharia aplicadas a uma stack nova:
Information retrieval: Entendimento sólido de modelos de embedding, estratégias de busca híbrida, reranking, tamanhos de chunk. Menos glamouroso que ajustar prompt, mas com mais impacto.
Design de API: Definições de ferramenta são APIs para modelos. Quem já desenhou REST APIs limpas sai na frente.
Modelagem de dados: Schemas de output, inputs estruturados, definições em Pydantic ou Zod. Trabalho clássico de backend.
Observability: Logging, tracing, pipelines de avaliação. Sem isso, nenhum sistema de contexto é melhorado em produção.
Na nh labs, paramos de contratar „prompt engineers" desde meados de 2025 – não porque o trabalho sumiu, mas porque virou um aspecto da engenharia de software. Os melhores resultados vêm de devs que sabem construir sistemas limpos, não de redatores com experiência em ChatGPT.
Conclusão
Prompt engineering não está desaparecendo – está encolhendo para o tamanho real dele. É uma ferramenta na caixa, não uma carreira independente. O que permanece, e ganha importância, é a capacidade de moldar deliberadamente toda a janela de contexto: o que entra, em que forma, em que ordem, com quais ferramentas, em qual schema. Quem domina isso constrói sistemas de IA confiáveis. Quem ainda fica polindo prompts otimiza o último por cento enquanto ignora os primeiros noventa. O termo context engineering não vai durar para sempre – a disciplina por trás dele vai.