Novembro de 2023. A OpenAI lançou a API de function calling com suporte estável e, sem que ninguém fizesse um anúncio formal, o ofício do “prompt engineer” começou o seu declínio. Não porque os prompts deixassem de importar, mas porque deixaram de ser o que mais importava.
Na Soamee, há anos que construímos produtos com LLMs. Passámos pela fase dos prompts mágicos, pela fé cega de que a redação perfeita da mensagem era o segredo do sucesso. E aprendemos, por vezes de forma dolorosa, que essa fé estava errada.
Este artigo é a minha opinião direta sobre o que aconteceu, por que o prompt engineering como disciplina isolada morreu e o que verdadeiramente move a agulha nos produtos de IA em 2026.
A Era dos Prompts Mágicos (2022-2024)
Quando o GPT-3 chegou ao mainstream e o GPT-4 o popularizou, o mundo tech dividiu-se em dois grupos: os céticos que achavam que era tudo fumaça, e os entusiastas que acreditavam ter encontrado o oráculo definitivo. Os entusiastas tinham razão numa coisa: os LLMs eram genuinamente poderosos. Mas tiraram a conclusão errada sobre por que funcionavam.
A narrativa dominante era: “A chave está em saber falar com o modelo.” Surgiram cursos de “prompt engineering” a centenas de dólares. Apareceram repositórios com milhares de estrelas cheios de “prompts definitivos”. O LinkedIn encheu-se de perfis que se autodenominavam “Prompt Engineer” como se fosse a profissão do futuro.
O problema não era que os prompts não importassem. O problema era a conclusão que se tirava: que a diferença entre um produto de IA excelente e um medíocre residia em ter encontrado a formulação correta da mensagem. Que havia prompts mágicos à espera de ser descobertos.
Esta ideia estava errada. E o mercado demorou entre 18 e 24 meses a percebê-lo.
O Que Matou o Prompt Engineering
1. Os structured outputs tornaram obsoletos os prompts de formato
Durante anos, uma parte importante do trabalho de “prompt engineering” era conseguir que o modelo respondesse no formato correto. Pedias JSON e às vezes obținhas JSON, às vezes texto com JSON dentro, às vezes algo que parecia JSON mas não era. Existiam bibliotecas inteiras dedicadas a parsear e corrigir a saída dos modelos.
Hoje, a OpenAI, a Anthropic e a Google suportam nativamente structured outputs: defines um esquema JSON e o modelo garante que a sua resposta cumpre esse esquema. Não há magia, não há redação perfeita. Há um contrato técnico.
# Antes: rezar para que o modelo respondesse em JSON
response = client.messages.create(
model="claude-3-5-sonnet",
messages=[{"role": "user", "content": "Extrai o nome e email. Responde APENAS em JSON com campos 'nome' e 'email'. NÃO incluas texto adicional."}]
)
# Resultado: imprevisível
# Agora: definir o contrato
class ExtractedContact(BaseModel):
nome: str
email: str
response = instructor.from_anthropic(client).messages.create(
model="claude-3-5-sonnet",
response_model=ExtractedContact,
messages=[{"role": "user", "content": "Extrai o contacto do texto"}]
)
# Resultado: garantidoO prompt de formato morreu. A engenharia matou-o.
2. O tool use tornou obsoletos os prompts de ação
O segundo grande pilar do prompt engineering era conseguir que o modelo tomasse as decisões certas: “Se o utilizador perguntar X, faz Y. Se perguntar Z, faz W.” Prompts com condicionais, árvores de decisão escritas em linguagem natural.
O function calling substituiu-o com elegância. Em vez de tentar que o modelo simulasse lógica de negócio mediante texto, dás-lhe ferramentas reais e deixas que decida quando usá-las. O modelo é bom a tomar decisões de alto nível; o código é bom a executar ações com precisão.
tools = [
{
"name": "pesquisar_pedido",
"description": "Pesquisa um pedido por ID ou email do cliente",
"input_schema": {
"type": "object",
"properties": {
"query": {"type": "string"},
"tipo": {"enum": ["id", "email"]}
}
}
},
{
"name": "atualizar_estado",
"description": "Atualiza o estado de um pedido",
"input_schema": {
"type": "object",
"properties": {
"pedido_id": {"type": "string"},
"novo_estado": {"enum": ["em_processamento", "enviado", "cancelado"]}
}
}
}
]Não precisas de escrever “Se o utilizador mencionar um número de pedido, pesquisa-o primeiro antes de responder.” O modelo infere-o do contexto das ferramentas. O que antes era um parágrafo de instruções no prompt é agora uma definição de função.
3. O context engineering importa mais do que a redação do prompt
Aqui está o insight que mais custou à indústria interiorizar: o que colocas no contexto importa muito mais do que como rediges a pergunta.
Podes ter o prompt mais elegante do mundo, mas se o modelo não tiver acesso à informação relevante, vai alucinar ou dar respostas genéricas. E podes ter um prompt básico, quase telegráfico, mas se lhe deres a informação correta, o modelo vai render bem.
O context engineering é a disciplina de desenhar o que chega ao modelo antes de responder:
- RAG bem implementado: Não apenas embeddings e cosine similarity. Seleção de chunks relevantes, reranking, filtragem por metadados, contexto suficiente sem exceder o limite.
- Few-shot examples dinâmicos: Não exemplos estáticos no prompt. Exemplos selecionados dinamicamente conforme a consulta atual.
- Gestão do contexto conversacional: Que turnos anteriores conservar, quais comprimir, quais descartar.
- Dados estruturados vs. texto: Por vezes é melhor dar ao modelo uma tabela bem formatada do que um parágrafo a explicar os dados.
Nos nossos projetos, 80% das melhorias de qualidade vieram de melhorar o contexto, não de reescrever o prompt.
4. A avaliação substituiu o instinto
O prompt engineering clássico era fundamentalmente guiado por intuição. Experimentavas uma variação, parecia melhor, publicavas. Não havia forma rigorosa de medir se era realmente melhor em todos os casos ou apenas nos que tinhas testado manualmente.
A maturidade do campo trouxe as evals: conjuntos de casos de teste com critérios de avaliação explícitos, frequentemente avaliados por outro LLM. Frameworks como RAGAS, LangSmith, Braintrust ou PromptFoo permitem fazer isto de forma sistemática.
Quando tens evals, podes fazer o que fazias com o código: medir antes de mudar, comparar versões, detetar regressões. O prompt deixa de ser um artefacto artesanal que ninguém toca com medo de partir algo e torna-se código versionado com testes.
Isto muda a natureza do trabalho. Não é intuição, é engenharia.
O Que Substituiu o Prompt Engineering: LLM Engineering
O que está a emergir não é o prompt engineering evoluído. É uma disciplina completamente diferente que toma emprestado o nome da engenharia de software porque isso é, essencialmente, o que é.
O LLM engineering trata o modelo de linguagem como mais um componente de sistema: com interfaces definidas, contratos de dados, testes automatizados, observabilidade e deployment contínuo. O prompt é um ficheiro de configuração versionado em git, não um texto guardado numa variável de ambiente que só o especialista da equipa toca.
Os pilares desta disciplina:
System prompts como especificações de software: Versionados em git, revistos em pull requests, com testes de regressão. Se alguém mudar o system prompt, o pipeline de CI corre as evals e bloqueia o merge se a qualidade baixar.
Structured outputs como contratos de API: O modelo é um serviço interno com uma interface definida. O que devolve tem um schema. O resto do sistema confia nesse schema, não em parsear texto livre.
Tool use como arquitetura de agentes: Em vez de tentar que o modelo faça tudo, dás-lhe ferramentas especializadas e deixas que orquestre. A lógica de negócio vive nas ferramentas (código testável), não no prompt.
Observabilidade e rastreabilidade: Cada chamada ao modelo é registada com o seu contexto completo, tokens usados, latência, resultado. Quando algo falha em produção, há um trace que te diz exatamente o que aconteceu.
Evals como CI/CD para prompts: Antes de fazer deploy de qualquer alteração ao system prompt ou à arquitetura RAG, corres o suite de evals. Se a pontuação baixar, não se faz deploy.
Onde o Prompting Ainda Importa
Seria desonesto dizer que os prompts não importam de todo. Importam. Mas em contextos específicos:
Tarefas criativas: Quando queres que o modelo gere texto com um estilo particular, a redação do prompt continua a ser uma arte. “Escreve no estilo de um jornalista do The Economist a cobrir tecnologia” produz resultados diferentes de “Escreve um artigo sobre tecnologia”. Aqui a nuance da linguagem importa.
Prototipagem rápida: Quando estás a validar uma ideia em poucas horas, não faz sentido construir toda a infraestrutura de evals e structured outputs. Um prompt bem redigido no Cursor ou na consola da Anthropic é perfeitamente válido para explorar a viabilidade.
Edge cases e comportamento de raciocínio: Para tarefas que requerem raciocínio em cadeia (chain-of-thought), a forma como estruturas o problema no prompt continua a ter impacto. “Pensa passo a passo” e as suas variações não são magia, mas são instruções que afetam o processo de raciocínio.
Modelos sem tool use ou structured outputs: Se por alguma razão trabalhas com modelos menores ou implementados localmente que não suportam estas capacidades, o prompting clássico continua a ser relevante.
O que morreu não é o prompt em si. O que morreu é a ideia de que o prompt é o artefacto central em torno do qual tudo o resto gira.
O Que a Tua Equipa Deve Aprender
Se estás a construir produtos com LLMs em 2026, estas são as competências que realmente importam:
1. Design de schemas JSON: Saber definir estruturas de dados claras para os outputs do modelo. Pydantic, Zod, JSON Schema. Isto é mais importante do que saber redigir prompts.
2. Arquiteturas de agentes: Entender como desenhar sistemas onde o LLM orquestra ferramentas especializadas. Patterns como ReAct, Plan-and-Execute, e quando usar cada um.
3. RAG em produção: Não o tutorial de 5 minutos com ChromaDB e embeddings básicos. RAG real inclui chunking estratégico, reranking, avaliação de relevância, e monitorização de qualidade.
4. Design e execução de evals: Saber definir o que significa “bom” para o teu caso de uso, construir conjuntos de teste representativos, e executar avaliações de forma sistemática.
5. Observabilidade de LLMs: Tracing, logging, monitorização de custos e latência. Ferramentas como LangSmith, Langfuse, ou Helicone. Não podes melhorar o que não consegues medir.
6. Gestão de contexto: Entender os limites do contexto, quando e como comprimir, quando usar memória externa vs. contexto in-context.
Os prompts fazem parte de tudo isto. Mas são um componente entre muitos, não o centro.
Conclusão: Constrói Sistemas, Não Prompts
A diferença entre uma equipa que usa IA de forma produtiva e uma que não o faz não está em quem sabe escrever melhores prompts. Está em quem construiu a infraestrutura correta em torno do modelo: os contratos de dados, as ferramentas, o pipeline de avaliação, a observabilidade.
O prompt engineer que só sabe redigir mensagens é o equivalente a um developer frontend que só sabe copiar código do Stack Overflow sem entender por que funciona. Útil para tarefas pontuais, insuficiente para construir produtos de qualidade.
O que o mercado exige agora são engenheiros que entendam os LLMs como componentes de sistema: as suas capacidades, as suas limitações, e como integrá-los em arquiteturas de software reais.
Na Soamee, há algum tempo que trabalhamos exatamente assim. Não vendemos prompts mágicos nem workshops de ChatGPT. Construímos produtos de inteligência artificial com a mesma disciplina de engenharia com que construiríamos qualquer outro sistema de software: com contratos definidos, testes, observabilidade e deployment contínuo.
Se a tua empresa está a avaliar como integrar IA de forma séria, para além do protótipo inicial, conta-nos. Agenda uma consultoria gratuita e falamos de arquitetura, não de prompts.