Engenharia de Contexto É a Nova Engenharia de Prompt

Por um tempo, "engenharia de prompt" foi tratada como a habilidade inteira. Formular bem a instrução, adicionar algumas palavras mágicas, e o modelo fazia a coisa certa. Essa forma de pensar fazia sentido quando a unidade de interação era uma única mensagem. Ela quebra completamente quando o que você está usando é um agente que lê uma base de código, chama ferramentas e age em vários passos.

O prompt nunca foi o gargalo

Peça a um agente para "corrigir o bug no fluxo de checkout" e a instrução em si é quase a parte fácil. A parte difícil é tudo que precisa acontecer antes de o modelo conseguir agir sobre isso de forma sensata:

  • Quais arquivos são realmente relevantes, entre milhares.
  • Se o agente tem o contexto certo ao redor — tipos, pontos de chamada, mudanças recentes — ou só o arquivo único que por acaso você colou.
  • Se informação desatualizada (um comentário antigo, uma função obsoleta ainda no escopo) está silenciosamente competindo com o estado correto e atual do código.
  • Quanto da janela de contexto está sendo gasto em ruído versus sinal.

Nada disso é um problema de redação. É um problema de recuperação e curadoria, e isso determina o teto do que o agente consegue fazer muito mais do que a formulação do pedido.

Contexto é um orçamento, não um recurso livre

Uma janela de contexto grande não faz isso desaparecer — só aumenta o tamanho do erro que você consegue cometer antes que ele fique óbvio. Jogar um repositório inteiro no contexto só porque a janela tecnicamente cabe geralmente produz resultados piores do que entregar um subconjunto de arquivos bem escolhido, porque código irrelevante compete pela atenção do modelo com a parte que realmente importa.

Tratar o contexto como um recurso limitado e curado — mais perto de como você pensaria sobre o conteúdo de um cache do que sobre uma caixa de entrada — tende a produzir um comportamento de agente mais confiável do que tratá-lo como "quanto mais, melhor".

Como isso aparece na prática

Os times que conseguem resultados consistentes com agentes de código não estão escrevendo prompts mais elaborados. Estão construindo a maquinaria pouco glamorosa em volta do prompt: ferramentas que recuperam os arquivos certos, convenções que mantêm a documentação perto do código que ela descreve, e loops de feedback que deixam o agente verificar as próprias mudanças (rodando testes, checando tipos) em vez de só afirmar que estão corretas.

O prompt ainda é a parte que você vê. Raramente é a parte que decide se o agente vai ter sucesso.

Vamos conversar?

Tem um projeto, uma vaga ou só quer trocar uma ideia sobre o assunto? Envie uma mensagem.

Entrar em contato