A engenharia de prompts está morta

A engenharia de prompt como uma habilidade está morta. Eu sei que essa é uma opinião polêmica. Eu também sei que está correta.

Estou construindo sistemas de agentes de IA desde março de 2023. Aprofundei-me na engenharia de prompt no início - GPTs personalizados com bases de conhecimento especializadas, sistemas de prompt projetados para pesquisa de UX, rastreamento de refeições, criação de conteúdo viral, assistentes de planejamento. Fiz tudo isso. Segui os guias, li os artigos, obcequei-me pela estrutura do prompt do sistema.

E em algum lugar nos últimos 12 meses percebi: quase nada disso importa mais. A habilidade que passei tempo real desenvolvendo foi comoditizada. O que a substituiu é mais difícil, mais valioso, e quase ninguém está falando sobre isso corretamente.

Por que a engenharia de prompt como uma habilidade está morta

A engenharia de prompt teve cerca de 18 meses como um diferenciador técnico legítimo. Chame de meados de 2022 a final de 2023. Durante essa janela, saber como extrair uma saída útil de um modelo era genuinamente não óbvio. O prompting em cadeia de pensamento melhorou as saídas de forma significativa. Exemplos de poucos disparos ajudaram muito. Estruturação de persona, ordenação cuidadosa de instruções, controle de formato de saída - tudo isso fez uma diferença real porque os modelos base precisavam da ajuda.

Então os modelos melhoraram. Rápido.

GPT-4 Turbo, Claude 3, Gemini 1.5 - esses modelos entendem a intenção. Você não precisa mais guiá-los através de uma tarefa com rituais elaborados de prompting. Cadeia de pensamento? Os modelos atuais fazem isso automaticamente sem serem instruídos a "pensar passo a passo". Exemplos de poucos disparos? Os modelos inferem a partir do contexto da conversa. Personas cuidadosamente estruturadas? Você pode escrever "você é um assistente útil que se especializa em X" e funciona bem.

As coisas elaboradas que as pessoas estavam vendendo como engenharia de prompt avançada? Sempre foi apenas "aprender a dar instruções claras a algo que precisava de instruções mais claras." Isso não é uma habilidade. Isso é comunicação.

Aqui está a prova: se a engenharia de prompt fosse uma verdadeira habilidade técnica, você precisaria entender algo sobre como o sistema funciona para melhorar nisso. Mas a maioria dos conselhos sobre engenharia de prompt é apenas... bons conselhos de escrita com etapas extras. Seja específico. Dê exemplos. Declare suas restrições. Esses não são insights sobre IA - são princípios básicos de comunicação.

Os cursos do YouTube, os bootcamps de "engenheiro de prompt certificado", as postagens no LinkedIn sobre estruturas de prompt - toda essa indústria se formou em torno de uma habilidade que teve uma vida útil de dois anos. Não estou criticando as pessoas que criaram esse conteúdo. Foi um valor real na época. Simplesmente não é mais o gargalo.

O que realmente matou isso

Três coisas aconteceram simultaneamente e a combinação foi letal para a engenharia de prompt como um caminho de carreira.

Melhores modelos base que entendem a intenção. Posso dar a Claude Sonnet uma instrução vagamente formulada e levemente ambígua e ele entenderá o que quero dizer. Não preciso elaborá-la como um contrato legal. A capacidade interpretativa do modelo melhorou mais rápido do que a complexidade do que as pessoas queriam fazer com ele.

Uso de ferramentas e chamadas de função. Este é o grande ponto. Uma grande parte do que a engenharia de prompt estava tentando fazer era fazer com que os modelos simulassem capacidades que eles realmente não tinham. "Imagine que você tem acesso a um motor de busca..." Agora você apenas dá a ele uma ferramenta de busca. As acrobacias de prompt eram uma solução alternativa para a ausência de integração real de ferramentas. Agora que a chamada de ferramentas é padrão, você não precisa da solução alternativa.

A realização de que é gerencial, não técnica. Os melhores engenheiros de prompt eram bons escritores e bons gerentes - pessoas que podiam especificar claramente o que queriam. Essa é uma habilidade útil. Não é uma habilidade técnica. Um engenheiro que passou anos aprendendo programação de sistemas tem profundidade que se transfere. Um "engenheiro de prompt" que passou anos otimizando a formulação de instruções tem uma habilidade que foi automatizada pelas melhorias do modelo.

O que o substituiu: arquitetura de agentes e design de ferramentas

Eu administro um sistema multi-agente chamado OpenClaw. 15+ agentes especializados, cada um executando um modelo diferente, lidando com diferentes partes do meu fluxo de trabalho diário - resumos matinais, pesquisa, tarefas de código, gerenciamento de memória, agendamento de conteúdo, monitoramento de posições em criptomoedas. O sistema processa cerca de 40 mil tokens por dia. O custo mensal da API é de cerca de $40 porque sou agressivo na seleção de modelos.

Os prompts para cada agente individual? Talvez 20 linhas. Às vezes menos. Nada elaborado.

O código de orquestração tem milhares de linhas. As integrações de ferramentas são onde a maior parte do trabalho reside. O pensamento difícil foi em: qual agente lida com o que, como os agentes passam contexto uns para os outros, o que acontece quando um agente falha, como a memória persiste entre as sessões, qual modelo é barato o suficiente para uma determinada tarefa enquanto ainda é capaz de não estragar tudo.

Essa é a nova habilidade. E é realmente uma habilidade - uma que requer compreensão de sistemas, trade-offs, modos de falha e estruturas de custo.

Aqui está o que o trabalho real parece agora:

Seleção de modelo por tarefa. Eu não uso um modelo para tudo. Opus lida com decisões de orquestração que requerem julgamentos. Sonnet lida com tarefas rápidas onde preciso de velocidade em vez de profundidade. Gemini Flash lida com síntese de pesquisa porque é barato e bom em resumir grandes quantidades de texto. Codex lida com código porque é feito para isso. Escolher o modelo errado para uma tarefa ou queima dinheiro ou degrada a qualidade da saída. Essa lógica de seleção importa muito mais do que a formulação do prompt.

Arquitetura de memória. Uma única chamada de modelo é sem estado. Sistemas de agentes reais não são. Como você persiste o contexto entre as sessões, o que você inclui na memória de trabalho de cada agente, quando resumir versus reter todo o histórico da conversa - essas decisões afetam se seu sistema permanece coerente ao longo do tempo ou lentamente se degrada em confusão. Meu sistema usa arquivos markdown (MEMORY.md, SOUL.md, AGENTS.md) que os agentes leem em cada execução. É simples e funciona. Chegar lá levou iteração.

Recuperação de erros. Chamadas de modelo falham. APIs ficam fora do ar. Um agente retorna uma resposta que está formatada corretamente, mas semanticamente errada. O que seu sistema faz? Ele tenta novamente com o mesmo prompt? Escala para um modelo mais capaz? Registra a falha e ignora? Notifica você? Construir um tratamento de erro robusto em pipelines de agentes é onde passei mais tempo do que em qualquer prompt individual.

Design de ferramentas. Quando você constrói ferramentas para seus agentes usarem, você está essencialmente projetando uma API para um sistema semi-autônomo. A ferramenta precisa fazer uma coisa claramente. O esquema de entrada precisa ser simples o suficiente para que um modelo a chame corretamente. A saída precisa ser estruturada de uma forma que o modelo possa raciocinar. Um mau design de ferramenta leva a agentes que não conseguem usar suas ferramentas de forma eficaz - e você vai