PROMPT ENGINEERING NÃO MORREU — EVOLUIU

A morte anunciada que nunca aconteceu

De tempos em tempos, alguém declara que prompt engineering morreu. O argumento costuma ser o mesmo: "os modelos ficaram tão bons que não precisa mais de prompt sofisticado." Eu discordo — e tenho dados para sustentar isso.

O que aconteceu não foi a morte da disciplina. Foi uma evolução radical. O prompt engineering de 2023 — aquele baseado em tentativa e erro, "fale como se fosse um especialista em X" — de fato ficou obsoleto. Mas o que surgiu no lugar é uma engenharia de interação com LLMs que exige mais conhecimento técnico, não menos.

Na minha experiência liderando projetos de IA na Frame8, e antes disso em contextos como TOTVS e Bradesco Seguros, vi que a qualidade do prompt é frequentemente o fator determinante entre um POC que impressiona e um sistema em produção que entrega valor real.

O que o Prompt Engineering Survey Paper revelou

O survey paper "The Prompt Report" (Schulhoff et al., 2024), que compilou mais de 1.500 artigos sobre técnicas de prompting, classificou 58 técnicas distintas em categorias que vão muito além do básico. O paper demonstra que prompting é uma disciplina com taxonomia própria, padrões replicáveis e impacto mensurável em performance.

Três achados me chamaram atenção:

• A diferença entre um prompt básico e um otimizado pode representar 40-70% de variação em accuracy dependendo da tarefa.
• Técnicas compostas (combinação de múltiplas estratégias) consistentemente superam técnicas isoladas.
• O design do prompt tem mais impacto na qualidade do output do que a escolha do modelo em muitos cenários.

Isso deveria encerrar a discussão sobre se prompt engineering importa ou não.

As 6 técnicas que uso em projetos enterprise

1. Chain-of-Thought (CoT) com decomposição explícita

Chain-of-thought não é novidade, mas a forma como aplicamos evoluiu. Em vez de simplesmente pedir "pense passo a passo", a prática atual envolve decomposição explícita do raciocínio em etapas nomeadas.

Em um projeto recente de análise de contratos, estruturamos o prompt para que o modelo seguisse: identificação das partes, extração de cláusulas críticas, análise de risco por cláusula, e síntese final. Cada etapa com critérios claros. O resultado foi uma redução de 35% em hallucinations comparado com o prompt direto.

2. Few-shot com exemplos estratificados

Few-shot prompting funciona melhor quando os exemplos são escolhidos para cobrir a distribuição dos casos reais — não apenas os casos fáceis. Isso significa incluir deliberadamente exemplos de edge cases, exemplos negativos (o que não fazer) e exemplos que representam a fronteira de decisão.

Na prática, mantenho bibliotecas de exemplos curados por domínio. Para cada projeto, selecionamos entre 3 e 7 exemplos que maximizam a cobertura dos cenários que o sistema vai enfrentar.

3. System prompts como contratos de comportamento

O system prompt deixou de ser uma instrução genérica e virou um contrato de comportamento. Nos projetos da Frame8, tratamos system prompts como artefatos de engenharia: versionados, revisados, testados.

Um system prompt bem construído define:

• Persona e escopo: o que o modelo é e o que não é
• Restrições hard: coisas que o modelo nunca deve fazer
• Formato de saída: estrutura esperada da resposta
• Protocolo de incerteza: como o modelo deve se comportar quando não tem confiança
• Exemplos de calibração: referências do tom e profundidade esperados

4. Tool use e function calling

Esta é talvez a evolução mais significativa. O modelo deixou de ser um gerador de texto para se tornar um orquestrador que decide quando e como usar ferramentas externas.

Em arquiteturas de agentes, o prompt engineering se expande para incluir a descrição das ferramentas disponíveis, os critérios para seleção de ferramentas e as instruções de como interpretar os resultados. A qualidade dessas descrições impacta diretamente a taxa de acerto do modelo ao escolher a ferramenta correta.

Tenho visto taxas de seleção correta de ferramenta variando de 60% a 95% dependendo exclusivamente da qualidade da descrição no schema.

5. Structured outputs com JSON Schema

Forçar outputs estruturados via JSON Schema transformou a confiabilidade dos sistemas. Em vez de parsear texto livre e torcer para o modelo seguir o formato, definimos schemas rígidos que o modelo deve obedecer.

Isso é particularmente relevante em contextos enterprise onde o output do LLM alimenta outros sistemas. Um JSON malformado quebra o pipeline inteiro. Com structured outputs, a taxa de conformidade vai para virtualmente 100%.

6. Meta-prompting e prompts auto-otimizáveis

A fronteira atual é usar LLMs para otimizar prompts de outros LLMs. Técnicas como DSPy e OPRO (Optimization by PROmpting) permitem que o prompt seja tratado como um hiperparâmetro otimizável contra uma métrica objetiva.

Na Frame8, usamos essa abordagem quando temos um dataset de avaliação robusto. O sistema testa variações do prompt, mede performance, e converge para a versão mais eficaz. É prompt engineering automatizado — mas que exige um engenheiro humano para definir as métricas, os guardrails e a estratégia de otimização.

Padrões para uso enterprise

Depois de implementar dezenas de sistemas baseados em LLMs, destilo os padrões que consistentemente fazem diferença em produção:

• Separe instrução de contexto: mantenha as instruções do sistema separadas dos dados de entrada. Isso facilita manutenção e debugging.
• Versione seus prompts: trate prompts como código. Git, code review, changelog. Não existe "só um ajustezinho" em produção.
• Teste com datasets representativos: crie suites de avaliação antes de otimizar. Sem baseline, você não sabe se está melhorando ou piorando.
• Documente as decisões de design: por que esse formato? Por que essa ordem de instruções? As razões se perdem rápido se não forem documentadas.
• Monitore drift: a performance do prompt pode degradar com atualizações do modelo. Tenha alertas para detectar isso.

O que esperar daqui para frente

Prompt engineering vai continuar evoluindo em direção a mais formalização e menos artesanato. Veremos mais frameworks de otimização automática, mais integração com pipelines de CI/CD, e mais métricas padronizadas de qualidade.

Mas o core permanece: entender profundamente o problema, o modelo e o usuário final para projetar a interação que maximiza valor. Isso não é algo que um template genérico resolve. É engenharia.

A disciplina não morreu. Ela cresceu a ponto de exigir profissionais sérios. E é exatamente isso que empresas que querem extrair valor real de IA precisam entender.