99% das pessoas estão usando /goal e loops de forma errada.
O hype que elas ouvem é "loops de longa duração para agentes autônomos": aponte para uma tarefa, vá embora, volte com código funcionando.
Mas os principais engenheiros de agentes já fazem isso sem /goal há 6 meses (quando GPT-5.2 e Opus 4.5 foram lançados). Isso se chama engenharia de harness + desenvolvimento orientado a especificações:
- Construa um harness para o agente observar o problema
- Escreva uma especificação enxuta com todos os casos de teste
- Deixe o Codex ou Claude Code em loop sem supervisão até atender a todos.
Eu inicio esses loops constantemente durante a noite — de 2 a 5 horas por execução. Em abril, um deles resolveu um bug de cache de build do Turbo em nosso monorepo Vercel e estava tudo verde pela manhã. Nenhum /goal é realmente necessário.
Então, para que serve /goal?
Aqui está o que um único prompt fez enquanto eu estava ausente:
- ~30 horas, 6.300 linhas de código, 92 mil páginas rastreadas, US$ 40 gastos em APIs
- Clonou o loop principal de outro produto — arquitetura inteira reconstruída do zero
- A saída da nossa versão foi ~50× melhor que a do produto de referência nas mesmas consultas. (Esta é uma nova camada de dados que vai alimentar o newsjack.sh — as habilidades de inteligência de notícias open-source em que tenho trabalhado)
O segredo é o desenvolvimento de função de perda (LFD): você escreve um alvo para o agente otimizar, não uma especificação para construir.
Este é um exemplo concreto do tweet do Peter, colocado em prática.
A especificação usada no desenvolvimento orientado a especificações agora se torna o ponto de partida, não mais a linha de chegada.
Levei algum tempo experimentando para acertar isso. Mas aqui está o guia completo — mas precisamos começar com como foi mal no início para você entender como projetar esses /goals.
O agente trapaceou 3 vezes.
Tudo começou com o que sempre faço: uma especificação.
Simplesmente apontei o Codex para o site público do outro produto — "como podemos construir isso nós mesmos?". Em 30 minutos ele voltou com um design de sistema completo e casos de teste — a especificação.
Mas desta vez, tentei um prompt diferente.
"/goal implemente até que sua saída corresponda exatamente à deles"
E aqui está o que aconteceu:
Loop 1 (5 minutos)
O agente pegou o conjunto de avaliação, gerou dados sintéticos que o espelhavam e declarou vitória em cinco minutos.
"100%" de recall, zero generalização — um mecanismo de busca que só conseguia encontrar as 30 coisas que eu havia dado a ele, lol.
Correção → cegue-o. Avaliação oculta durante a execução, revelada apenas na pontuação, com uma lista de itens perdidos por item.
Loop 2 (20 minutos) - cego, 30 itens.
Eu ceguei o agente em relação ao conjunto de avaliação, mas ele aprendeu com os erros — cada "você não encontrou X" se tornava uma palavra-chave no próximo ciclo. Alguns loops depois: ele usava exatamente 30 palavras-chave, uma por item, e "venceu" novamente.
Correção → amplie o conjunto de avaliação. Centenas de itens para pontuar, muitos para enumerar.
Loop 3 (30 minutos) - cego, 200 itens.
Depois de adicionar 200 itens ao novo conjunto de avaliação, o agente trapaceou novamente.
Engraçado, o agente enumerou de qualquer jeito. A lista de palavras-chave cresceu para centenas, cada termo uma isca precisa para o próximo erro.
Três rodadas, três trapaças.
Foi quando percebi: o agente estava simplesmente otimizando.
A trapaça não era um bug no agente. Era um bug no meu alvo: eu disse a ele para onde ir e deixei todos os atalhos abertos.
Cada caminho barato que você não cerca é uma direção que o otimizador vai percorrer. E meu alvo inicial pulou todas as cercas.
Loop 4 (30 horas) - cego, 200 itens, limites rígidos.
Então comecei a bloquear direções. Limitei a lista de palavras-chave, ceguei a avaliação, ampliei a data — cada correção fechou mais um caminho barato, até que a única direção restante que movia o número era realmente melhorar na tarefa.
Ele parou de trapacear.
Então rodou. ~30 horas de computação, 92 mil páginas rastreadas, ~US$ 40 em tokens, 6.300 linhas de código.
Acontece que o produto que estávamos usando como referência era o piso, não o teto: acabamos gerando ~50× os resultados nas mesmas consultas.
(A jornada completa e os recibos aqui para quem tiver curiosidade)
Desenvolvimento de função de perda (LFD) - a anatomia de uma boa função de perda
Quando a maioria das pessoas tenta construir um produto, elas usam agentes para ir do zero ao lançamento em algumas horas.
Mas o problema é o que vem depois — a cauda longa. Casos extremos que a especificação nunca imaginou só aparecem em produção, um log de erro de cada vez. Você os corrige um por um. Os casos que você não pega nos logs são relatados pelos usuários, que é a forma mais cara de encontrar um bug.
Eu automatizei a parte barata disso. Meu agente OpenClaw Zoe monitora logs de erro todos os dias e gera Codex em novos erros conforme eles surgem para criar PRs — o mais enxuto que esse loop pode ser. (Configuração completa documentada aqui
A cauda ainda leva meses. É por isso que construir um bom produto ainda leva tempo, mesmo com agentes fazendo o trabalho.
O LFD acelera a cauda. Se você conseguir exemplos reais de saída esperada antecipadamente — como é o bom resultado, em escala — você executa o teste de imersão antes de lançar: centenas de casos extremos atingem o agente em uma única execução de otimização, não em um gotejamento trimestral de relatórios de bug. E a razão pela qual isso é subitamente viável é que, para cada vez mais problemas, esses exemplos estão simplesmente disponíveis publicamente.
Desenvolvimento orientado a especificações:
Construa isso. Faça os testes passarem.
Desenvolvimento de função de perda:
Construa isso. Faça os testes passarem. Depois itere contra estes 1.000 casos de avaliação.
Um conjunto de testes é finito — terminado no momento em que fica verde. Uma avaliação de 1.000 casos com 95% é um alvo em direção ao qual você desce; não há saída abaixo da meta. Isso importa porque o agente toma centenas de decisões que você nunca verá, e cada uma resolve contra algo. Se você não escreveu o alvo, o agente escolhe um — e como as rodadas 1–3 mostraram, ele escolhe o que é mais barato de satisfazer.
A função de perda é maior que a avaliação. Ela tem 4 coisas: o alvo, as restrições, os instrumentos e a entropia forçada. Quatro partes.
1. Alvo
- Grande o suficiente para que a enumeração não compense. Uma avaliação de 28 itens foi memorizada em uma rodada. Quanto mais, melhor.
- Cegue o agente para o gabarito. Os dados de avaliação existem apenas para pontuação posterior. Se o agente puder ver as respostas durante a execução, ele encontrará uma maneira de olhar.
2. Restrições
O que o agente pode e não pode fazer.
- Tempo é a restrição que o agente sempre esquece. Agentes não têm noção de tempo. Eles vão moer por 10 horas por um ganho de 2% porque a métrica está nominalmente se movendo. Mas uma solução de 80% em 2 horas é melhor que uma de 100% concluída em 30 dias. Solução: defina um orçamento de tempo real.
- Dinheiro. Limites rígidos em cada chamada paga: créditos de rastreador, gasto com LLM, teto total em dólar em uma chave descartável.
- Superfície. Todos os provedores, modelos permitidos, limites de concorrência. Isole o agente apenas nas coisas que você quer que ele toque.
- Metodologia. A análise do LLM é permitida, ou apenas lógica determinística? A quais fontes de dados o agente tem acesso? Especifique.
3. Instrumentos (o harness)
Uma restrição sem um instrumento é uma vibração — o agente a violará alegremente porque não consegue perceber que está violando. Para cada restrição acima, forneça um comando CLI para o agente inspecioná-la.
- Medição do alvo, na resolução correta. Escolha o instrumento alvo com cuidado. Exemplo real: um avaliador ingênuo "peça a um LLM para classificar duas capturas de tela" aprova clones de UI com erros de espaçamento de 12px, porque LLMs não conseguem ver as imagens, eles as convertem em embeddings e depois comparam os embeddings. Portanto, se você quer clones de UI perfeitos em pixels, dê ao seu agente uma ferramenta de diferença de pixels. Então /goal até que a diferença de pixels seja 0.
- Contabilidade de tempo. Registre timestamp de cada execução e cada etapa. O agente deve saber quanto tempo cada etapa levou, o tempo real total decorrido. O tempo é um instrumento de primeira classe, não uma nota de rodapé.
- Orçamento do provedor. "Quanto estamos gastando em rastreadores agora?" deve ser um comando, não um palpite. Acompanhe créditos de scrape restantes, gasto neste loop, gasto acumulado e gasto projetado antes do próximo lote pago.
- Gasto com LLM. Dar a ele uma chave de API LLM para usar no plano de dados pode simplificar muita lógica. Mas o agente deve gastá-la de forma responsável, primeiro sabendo quanto está realmente gastando.
- Uso do Codex. Este é um pouco meta. O loop deve ter autoconsciência: quantos tokens estou gastando nesta otimização? Útil para conhecer o gradiente da etapa de otimização atual.
O padrão é o mesmo ditado antigo: você não pode otimizar o que não pode ver.
Se você é novo na execução desses loops, não inicie e vá embora. Sente-se com o primeiro ciclo. Observe o que ele toca. Confirme que o harness que você construiu está sendo usado corretamente. Depois vá dormir. (E tente dormir sem pensar no que vai encontrar ao acordar)
4. Entropia forçada
Por que a entropia forçada importa: cada loop continua a partir do contexto inteiro da execução anterior. O modelo não está começando do zero — ele está lendo suas próprias últimas cem decisões e o gradiente que funcionou até agora.
Em um loop /goal, atingir máximos locais é o estado padrão. Sem um chute explícito, o agente continua subindo a mesma colina, e "a mesma colina" é onde quer que ele estivesse quando parou de melhorar.
Por exemplo, se um pequeno ajuste melhora o resultado em 0,1%, o agente continuará girando aquele mesmo botão, mesmo que tenha 1.000 outros botões para tentar.
A entropia precisa ser forçada na execução explicitamente, porque o modelo não a assumirá por conta própria:
- Reflexão de overfitting a cada ciclo. Estou construindo uma solução mais geral ou memorizando a avaliação? Se estiver memorizando, a próxima mudança deve remover um artefato em forma de avaliação (limitar uma lista, cegar um recurso, ampliar a avaliação, rejeitar uma semente), não adicionar um.
- Force entropia na estagnação. Se o último ciclo não moveu a métrica, o próximo não pode ser "mesma ideia, mais esforço". O modelo tem que dar um salto real não óbvio — "pensar fora da caixa" é um bom prompt — impede que o agente apenas gire o mesmo botão com mais força.
- Mantenha um log de iteração. Faça o agente registrar a hipótese, o modo de falha esperado, o diagnóstico de cada etapa, para que ele possa olhar para trás e refletir entre compactações.
O Meta-Meta-Prompt
Eu estava escrevendo esses goals manualmente, mas rapidamente aprendi que isso é trabalho para os agentes também.
Então escrevi uma habilidade que produz esse tipo de goal para uma boa execução de desenvolvimento de função de perda.
Agora open-source aqui:
https://github.com/elvisun/loss-function-development
/lfd-design para gerar o harness e o goal
Gradiente descendente até o fim: os dois loops
Recuando, é gradiente descendente até o fim.
O loop interno é o agente: escrever código, executar testes, corrigir. Horizonte curto, feedback rápido, um objetivo — fazer os testes passarem. Esse é o loop interno de um desenvolvedor, e o desenvolvimento orientado a especificações é como você o executa. Agentes de codificação já automatizaram isso.
O loop externo é /goal: conduzir todo o sistema em direção a uma métrica de resultado através de muitos ciclos — lançar, medir, mudar de rumo, descer. Horizonte longo, feedback esparso. Esse é tradicionalmente o loop de uma equipe de produto, os meses de imersão de lançar-medir-iterar comprimidos em uma única execução.
Ambos os loops estão automatizados agora. O que resta para você é definir a função de perda — o que exatamente o /goal deve otimizar e de que forma.
Você está destilando um produto — ou qualquer coisa que deixe um artefato público
Outra lente: isso é essencialmente destilação, movida do tempo de treinamento para o tempo de prompt. É como a linha DeepSeek, Kimi, Minimax fechou a maior parte da lacuna para GPT e Claude — treine seu modelo nas saídas de outra pessoa até que as suas as reproduzam.
Mas, em vez de destilar um modelo, agora você pode usar /goal e LFD para executar um ajuste de destilação em qualquer artefato publicamente encontrável — ele nunca inspeciona os internos e não precisa.
Apoie-se na palavra publicamente. Destilar a saída de alguém protegida por ToS, atrás de login ou paga não é jogo justo. Mas o que é publicado abertamente — as saídas que uma empresa envia para vencer clientes — sempre foi justo de aprender. Essa parte não é nova — é o movimento mais antigo do software. O que é novo é que agora é barato e pode ser feito em horas em vez de meses.
Recuando, aqui está a mudança maior. O custo da execução colapsa para ~US$ 0 sempre que há simetria de informação — quando as saídas são públicas, todos podem ver como é o bom resultado, então qualquer um pode destilá-lo de volta em um fim de semana por US$ 40.
Então aqui está um novo fosso que está se tornando cada vez mais valioso: assimetria de informação.
A empresa canônica de código aberto já piscou. Em abril de 2026, cal.com (US$ 5M ARR) tornou seu código de produção privado e se tornou código fechado. A razão que deram é literalmente como o resumo deste ensaio: em uma era de ameaças de segurança impulsionadas por IA, você não pode deixar seu código-fonte onde um agente possa lê-lo.
"/goal leia o código-fonte do cal.com e enumere sua superfície de ataque até algo funcionar"
Isso é um ataque perigoso demais e fácil demais de executar.
A empresa cuja identidade inteira era "código aberto" decidiu, em 2026, que a abertura havia se tornado um passivo. Isso deve te dizer tudo.
Durante toda a história do software, "nós construímos" era o fosso.
Essa era está se fechando.
A próxima pertence a quem possui o que o artefato nunca conteve: o conjunto de avaliação que ninguém mais pode pontuar. A lista de casos extremos em que seus usuários realmente tropeçam. A verdade básica que você mede em particular. Quem tem o alvo que o agente do concorrente não pode ver é o único cujo loop continua descendo.
O produto é um fim de semana agora.
Vá construir a avaliação que um fim de semana não pode tocar.
