--- title: "Não, a Engenharia de Prompt Não Acabou. Só Evoluiu." author: "Ricardo Pupo Larguesa" date: "2026-06-17 21:28:00-03" category: "Opinião" url: "http://aintuicao.scale.press/portal/aintuicao/post/2026/06/17/nao-a-engenharia-de-prompt-nao-acabou-so-evoluiu/md" --- ## Resumo - A ideia de que a engenharia de prompt chegou ao fim é um equívoco; o campo evoluiu para a "Engenharia de Loop", onde o foco é projetar sistemas que operam de forma autônoma em vez de apenas realizar interações manuais constantes. - O papel do profissional mudou de um operador que fornece instruções passo a passo para um arquiteto que gerencia o comportamento e os fluxos dos agentes. - A Engenharia de Prompt permanece como uma competência fundacional crítica, sendo indispensável tanto para usuários que gerenciam fluxos complexos em agentes persistentes quanto para arquitetos que constroem harnesses multi-agentes. - Conceitos frequentemente vistos como substitutos, como a "Engenharia de Contexto" e a "Engenharia de Loop", são, na verdade, aplicações avançadas e subáreas da Engenharia de Prompt. - A eficácia de um agente autônomo é determinada pela capacidade de estruturar instruções claras para mecanismos de auto-reflexão, critérios de parada, políticas de memória e definições de ferramentas. - Dominar técnicas de linguagem natural para guiar esses sistemas é hoje o principal diferencial que separa agentes medíocres de ferramentas altamente úteis e confiáveis no mercado. --- Nos últimos dias, uma frase começou a circular com força nos feeds de quem trabalha com desenvolvimento e IA: *“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”* A frase é de **Peter Steinberger**, criador do OpenClaw. Poucos dias depois, **Boris Cherny** (líder do Claude Code na Anthropic) completou o coro: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.” **Addy Osmani** (Google) publicou um artigo que deu nome ao movimento: **Loop Engineering**. De repente, começou a parecer que a Engenharia de Prompt tinha morrido. Que o futuro era projetar sistemas autônomos que chamam agentes, avaliam resultados, persistem memória e decidem o próximo passo… tudo sem você ficar no meio do loop. **Essa narrativa está errada.** Não porque Loop Engineering seja irrelevante (é extremamente relevante). Mas porque ela representa uma **evolução**, não um enterro, da Engenharia de Prompt. ## **1. O que realmente mudou em junho deste ano** O que Steinberger, Cherny e Osmani estão descrevendo não é o fim da Engenharia de Prompt. É o fim de uma fase específica dela: a fase em que o ser humano fica dentro do loop de decisão, dando uma instrução por vez. Eles pararam de ser o “operador” que fica chamando o agente a cada iteração. Em vez disso, passaram a projetar **sistemas de controle** que fazem isso de forma autônoma. Isso é Loop Engineering, e é poderoso. Porém, existe uma diferença entre “não preciso mais escrever prompts” e “não preciso mais entender como prompts funcionam”. A segunda afirmação é falsa. E é sobre ela que este artigo trata. ## **2. Engenharia de Prompt como competência fundacional** A Engenharia de Prompt nunca foi uma habilidade exclusiva de “usuário avançado de ChatGPT”. Ela se sempre foi uma competência fundacional que se manifesta em dois níveis distintos, mas interconectados: ### **Nível 1 - O Usuário Final Avançado** Pessoas que usam agentes complexos (Claude Code, OpenCode, Aider, Hermes, OpenHands, Continue etc.) para realizar trabalho real. Aqui, a Engenharia de Prompt aparece na capacidade de: - Descrever fluxos complexos em linguagem natural (narrativa orientada a metas, decomposição discursiva, analogias funcionais) - Aplicar heurísticas de forma consciente (critérios de parada, auto-reflexão, contraste entre caminho feliz e caminho do erro) - Gerenciar contexto de forma estratégica (o que entregar, o que resumir, o que descartar) - Projetar loops simples dentro de um único agente persistente ### **Nível 2 - O Arquiteto de Harness** Pessoas que constroem agentes, harnesses ou sistemas multi-agente. Aqui, a Engenharia de Prompt é ainda mais crítica, porque ela define: - O system prompt do agente principal (comportamento, personalidade, limites éticos e operacionais) - As descrições de ferramentas (tool schemas + instruções de uso) - Os mecanismos de reflection, critique e auto-correção - As políticas de memória (o que guardar, como resumir, quando esquecer) - Os critérios de parada e as condições de intervenção humana **Em ambos os casos, a Engenharia de Prompt é o alicerce.** A diferença está na profundidade e no escopo. ## **3. Engenharia de Contexto e Engenharia de Loop como subáreas da Engenharia de Prompt** Uma das narrativas mais repetidas nos últimos 2 anos é que “agora não é mais prompt engineering, é context engineering” ou “loop engineering”. Essa dicotomia é falsa. **Engenharia de Contexto** é a aplicação avançada da Engenharia de Prompt focada em decidir *o que entregar* para o modelo em cada chamada (memória relevante, estado atual, documentos, histórico comprimido). Sem boa Engenharia de Prompt, você não sabe formular o que deve entrar no contexto nem como estruturá-lo. **Engenharia de Loop** é a aplicação avançada da Engenharia de Prompt focada em projetar *sistemas que chamam prompts de forma autônoma* (gatilhos, avaliação de resultados, políticas de retry, critérios de parada, delegação para sub-agentes). Sem boa Engenharia de Prompt, você não sabe escrever as instruções que o agente principal vai seguir dentro do loop, nem os critérios de avaliação que o verificador vai usar. Portanto: Context Engineering e Loop Engineering não substituem a Engenharia de Prompt. Elas são **camadas superiores** que dependem dela. ## **4. Exemplos práticos de Aplicação para Usuário Final** ### **Exemplo: Heurística de Parada + Auto-Reflexão em Linguagem Natural** Um usuário avançado pode escrever algo como: *Você é um engenheiro de software sênior trabalhando em uma refatoração grande. Antes de avançar para a próxima etapa do plano, pare e responda internamente às seguintes perguntas: (1) O que eu acabei de fazer realmente resolveu o problema original ou apenas moveu a complexidade para outro lugar? (2) Se eu fosse revisar este código daqui a três meses, o que eu provavelmente reclamaria? (3) Existe alguma decisão que tomei nas últimas três etapas que, olhando agora, parece inconsistente com o objetivo maior? Só avance se conseguir responder essas três perguntas com clareza. Se não conseguir, revise a etapa anterior antes de continuar.* Isso é Engenharia de Prompt aplicada a um agente persistente. Não é código. É linguagem natural estruturada que ativa heurísticas de auto-correção e evita loops de baixa qualidade. ### **Exemplo: Analogia Funcional + Contraste de Cenários** *Aja como um investigador de polícia experiente que nunca fecha um caso até que todas as pistas se conectem de forma coerente. Um investigador preguiçoso aceitaria a primeira versão plausível e seguiria em frente. Você não. Sempre que encontrar uma contradição ou uma lacuna grande, pare e investigue antes de avançar. Você saberá que terminou quando conseguir explicar o problema e a solução para um desenvolvedor júnior de forma que ele entenda sem fazer mais perguntas.* Execute esses exemplos e vai perceber que o comportamento do agente é fortemente condicionado ao prompt, e conhecer engenharia de prompt aplicada ao funcionamento e às limitações tanto do agente quanto do modelo no contexto do seu projeto faz toda a diferença na obtenção de uma resposta otimizada. Outro exemplo é a criação e utilização de skills, que no fim das contas não passam de prompts estruturados. Repare como as skills existentes possuem a estrutura básica de um prompt, com papel, tarefa e formato. É muito comum encontrar skills aplicando os frameworks clássicos de engenharia de prompt que descrevo no [meu livro](https://www.casadocodigo.com.br/products/livro-engenharia-de-prompt) como: RACE, CRISPE, CO-STAR, TAG, TRACE, CARE, PAR, AIDA, STAR, APE, BAB e RTF. ## **5. Exemplos práticos de Aplicação para Arquiteto de Harness** ### **Estrutura de System Prompt (inspirada em padrões de Aider, OpenHands e OpenCode)** Um system prompt bem projetado para um agente de codificação costuma conter instruções bem escritas, utilizando diversas técnicas da engenharia de prompt, cada uma de acordo com seu contexto específico: - **Definição de papel e princípios**: “Você é um engenheiro de software sênior com 15 anos de experiência. Seu objetivo não é escrever código rápido, mas escrever código que seja correto, legível, testável e que resista ao tempo.” - **Regras de ferramenta**: Descrições detalhadas de quando usar cada ferramenta, com exemplos de bons e maus usos. - **Políticas de memória e contexto**: O que manter em memória de curto prazo, como resumir etapas anteriores, quando pedir para o usuário fornecer mais contexto. - **Mecanismo de reflexão**: Instruções explícitas para o agente avaliar seu próprio trabalho antes de entregar (similar ao exemplo do usuário final, mas mais estruturado). - **Critérios de parada e intervenção humana**: Quando o agente deve parar e pedir ajuda (ex: “Se após 4 tentativas de correção o teste ainda falhar, pare e explique o que tentou”). ### **Padrão de Loop Simples (conceitual, inspirado em LangGraph + Aider + OpenHands)** Um loop mínimo de produção costuma ter pelo menos estes componentes: - **Trigger**: Agendamento (cron), evento (novo issue, push, mensagem do usuário) ou condição de estado. - **Executor Principal**: Agente que recebe o objetivo, planeja, usa ferramentas e produz saída. - **Verificador / Crítico**: Outro agente (ou mesmo modelo com temperatura mais baixa) que avalia se o resultado atende aos critérios definidos. - **Memória / Estado**: Armazenamento persistente (arquivo JSON, banco vetorial, git, ou memória do framework) que permite retomar o trabalho. - **Política de Parada**: Condição clara (objetivo alcançado + verificador aprovou) ou limite (máximo de iterações, custo de tokens, tempo). - **Canal de Intervenção Humana**: Mecanismo para o loop pedir ajuda quando fica travado ou incerto. Cada um desses componentes precisa de instruções específicas no seu contexto, e garantem resultados tão bons quanto forem as técnicas de engenharia de prompt empregadas em cada situação. ## **6. Por que isso importa para você seja qual for seu nível** Se você é usuário final de agentes: quanto melhor sua Engenharia de Prompt, mais você consegue extrair de ferramentas como Claude Code, Codex, OpenCode, Aider ou Hermes sem precisar virar desenvolvedor full-time de agentes. Se você é desenvolvedor ou arquiteto: a qualidade do system prompt, das tool descriptions e das instruções de reflexão que você escreve é frequentemente o fator que mais diferencia um agente medíocre de um agente realmente útil e confiável. Em ambos os casos, as técnicas de linguagem natural (narrativa, analogia, contraste, ancoragem de critérios de sucesso, auto-reflexão) continuam sendo extremamente poderosas, e continuam sendo Engenharia de Prompt. ## **Conclusão: A competência que não some** Peter Steinberger, Boris Cherny e Addy Osmani estão certos em uma coisa importante: o trabalho de maior alavancagem deste ano não é ficar promptando manualmente dentro de cada iteração. É projetar sistemas que fazem isso de forma autônoma e confiável. Mas eles não estão dizendo (nem poderiam dizer com seriedade) que entender como prompts funcionam deixou de ser importante. Pelo contrário: quanto mais autônomo o sistema, mais crítica fica a qualidade das instruções que você dá a ele, e mais sofisticada precisa ser sua capacidade de pensar sobre contexto, heurísticas, critérios de avaliação e comportamento desejado. **A Engenharia de Prompt não morreu. Ela apenas parou de ser sobre você ficar no meio do loop o tempo todo.** Agora ela é sobre você projetar o loop, e sobre você escrever as instruções que o loop vai executar de forma autônoma. Quem entender isso cedo vai ter uma vantagem significativa nos próximos anos. Quem acreditar que “prompt engineering acabou” vai descobrir, na prática, que os melhores loops ainda dependem de excelentes prompts. *A diferença entre um agente medíocre e um agente excelente, hoje em dia, ainda passa por Engenharia de Prompt. Só que agora ela aparece em outro lugar, e em outro nível de sofisticação.*