99% das pessoas estão a usar /goal e loops de forma errada.
O hype que ouvem é sobre "agentes autónomos com loops de longa duração": aponta para uma tarefa, sai, volta e encontra código a funcionar.
Mas os melhores engenheiros de agentes já fazem isso há 6 meses sem /goal (desde que o GPT-5.2 e o Opus 4.5 surgiram). Chama-se engenharia de harness + desenvolvimento orientado por especificações:
- constrói um harness para o agente observar o problema
- escreve uma especificação rigorosa com todos os casos de teste
- deixa o Codex ou o Claude Code iterar sem supervisão até cumprir cada um.
Eu lanço estes processos durante a noite constantemente — 2 a 5 horas por execução. Em abril, um deles resolveu um bug de cache de build do Turbo no nosso monorepo da Vercel e estava tudo verde de manhã. Não é preciso /goal.
Então para que serve realmente o /goal?
Isto é o que um único prompt fez enquanto eu estava ausente:
- ~30 horas, 6.300 linhas de código, 92 mil páginas rastreadas, 40$ gastos em APIs
- Clonou o loop central de outro produto — arquitetura inteira reconstruída de raiz
- A nossa versão produziu resultados ~50× melhores que o produto de referência nas mesmas consultas. (Isto é uma nova camada de dados que vai alimentar o newsjack.sh — as skills de inteligência de notícias open-source em que tenho trabalhado)
O segredo é o desenvolvimento de função de perda (LFD): escreves para o agente um alvo para otimizar, não uma especificação para construir.
Isto é um exemplo concreto do tweet do Peter, posto em prática.
A especificação usada no desenvolvimento orientado por especificações torna-se agora o ponto de partida, deixando de ser a linha de meta.
Precisei de alguma experimentação para acertar isto. Mas aqui está o manual completo — mas temos de começar por como correu mal primeiro para perceberes como desenhar estes /goals.
O agente enganou-se 3 vezes.
Tudo começou com o que faço sempre: uma especificação.
Simplesmente apontei o codex para o site público do outro produto — "como podemos construir isto 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 implementa até a tua saída corresponder exatamente à deles"
E eis o que aconteceu:
Loop 1 (5 minutos)
O agente agarrou no conjunto de avaliação, gerou dados de seed que o espelhavam e declarou vitória em cinco minutos.
"100%" de recall, zero generalidade — um motor de busca que só conseguia encontrar as 30 coisas que lhe tinha dado lol.
Correção → cegá-lo. Avaliação oculta durante a execução, revelada apenas na pontuação, com uma lista de falhas por item.
Loop 2 (20 minutos) - cego, 30 itens.
Ceguei o agente do conjunto de avaliação, mas ele aprendeu com as falhas — cada "não encontraste X" tornava-se uma palavra-chave no ciclo seguinte. Poucos loops depois: usava exatamente 30 palavras-chave, uma por item, e "ganhou" outra vez.
Correção → alargar o conjunto de avaliação. Centenas de itens para pontuar, demasiados para enumerar.
Loop 3 (30 minutos) - cego, 200 itens.
Depois de adicionar 200 itens ao novo conjunto de avaliação, o agente enganou-se novamente.
Engraçado que o agente enumerou na mesma. A lista de palavras-chave cresceu para centenas, cada termo uma isca precisa para a próxima falha.
Três rondas, três enganos.
Foi aí que percebi: o agente estava simplesmente a otimizar.
O engano não era um bug no agente. Era um bug no meu alvo: disse-lhe para onde ir e deixei todos os atalhos abertos.
Cada caminho barato que não fechas é uma direção que o otimizador vai percorrer a alta velocidade. E o meu alvo inicial saltou todas as barreiras.
Loop 4 (30 horas) - cego, 200 itens, limites rígidos.
Então comecei a bloquear direções. Limitar a lista de palavras-chave, cegar a avaliação, alargar a data — cada correção fechava mais um caminho barato, até que a única direção que fazia o número subir era melhorar genuinamente na tarefa.
Ele deixou de enganar.
Depois correu. ~30 horas de computação, 92 mil páginas rastreadas, ~40$ em tokens, 6.300 linhas de código.
Acontece que o produto que estávamos a usar como referência era o chão, não o teto: acabámos por gerar ~50× os resultados nas mesmas consultas.
(A jornada completa e os recibos aqui para os curiosos)
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, usam agentes para ir do zero ao lançamento em poucas horas.
Mas a dificuldade está no que vem depois — a cauda longa. Casos extremos que a especificação nunca imaginou surgem apenas em produção, um registo de erro de cada vez. Tu corriges um a um. Os casos que não apanhas nos registos são reportados por utilizadores, que é a forma mais cara de encontrar um bug.
Eu automatizei a parte mais barata disto. O meu agente OpenClaw Zoe monitoriza o registo de erros todos os dias e inicia o Codex para novos erros à medida que aparecem, criando PRs — o loop mais apertado possível. (Configuração completa documentada aqui
A cauda ainda leva meses. É por isso que construir um bom produto ainda demora tempo, mesmo com agentes a fazer o trabalho.
O LFD acelera a cauda. Se conseguires obter exemplos reais de saída esperada antecipadamente — o que é "bom" à escala — executas o soak test antes de lançares: centenas de casos extremos atingem o agente numa única execução de otimização, não num gotejar trimestral de relatórios de bugs. E a razão pela qual isto é subitamente viável é que, para cada vez mais problemas, esses exemplos estão simplesmente disponíveis publicamente.
Desenvolvimento orientado por especificações:
Constrói isto. Faz os testes passar.
Desenvolvimento de função de perda:
Constrói isto. Faz os testes passar. Depois itera contra estes 1.000 casos de avaliação.
Um conjunto de testes é finito — termina no momento em que fica verde. Uma avaliação de 1.000 casos a 95% é um alvo em direção ao qual desces; não há saída abaixo do patamar. Isso é importante porque o agente toma centenas de decisões que nunca verás, e cada uma resolve-se contra algo. Se não escreveste o alvo, o agente escolhe um — e como as rondas 1–3 mostraram, escolhe o que é mais barato de satisfazer.
A função de perda é maior do que a avaliação. Tem 4 coisas — o alvo, as restrições, os instrumentos e a entropia forçada. Quatro peças.
1. Alvo
- Grande o suficiente para que a enumeração não compense. Uma avaliação de 28 itens foi memorizada numa ronda. Quanto mais, melhor.
- Cega o agente para a chave de respostas. Os dados de avaliação existem apenas para pontuação posterior. Se o agente vir as respostas durante a execução, encontrará uma maneira de as consultar.
2. Restrições
O que o agente pode e não pode fazer.
- O tempo é a restrição que o agente sempre esquece. Os agentes não têm noção do tempo. Vão trabalhar 10 horas para uma melhoria de 2% porque a métrica está nominalmente a subir. Mas uma solução de 80% em 2 horas é melhor do que uma de 100% concluída em 30 dias. Solução: define um orçamento de tempo real.
- Dinheiro. Limites rígidos em cada chamada paga: créditos de crawler, gastos de LLM, teto total em dólares numa chave descartável.
- Superfície. Todos os fornecedores, modelos permitidos, limites de concorrência. Isola o agente apenas às coisas que queres que ele toque.
- Metodologia. É permitida análise LLM, ou apenas lógica determinística? A que fontes de dados o agente tem acesso? Explicita tudo.
3. Instrumentos (o harness)
Uma restrição sem um instrumento é uma vibe — o agente vai violá-la alegremente porque não consegue perceber que a está a violar. Para cada restrição acima, cria um comando CLI para o agente inspecionar.
- Medição do alvo, na resolução correta. Escolhe o instrumento de alvo cuidadosamente. Exemplo real: um juiz ingénuo "pede a um LLM para classificar duas screenshots" aprova clones de UI com erros de espaçamento de 12px, porque os LLMs não conseguem realmente ver as imagens, convertem-nas em embeddings e depois comparam os embeddings. Portanto, se queres clones de UI com pixel perfeito, dá ao teu agente uma ferramenta de diferença de pixels. Depois /goal até a diferença de pixels ser 0.
- Contabilidade de tempo. Regista o tempo de cada execução e cada passo. O agente deve saber quanto tempo cada passo demorou, o tempo total decorrido. O tempo é um instrumento de primeira classe, não uma nota de rodapé.
- Orçamento do fornecedor. "Quanto estamos a gastar em crawlers agora?" deve ser um comando, não um palpite. Controla os créditos de scrape restantes, o gasto neste loop, o gasto cumulativo e o gasto projetado antes do próximo lote pago.
- Gasto LLM. Dar ao agente uma chave de API LLM para usar no plano de dados pode simplificar muita da lógica. Mas o agente deve gastá-los de forma responsável, sabendo primeiro quanto está realmente a gastar.
- Uso do Codex. Este é um pouco meta. O loop deve ter autoconsciência: quantos tokens estou a gastar nesta otimização? Útil para saber o gradiente do passo de otimização atual.
O padrão é o velho ditado: não podes otimizar o que não podes ver.
Se és novo na execução destes loops, não os lances e saias. Senta-te com o primeiro ciclo. Observa o que ele toca. Confirma que o harness que construíste está a ser usado corretamente. Depois vai dormir. (E tenta adormecer sem pensar no que vais encontrar quando acordares)
4. Entropia forçada
Porque é que a entropia forçada é importante: cada loop continua a partir do contexto inteiro da execução anterior. O modelo não está a começar de novo — está a ler as suas próprias últimas cem decisões e o gradiente que funcionou até agora.
Num loop /goal, atingir máximos locais é o estado padrão. Sem um estímulo explícito, o agente continua a subir 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 vai continuar a rodar esse único botão, mesmo que tenha 1000 outros botões para experimentar.
A entropia precisa de ser forçada na execução explicitamente, porque o modelo não a criará sozinho:
- Reflexão sobre o overfit em cada ciclo. Estou a construir uma solução mais geral, ou a memorizar a avaliação? Se estiver a memorizar, a próxima alteração deve remover um artefacto em forma de avaliação (limitar uma lista, cegar uma funcionalidade, alargar a avaliação, rejeitar uma seed), não adicionar um.
- Forçar entropia em caso de estagnação. Se o último ciclo não moveu a métrica, o próximo não pode ser "mesma ideia, com mais força". O modelo tem de dar um salto real não óbvio — "pensar fora da caixa" é um bom prompt - impede o agente de apenas rodar o mesmo botão com mais força.
- Manter um registo de iteração. Faz o agente registar a hipótese, o modo de falha esperado, o diagnóstico de cada passo, para que possa olhar para trás e refletir entre compactações.
O Meta-Meta-Prompt
Eu escrevia estes goals manualmente, mas rapidamente aprendi que isso é trabalho para os agentes também.
Por isso, escrevi uma skill que produz este tipo de goals 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é ao fim: os dois loops
Recuando, é gradiente descendente até ao fim.
O loop interno é o agente: escrever código, executar testes, corrigir. Horizonte curto, feedback rápido, um objetivo — fazer os testes passar. Esse é o loop interno de um programador, e o desenvolvimento orientado por especificações é como o executas. Os agentes de programação já o automatizaram.
O loop externo é o /goal: conduzir todo o sistema em direção a uma métrica de resultado através de muitos ciclos — lançar, medir, mudar de estratégia, descer. Horizonte longo, feedback espaçado. Esse é tradicionalmente o loop de uma equipa de produto, os meses de lançar-medir-iterar comprimidos numa única execução.
Ambos os loops estão agora automatizados. O que resta para ti é definir a função de perda — o que exatamente o /goal deve otimizar e de que forma.
Estás a destilar um produto — ou qualquer coisa que deixe um artefacto público
Outra perspetiva: isto é essencialmente destilação, movida do tempo de treino para o tempo de prompt. É como a linha DeepSeek, Kimi, Minimax fechou a maior parte da distância para o GPT e o Claude — treinar o teu modelo nas saídas de outros até que as tuas as reproduzam.
Mas em vez de destilar um modelo, podes agora usar /goal e LFD para ajustar a destilação a qualquer artefacto publicamente encontrável — nunca inspeciona os internos e não precisa.
Apoia-te na palavra publicamente. Destilar saídas protegidas por ToS, atrás de login ou pagas não é legítimo. Mas o que é publicado abertamente — as saídas que uma empresa lança para conquistar clientes — sempre foi legítimo 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 ~$0 onde quer que haja simetria de informação — quando as saídas são públicas, todos podem ver como é o "bom", por isso qualquer um pode destilá-lo num fim de semana por 40$.
Portanto, aqui está um novo fosso que se está a tornar cada vez mais valioso: assimetria de informação.
A empresa open-source canónica já piscou o olho. Em abril de 2026, a cal.com (5M$ ARR) tornou o seu código de produção privado e tornou-se closed-source. A razão que deram lê-se literalmente como o resumo deste ensaio: numa era de ameaças de segurança impulsionadas por IA, não podes deixar o teu código fonte onde um agente o possa ler.
"/goal lê o código fonte do cal.com e enumera a sua superfície de ataque até algo funcionar"
Isso é um ataque demasiado perigoso e demasiado fácil de executar.
A empresa cuja identidade inteira era "open source" decidiu, em 2026, que a abertura se tinha tornado um passivo. Isso deve dizer-te tudo.
Durante toda a história do software, "nós construímo-lo" foi o fosso.
Essa era está a fechar.
A próxima pertence a quem possui o que o artefacto nunca conteve: o conjunto de avaliação que mais ninguém consegue pontuar. A lista de casos extremos em que os teus utilizadores realmente tropeçam. A verdade fundamental que medes em privado. Quem tem o alvo que o agente do concorrente não consegue ver é o único cujo loop continua a descer.
O produto é um fim de semana agora.
Vai construir a avaliação que um fim de semana não consegue tocar.
