Comecei a tratar agentes de codificação com IA menos como janelas de chat e mais como trabalhadores com contratos. A diferença não está no modelo. A diferença está em saber o que continuar fazendo, como provar o progresso e quando parar.
É aí que /loop e /goal fazem a diferença.
O Claude Code agora expõe ambas as ideias diretamente: /goal para uma condição de conclusão e /loop para prompts repetidos enquanto uma sessão permanece aberta. O OpenAI Codex tem /goal como um comando documentado, e a OpenAI também documenta loops de melhoria orientados por eval como um fluxo de trabalho. O detalhe importante: eu não descreveria o OpenAI Codex como tendo o mesmo comando de barra oficial /loop, a menos que ele apareça na sua lista de comandos instalados. Na documentação atual que verifiquei, /goal é oficial; "loop" é o padrão.
Essa distinção importa porque essas ferramentas parecem semelhantes por fora, mas eu as uso para trabalhos diferentes.
Resposta rápida
Use /goal quando o agente deve buscar um resultado durável até que uma condição clara seja verdadeira.
Use /loop quando o agente deve repetir um prompt em um intervalo ou ritmo autodeterminado enquanto a sessão permanece aberta.
Use um loop orientado por eval quando a saída puder ser pontuada e melhorada repetidamente: qualidade de código, qualidade visual, desempenho, SEO, migrações, testes ou qualquer tarefa onde cada passagem possa ser medida.
A regra prática é simples: um objetivo precisa de uma linha de chegada; um loop precisa de uma cadência; ambos precisam de verificação.
O que o Claude Code /goal faz
A referência de comandos do Claude descreve /goal [condição|clear] como uma maneira de definir uma condição para que o Claude continue trabalhando através dos turnos até que essa condição seja atendida. A documentação de hooks adiciona um detalhe de implementação útil: /goal se comporta como um atalho embutido para uma condição de parada com escopo de sessão.
Em termos simples, /goal diz ao Claude:
Isso é poderoso, mas apenas se a condição for concreta.
Fraco:
text /goal Torne o app melhor
Útil:
text /goal Corrija o bug do checkout, mantenha todo o comportamento de pagamento existente intacto e pare apenas quando pnpm test, pnpm build e o caminho de checkout do Playwright passarem.
A segunda versão dá ao Claude um alvo, limites e prova. Ele pode decidir o caminho, mas não redefinir o sucesso no meio do caminho.
Eu uso /goal para trabalhos como:
No momento em que uma tarefa tem múltiplos resultados não relacionados, não uso um grande objetivo único. Eu a divido. Um objetivo por resultado é mais limpo e fácil de confiar.
O que o Claude Code /loop faz
A referência de comandos do Claude lista /loop [intervalo] [prompt] como uma habilidade agrupada. Ele executa um prompt repetidamente enquanto a sessão está aberta. Você pode dar um intervalo, deixar o Claude se auto-regular ou omitir o prompt e deixá-lo usar um prompt de manutenção configurado, onde disponível.
Isso faz com que /loop pareça mais operacional do que /goal.
Exemplos:
text /loop 5m verifique se a implantação de preview da Vercel está pronta, depois verifique /blog e /api/health
text /loop pegue o próximo item não verificado em PRODUCTION_READINESS.md, corrija-o, execute o teste relevante e atualize a lista de verificação
text /loop a cada 10m verifique o CI, resuma as falhas e pare de escalar apenas após a última execução ficar verde
O melhor caso de uso é verificação repetida ou pequenas unidades de trabalho repetidas. No meu loop híbrido de revisão de código com IA→, o padrão útil não foi "escrever para sempre". Foi: pegar um item da lista de verificação, implementá-lo, pedir a outro modelo para revisar, executar a build, marcar a caixa, repetir.
É isso que torna /loop perigoso se você escrever um prompt preguiçoso. Se o prompt não disser o que verificar, o agente pode continuar fazendo um trabalho plausível em que ninguém deve confiar.
O que o OpenAI Codex /goal faz
A OpenAI documenta /goal para o Codex tanto no app quanto na CLI. O guia do Codex o enquadra como um objetivo durável para trabalho de longa duração, especialmente quando a tarefa tem uma condição de sucesso clara e um loop de validação.
A referência de comandos da CLI do Codex lista /goal como o comando para definir, pausar, retomar, visualizar ou limpar um objetivo de tarefa. A documentação do app diz a mesma ideia em termos de produto: um objetivo é persistente, visível e pode ser pausado ou retomado.
Um bom objetivo do Codex parece quase idêntico a um bom objetivo do Claude:
text /goal Complete a migração para Next.js 16 sem alterar rotas públicas. Pare apenas quando pnpm build passar, a homepage carregar, /blog carregar e as rotas alteradas retornarem 200.
Para o Codex, gosto de objetivos que nomeiam:
A própria orientação da OpenAI para problemas difíceis é próxima de como já trabalho: dê ao Codex um sistema de avaliação, faça melhorias focadas, execute a pontuação novamente, inspecione artefatos e continue até que a pontuação seja boa o suficiente.
Esse é o coração do trabalho agentico. Não autonomia por si só. Autonomia vinculada à medição.
A OpenAI tem /loop?
É aqui que as pessoas podem ser descuidadas com a redação.
O Claude Code tem um comando /loop documentado. O OpenAI Codex tem fluxos de trabalho documentados no estilo de loop: loops de eval, loops de reparo, modo de objetivo com validação, hooks e automações. Mas na referência atual de comandos de barra do Codex que verifiquei, encontrei /goal, /plan, /review, /status, /mcp e muitos outros, não um comando oficial /loop equivalente ao do Claude.
Portanto, minha redação é:
Isso não é uma fraqueza. Apenas muda como eu configuro. No Codex, geralmente expresso o loop dentro do objetivo ou prompt:
text /goal Melhore este componente até que a pontuação de regressão visual esteja acima de 95%. Faça uma mudança focada de cada vez, execute a comparação de capturas de tela após cada mudança, mantenha um log de pontuação e pare quando o alvo for mantido duas vezes seguidas.
Isso dá ao Codex o mesmo ritmo operacional sem fingir que existe um comando de barra /loop separado.
Minha configuração prática
Para trabalho sério, uso um padrão de cinco camadas.
1. Um alvo escrito
Começo com um plano curto ou lista de verificação. Pode ser `PLAN.md`, `PRODUCTION_READINESS.md`, uma issue do GitHub ou um prompt simples. O formato importa menos do que a verificabilidade.
Uma tarefa fraca diz "melhore o sistema de artigos".
Uma tarefa forte diz "impedir publicação quando URLs externas retornarem 404, soft 404, content-type errado ou redirecionarem para o alvo errado; manter salvos de rascunho permitidos; provar com build e um caso de validação focado".
Esse é o tipo de instrução com a qual um agente pode continuar agindo.
2. Um modelo proprietário
Escolha quem está dirigindo. O Claude pode ser o implementador. O Codex pode ser o implementador. Não deixe ambos editarem os mesmos arquivos ao mesmo tempo, a menos que você tenha worktrees ou uma entrega estrita. Autonomia sem propriedade vira teatro de conflito de merge.
3. Uma segunda opinião
Para trabalho de maior risco, ainda gosto de revisão de modelo para modelo. Escrevi sobre minha ponte de revisão por pares com IA→ porque ela captura modos de falha diferentes de um único modelo verificando a si mesmo.
O revisor pode ser somente leitura. Não precisa de acesso de escrita para ser útil. Precisa do diff, do objetivo, dos arquivos arriscados e permissão para dizer "isso está errado".
4. Um validador rígido
Testes vencem confiança. Builds vencem resumos. Capturas de tela do navegador vencem "deveria renderizar". Logs vencem vibes.
Para trabalho web, isso geralmente significa:
bash pnpm build pnpm lint pnpm test
mais verificações de rota, capturas de tela ou fluxos do Playwright quando a tarefa é voltada para o usuário.
Para fluxos de trabalho de conteúdo, minha preferência é QA de URL antes da publicação: não apenas "o link retornou 200", mas "ele chegou à página que o artigo afirmava?". Esse é o mesmo princípio. O validador deve verificar a coisa que o leitor realmente experiencia.
5. Uma regra de parada
Esta é a parte que as pessoas pulam.
Um loop sem regra de parada torna-se caro. Um objetivo sem regra de parada torna-se vago. Uma regra de parada deve ser chata e literal:
Essa última linha é importante. Bons agentes não escondem incerteza. Eles a trazem à tona.
Quando uso cada um
| Situação | Melhor ferramenta | Por quê |
|---|---|---|
| --- | ---: | --- |
| Uma grande tarefa com uma definição clara de concluído | /goal | O agente pode continuar movendo-se em direção a um estado final durável |
| Verificar status de implantação a cada poucos minutos | Claude /loop | A mesma verificação precisa ser executada repetidamente |
| Melhorar um artefato gerado contra uma pontuação | Loop de eval | A pontuação diz ao agente se a última passagem melhorou algo |
| Limpar item por item de uma lista de verificação | /loop ou /goal | Use /loop para itens repetidos, /goal para o resultado final |
| Pesquisa com direção incerta | Prompt normal ou modo de plano | Não inicie autonomia antes que o alvo esteja claro |
| Ação sensível de produção | Portão de aprovação humana | Agentes podem preparar a ação, mas não devem executá-la silenciosamente |
Prompts para copiar e colar
Claude Code /goal
text /goal Termine esta correção de bug sem alterar comportamento não relacionado. Primeiro leia AGENTS.md e os arquivos de rota/componente relevantes. Faça pequenos commits apenas na lógica, execute pnpm build e o caminho de regressão focado, e pare apenas quando o bug original não reproduzir mais e toda a verificação passar.
Claude Code /loop
text /loop pegue o próximo item não verificado em TODO.md, inspecione os arquivos reais primeiro, faça uma correção focada, execute o comando de validação relevante, atualize a caixa de seleção apenas após a verificação e reporte qualquer bloqueador em vez de pulá-lo
OpenAI Codex /goal
text /goal Complete a migração descrita em PLAN.md. Preserve o comportamento público, mantenha arquivos não relacionados inalterados, execute os comandos de validação listados após cada marco, mantenha um log de progresso curto e pare apenas quando cada marco estiver completo e a build final passar.
Prompt de loop orientado por eval do Codex
text Quero isso como um loop de melhoria orientado por eval. Encontre ou crie o comando que pontua a saída. Faça uma melhoria focada de cada vez, execute a pontuação novamente após cada mudança, inspecione qualquer artefato gerado diretamente, registre mudanças de pontuação e continue iterando até que a pontuação alvo seja alcançada duas vezes seguidas. Se a pontuação parar de melhorar, explique o gargalo e pare.
Erros comuns
O primeiro erro é usar /goal como uma frase motivacional. "Torne isso pronto para produção" não é um objetivo. É um humor.
O segundo erro é usar /loop sem um validador. Se cada iteração terminar com uma afirmação não verificada, o loop é apenas repetição.
O terceiro erro é agrupar trabalho não relacionado. "Corrigir auth, redesenhar o dashboard, atualizar preços e limpar SEO" devem ser quatro tarefas, não uma execução autônoma heroica.
O quarto erro é dar ao agente acesso de escrita antes que ele entenda as regras do repositório. Em meus próprios projetos, quero que os agentes leiam `AGENTS.md`, respeitem as regras de implantação, evitem segredos e verifiquem antes de reivindicar sucesso. A camada de controle ao redor do modelo importa tanto quanto o modelo. É por isso que continuo voltando aos fluxos de trabalho de desenvolvedor MCP→: ferramentas, permissões, evidências e ações reproduzíveis são o que transformam um chat inteligente em um sistema operacional.
O ponto real
O interessante sobre /loop e /goal não é a sintaxe do comando de barra. O interessante é a mudança de responsabilidade.
Um prompt normal diz: responda-me.
Um objetivo diz: termine isso e saiba o que terminado significa.
Um loop diz: continue verificando ou melhorando até que a condição mude.
É assim que quero que agentes de codificação com IA funcionem. Não como mágica. Não como caos sem supervisão. Como trabalhadores com um contrato, um validador e uma regra de parada limpa.
Se você usa Claude Code, /loop é a maneira mais rápida de transformar uma verificação operacional repetida em algo que o agente pode lidar enquanto você continua trabalhando. /goal é a ferramenta melhor quando o trabalho tem um estado final durável único.
Se você usa OpenAI Codex, /goal lhe dá o objetivo durável, e o loop pertence ao design de validação: testes, evals, artefatos, hooks, logs de progresso e uma condição de parada que o agente não pode redefinir silenciosamente.
Esse é o padrão em que confio: não "deixe a IA rodar", mas "deixe a IA rodar dentro de um sistema que possa dizer não a ela".
Fontes verificadas
---