Engenharia de Contexto vs Engenharia de Prompt: a mudança na forma como construímos sistemas de IA

Você recebe um pull request vindo de uma IA. O código parece limpo, segue o prompt e todos os testes unitários passam. Aí você percebe que ele usa uma biblioteca que o time descontinuou no último trimestre. E um padrão de design que viola o documento de arquitetura do serviço. O código parece certo, mas está completamente errado no contexto do seu sistema. Esse é o limite absoluto da engenharia de prompt. Todo o “debate entre engenharia de contexto vs. engenharia de prompt” se resume a um problema prático: nossas ferramentas de IA continuam nos entregando código que precisa de correções manuais cuidadosas.

Engenharia de prompt funciona bem para tarefas isoladas. Construir software não é uma sequência de tarefas isoladas. É uma cadeia de decisões limitada por código existente, hábitos do time e regras de negócio. O problema não é um prompt mal escrito. O problema é que o modelo não faz ideia do que está acontecendo fora da sua pequena janela. Fazer uma pergunta melhor não ajuda quando o modelo não consegue ver o resto da base de código.

Os custos da engenharia de prompt em escala

Usar engenharia de prompt para qualquer coisa maior cria um sistema frágil e de alta manutenção. Você entra em um loop de ficar ajustando prompts para preencher lacunas no conhecimento do modelo, e então tudo quebra quando o modelo recebe uma atualização ou o problema fica mais difícil.

Um pesadelo de manutenção

Quando um sistema de IA depende apenas do prompt, o sistema se torna difícil de manter e fácil de quebrar. Engenheiros escrevem prompts absurdamente complexos para conseguir o comportamento certo, e esses prompts viram uma bagunça impossível de manter, cheia de suposições sobre como o modelo “pensa”.

Isso falha de algumas formas. Uma pequena mudança no output significa que você precisa sair procurando qual prompt modificar, o que é ainda pior quando os prompts estão encadeados. Quando um provedor lança uma nova versão do modelo, seus prompts cuidadosamente ajustados podem quebrar. Uma instrução que funcionava perfeitamente ontem pode produzir um formato completamente diferente ou um erro lógico hoje. E quando algo falha, é difícil debugar. Você fica tentando adivinhar se o problema era o prompt ou a falta de contexto, porque não consegue reproduzir facilmente o estado exato em que o modelo estava.

Você só consegue otimizar um prompt até certo ponto

Existe um limite para o que você consegue só refinando um prompt de texto. Construir software exige consciência, não apenas uma boa instrução. Um prompt não tem como conter o grafo de dependências de um projeto, o raciocínio por trás de uma decisão arquitetural antiga ou como o time prefere lidar com operações assíncronas.

Você acaba com código que está tecnicamente correto, mas na prática é inútil. Tratamento de erro é um exemplo perfeito. Um modelo vai gerar blocos genéricos de `try/catch` porque não sabe nada sobre logging estruturado, tipos de erro ou padrões de métricas do sistema. O código funciona, mas está incompleto e não encaixa, o que significa que um desenvolvedor vai precisar corrigir. Sem consciência do sistema, a IA produz resultados imprevisíveis que fazem as pessoas perderem a confiança na ferramenta.

Engenharia de Contexto vs. Engenharia de Prompt: uma forma diferente de pensar

Precisamos parar de tentar enfiar tudo dentro do prompt. Devemos focar em projetar o ambiente em que o modelo trabalha, não só otimizar a instrução. Isso significa construir sistemas para fornecer ao modelo as informações específicas e explícitas que ele precisa para tomar decisões que realmente se encaixam.

Engenharia de contexto é o trabalho de projetar, construir e manter os sistemas que coletam, filtram e fornecem essas informações para o modelo.

Mais do que apenas um prompt

A interação com um LLM não deveria ser `prompt -> output`. Deveria ser `(contexto + prompt) -> output`. O prompt é só uma pequena parte de um pacote muito maior. Esse contexto operacional pode incluir dados, como código relevante de outros arquivos, schemas de banco de dados ou contratos de API. Também pode incluir ferramentas, que são funções que o modelo pode chamar para obter mais informações (como rodar um linter ou verificar permissões de usuário). Pode até incluir estado, como quais arquivos o usuário tem abertos ou quais comandos acabou de rodar.

Isso muda completamente o trabalho. Estamos arquitetando um ambiente de IA, não só escrevendo prompts. O trabalho real é decidir quais informações precisam ser fornecidas explicitamente e o que o modelo pode ser esperado saber. Um guia de estilo de código é contexto explícito. A sintaxe de Python é conhecimento implícito.

Engenharia de contexto é design de sistemas

Essa abordagem muda como construímos com IA. Em vez de ficar ajustando texto sem parar, passamos a construir componentes estruturados e previsíveis. Um engenheiro de contexto pensa no sistema inteiro, enquanto um engenheiro de prompt foca em uma única interação.

Um engenheiro de prompt tenta melhorar uma resposta. Ele pode mudar um prompt de “escreva uma função que faz X” para “atuando como um engenheiro de software sênior, escreva uma função pura que faz X, siga princípios de programação funcional e inclua testes baseados em propriedades.” Isso pode te dar uma resposta melhor naquele caso específico.

Um engenheiro de contexto quer tornar o sistema inteiro mais consistente e confiável. Ele constrói a infraestrutura que encontra automaticamente os princípios de programação funcional do time na wiki, pega exemplos de testes baseados em propriedades já existentes no código e fornece tudo isso como contexto. O prompt pode continuar simples. O sistema fica mais confiável porque as decisões do modelo passam a se basear em dados reais do projeto.

A inteligência real não está no modelo. Está no sistema que alimenta ele. Construir produtos de IA que sejam sustentáveis depende disso.

Princípios para construir com engenharia de contexto

Isso exige uma forma mais disciplinada de passar informação para os modelos. Parece muito com design de sistemas, o que é um bom sinal.

Projete seu sistema para entregar contexto

O primeiro passo é tratar contexto como uma parte central da arquitetura do sistema. O código que busca o schema do banco de dados não deveria estar misturado com o código que formata o prompt. Você deve criar módulos ou serviços separados que apenas fornecem partes específicas de contexto. Isso torna o sistema muito mais fácil de testar e manter.

Sempre que possível, forneça contexto como JSON ou YAML, não só como um bloco grande de texto. Isso ajuda o modelo a interpretar a informação de forma mais confiável. Por exemplo, forneça o guia de estilo como um objeto JSON de regras de lint, em vez de colar o texto bruto.

Você também precisa de versionamento para o seu contexto. Schemas de API mudam, documentos são atualizados. Seu sistema deve conseguir apontar para versões específicas dessas fontes. Essa é a única forma de reproduzir com confiabilidade uma geração passada para debug.

Pensando em camadas de contexto

Ajuda pensar no contexto como uma pilha de camadas. Cada camada fornece um tipo diferente de informação. Isso ajuda a priorizar e filtrar o que você envia para o modelo, o que é importante para ficar dentro do limite de tokens e evitar ruído.

Uma pilha de contexto para uma tarefa de código poderia ser assim:

• Camada 0 (Global): O conhecimento embutido do modelo sobre uma linguagem de programação.
• Camada 1 (Organização): Padrões de engenharia da empresa ou bibliotecas preferidas.
• Camada 2 (Projeto): Padrões de arquitetura desse projeto, regras de lint e lista de dependências.
• Camada 3 (Local): O conteúdo do arquivo atual e de outros arquivos relacionados que o usuário tem abertos.
• Camada 4 (Dinâmico): Feedback em tempo real de um compilador ou executor de testes.

Um loop de feedback já está embutido nessa ideia. Se o modelo gerar código que falha em um lint, essa falha vira contexto dinâmico para a próxima tentativa. O sistema consegue se autocorrigir usando feedback imediato e factual.

Aplicando engenharia de contexto na prática

Para fazer isso funcionar, você precisa construir a infraestrutura para gerenciar contexto como código.

Gerenciando contexto com código

Ferramentas de orquestração podem ajudar, mas um conjunto de funções bem definidas ou microserviços também funciona. O ponto é ter uma forma programável de montar e fornecer contexto. Um orquestrador pode chamar diferentes provedores de contexto dependendo da requisição do usuário, montar o pacote final de informação e enviar para o modelo.

Você também precisa validar e monitorar seu contexto. Antes de enviar informação para o modelo, verifique. O schema da API faz parse? O caminho do arquivo existe? Fique de olho na qualidade das suas fontes de contexto. Contexto desatualizado ou errado é pior do que nenhum contexto.

Por fim, o sistema precisa adaptar o contexto à tarefa. Um pedido para refatorar uma função precisa de informações diferentes de um pedido para escrever uma nova migration de banco de dados. Seu código precisa ser inteligente o suficiente para buscar o contexto certo para cada tipo de trabalho.

Um checklist para construir com contexto

Quando você estiver desenhando uma nova feature de IA, faça essas perguntas:

• Quais informações são necessárias? Identifique cada pedaço de informação que o modelo precisa para tomar uma boa decisão (código fonte, docs, schemas, histórico do git, padrões do time).
• Qual é o escopo? Para uma tarefa específica, qual é o limite do contexto? O arquivo atual, o pacote, o repositório inteiro? Como você define isso em código?
• Como sabemos que o contexto é bom? Como você garante que o contexto está correto e atualizado? Qual é o fallback se uma fonte estiver indisponível?
• Como ele se mantém atualizado? Quando e como o contexto é atualizado? A cada requisição, em um intervalo de tempo, ou após um evento como um commit no git?
• Conseguimos debugar? Você está registrando exatamente qual contexto versionado foi enviado para o modelo junto com o prompt? Consegue reproduzir perfeitamente uma geração antiga

Responder essas perguntas muda o trabalho de tentar adivinhar as palavras mágicas de um prompt para construir um sistema de software confiável e fácil de debugar. Pequenas melhorias em um prompt geram pequenas melhorias no output. Melhorar o contexto muda a confiabilidade do sistema inteiro.