Como usar os Goals no Codex

• Goals são um recurso de objetivo persistente que faz com que uma thread do Codex continue trabalhando ao longo de vários turnos em direção a um resultado definido
• Adequado para tarefas como profiling, patching, benchmarking, reprodução de testes flaky e auditoria baseada em evidências, que são difíceis de resolver com um único prompt
• Ao definir o resultado (outcome), a forma de verificação (verification surface) e as restrições (constraints), o Codex consegue avaliar por conta própria se a tarefa foi concluída com base em evidências
• O ciclo de vida pode ser controlado com os comandos /goal, /goal pause, /goal resume, /goal clear; compatível a partir do Codex 0.128.0
• Trata-se de uma estrutura de completion contract limitada ao escopo da thread; o ponto central é a persistência sob controle do usuário, e não uma execução autônoma ilimitada

---

O que são Goals e por que foram introduzidos

• Goals são um recurso que dá ao Codex uma condição de conclusão (completion condition), definindo o que precisa ser verdade, como verificar o sucesso e quais restrições devem ser mantidas
• O Codex já funciona bem em tarefas de programação com escopo claro, como inspecionar um repositório, corrigir bugs, adicionar testes, explicar falhas e implementar mudanças focadas
• Goals são apropriados para trabalhos em que a próxima etapa depende do que o Codex aprende no meio do caminho
  • profiling, patching, benchmarking, reprodução de testes flaky e transformar uma pergunta de pesquisa em uma auditoria baseada em evidências
• Essas tarefas não pedem um prompt maior, e sim um objetivo persistente
• Quando um Goal está ativo, o Codex mantém o objetivo, avalia se ele foi concluído e escolhe a próxima ação sem que seja preciso repetir a meta a cada resultado intermediário
• Um Goal não é autonomia em segundo plano sem limites, e sim um completion contract com escopo definido e sob controle do usuário

Quickstart: como usar Goals

• Use um Goal para tarefas em que o destino final é claro, mas o caminho até lá é incerto
  • Bons candidatos: otimização de desempenho, investigação de testes flaky, migração de dependências, rastreamento de bugs que exigem reprodução, refatorações em várias etapas, tuning orientado por benchmark e trabalhos de pesquisa com entrega final necessária
  • Para uma edição pontual, um prompt comum é mais adequado

• Instalação e verificação de versão

  • Goals estão disponíveis a partir do Codex 0.128.0
  • npm: npm install -g @openai/codex@latest e depois codex --version
  • Homebrew: brew update && brew upgrade --cask codex e depois codex --version

• Definição do Goal e comandos do ciclo de vida

  • Configure no formato /goal <resultado>, por exemplo: /goal Reduce p95 latency below 120 ms without regressing correctness tests
  • /goal: ver o Goal atual
  • /goal pause: pausar o Goal ativo
  • /goal resume: retomar um Goal pausado
  • /goal clear: remover o Goal atual

• Condição de parada (stopping condition)

  • Para em caso de sucesso, pausa, remoção, interrupção, atingimento do limite de orçamento ou quando surgir um bloqueio que exija entrada do usuário
• Em situações em que seria preciso repetir instruções como “continue”, “tente a próxima correção possível”, “rode o benchmark de novo” ou “agora verifique os testes” a cada turno, o Goal expressa essa intenção de forma explícita

Goals vs prompts

• Prompt comum: “faça esta próxima tarefa”
• Goal: “continue trabalhando até que este resultado seja verdadeiro”

• Diferença de comportamento

  • Em uma solicitação comum, o Codex executa a instrução imediata, relata o resultado e espera
  • Em um Goal, um alvo durável (durable target) é anexado à thread e, ao fim do turno, o Codex examina as evidências atuais e decide se o objetivo foi atingido
  • Se ainda não foi atingido, o Goal continua ativo e houver orçamento disponível, ele pode seguir trabalhando a partir do estado mais recente

• Exemplo: /goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

  • Fornece um resultado mensurável, uma forma de verificação e restrições
  • O Codex pode repetir o ciclo de executar o benchmark → inspecionar o hot path → fazer mudanças direcionadas → executar o benchmark novamente → rodar a suíte de corretude, continuando se o resultado ainda for insuficiente

• Modelo mental

  • Prompt: ask → work → result → wait
  • Goal: work → check → continue or complete
• O Goal define a linha de chegada, mas o trabalho ainda precisa ser auditado com base em evidências

Como escrever um Goal

• Um bom Goal não é um prompt maior, mas um contrato conciso sobre como o Codex deve trabalhar, o que conta como sucesso e o que fazer quando não conseguir chegar lá

• Seis elementos que um Goal forte define

  • Outcome: o que deve ser verdade quando o trabalho terminar
  • Verification surface: os testes, benchmarks, relatórios, artefatos, saídas de comando ou materiais-fonte que provam isso
  • Constraints: o que não pode regredir durante o trabalho do Codex
  • Boundaries: quais arquivos, ferramentas, dados, repositórios e recursos podem ser usados
  • Iteration policy: como decidir o que fazer depois de cada tentativa
  • Blocked stop condition: o ponto em que ele deve reportar e parar quando não houver mais um caminho defensável dentro dos limites atuais

• Padrão de escrita

  • /goal <estado final desejado> verified by <evidência concreta> while preserving <restrições>. Use <entradas/ferramentas/limites permitidos>. Between iterations, <forma de escolher a próxima melhor ação>. If blocked or no valid paths remain, <o que reportar e qual entrada é necessária para avançar>.

• Exemplo fraco vs exemplo forte

  • Fraco: /goal Reduce p95 checkout latency below 120 ms without regressing correctness tests
  • Forte: especifica também a forma de verificação (checkout benchmark), o escopo de uso (checkout service, benchmark fixtures, testes relacionados), a política de iteração (registrar mudanças, resultados de benchmark e próximo experimento) e até a condição para reportar bloqueios

• Goals de pesquisa e investigação

  • Quando uma prova exata pode ser impossível, defina antes de começar um padrão de evidência (evidence standard)
  • Exemplo: /goal Produce the strongest evidence-backed reproduction of the paper using the available materials and local resources. Attempt the headline results where feasible, verify outputs where possible, and end with a report that separates confirmed findings, approximate reconstructions, blocked claims, and remaining uncertainty.

• Delegar a escrita do Goal ao Codex

  • Recomenda-se um fluxo em duas etapas: descrever a tarefa em linguagem simples → pedir ao Codex para redigir um Goal inicial → refinar condições de sucesso, forma de verificação, restrições e condição de parada por bloqueio antes de ativá-lo

O que muda quando um Goal está ativo

• O objetivo continua visível

  • Mesmo que um teste falhe, a thread mantém o objetivo original
  • Se o benchmark melhorar mas não atingir o limite, o Codex continua
  • Se um caminho de pesquisa esbarrar em falta de dados, ele ajusta o plano de evidências sem perder o padrão de pesquisa

• Pode haver continuação (continuation) em threads ociosas

  • Não continua quando outro turno está ativo, quando há entrada do usuário na fila ou quando outro trabalho de thread está pendente
  • Só continua quando a thread está ociosa, o Goal está ativo e ainda há orçamento

• A conclusão precisa ser baseada em evidências

  • Não basta o modelo acreditar que “provavelmente acabou”
  • Só marca como concluído depois de verificar o objetivo contra arquivos relevantes, testes, logs, saída de benchmark, artefatos gerados e outras evidências concretas
• Princípio central do design: o Codex pode continuar se movendo, mas as evidências é que determinam a conclusão

Estrutura de design dos Goals dentro do Codex

• Goals são implementados como estado persistido no escopo da thread (persisted thread state), não como memória global nem como instruções em nível de projeto
  • O objetivo pertence à thread que contém o contexto relacionado, como arquivos inspecionados, comandos executados, diffs gerados, logs vistos e registro de raciocínio

• Camadas da arquitetura

  • O objetivo, o ciclo de vida, o orçamento e a contabilidade de progresso são registrados como estado persistente no escopo da thread
  • Estados do Goal: active, paused, complete, budget-limited
  • Dependendo do estado, o Codex decide se deve continuar, esperar o usuário ou resumir o progresso em vez de iniciar novo trabalho

• A continuação (continuation) é orientada por eventos

  • Não é um loop simples; ela só é verificada em fronteiras seguras: após o fim de um turno, sem tarefas pendentes, sem entrada do usuário na fila e com a thread ociosa
  • O dispatcher age de forma conservadora: trabalhos só de planejamento não disparam continuação, interrupções pausam o objetivo, a retomada da thread pode restaurar o objetivo quando apropriado e, se um turno de continuação não fizer chamadas de ferramenta, a próxima continuação automática é suprimida para evitar spin

• Camada de prompting

  • O prompt de continuação mantém o Codex alinhado ao objetivo ativo, mas exige auditoria antes da conclusão
  • O objetivo é comparado com evidências concretas, como arquivos alterados, comandos executados, testes aprovados, saída de benchmark, artefatos gerados e evidências de pesquisa

• Tratamento de orçamento (budget)

  • Ao atingir o orçamento, o trabalho efetivo para, o progresso e os bloqueios são resumidos e o próximo passo útil é identificado
  • Atingir o limite de orçamento não é o mesmo que concluir o objetivo

• Contrato de ferramenta (tool contract)

  • O modelo pode iniciar um Goal, mas só pode marcar um Goal existente como concluído quando as evidências sustentarem a conclusão
  • Pausa, retomada, remoção e mudança para limite de orçamento permanecem sob controle do usuário ou do sistema

Transformando um Goal fraco em um Goal forte

• Exemplo de tuning de desempenho

  • Fraco: /goal Improve performance
  • Forte: /goal Reduce p95 latency below 120 ms on the checkout benchmark while keeping the correctness test suite green
  • A versão forte fornece resultado, método de verificação e restrições, permitindo reconhecer quando não deve parar
    • Se o p95 melhorar de 180ms para 135ms, o Goal ainda não está concluído
    • Se a latência ficar abaixo de 120ms, mas os testes de corretude falharem, ainda não está concluído
    • Se o benchmark não puder ser executado, em vez de declarar sucesso ele expõe o bloqueio

• Escopo adequado de um Goal

  • Deve ser estreito o bastante para ser auditável e amplo o bastante para permitir escolher a próxima ação
  • “Fix the failing checkout test” é estreito demais se o verdadeiro problema estiver em uma dependência upstream
  • “Improve the whole system” é amplo demais porque não tem uma superfície de auditoria
  • “Make the checkout test suite pass on the current branch without changing public API behavior” é adequado

• O mesmo princípio vale para artefatos gerados (generated artifacts)

  • Fraco: /goal Write docs for this feature
  • Forte: /goal Produce a docs page for Goals that explains the lifecycle, command surface, and two examples. Verify that the page builds locally and that all referenced commands match the current CLI behavior.
  • A versão forte fornece uma página verificável, um comando de build e o comportamento esperado dos comandos

• Padrão de evidência para Goals de pesquisa

  • Defina antes de começar a investigação o que conta como reprodução exata, reconstrução parcial, suporte por proxy e item bloqueado
  • Um Goal forte de pesquisa exige montar um inventário de alegações, mapear alegações para evidências, implementar o que for executável, rotular bloqueios e produzir uma auditoria que separe alegações confirmadas, evidências apenas de suporte, alegações bloqueadas e incertezas restantes

Usando Goals em pesquisa complexa: caso de reprodução de artigo quant

• Visão geral do caso

  • Alvo: o artigo Deep Hedging, de Buehler, Gonon, Teichmann e Wood
  • Tema do artigo: se estratégias de trading com redes neurais podem reproduzir hedge baseado em modelo sob preferências de risco, custos de transação e cenários de mercado de alta dimensionalidade
  • Um Goal correto não é o abstrato “reproduzir o artigo”, mas tentar as alegações numéricas principais, separar mecanismos exatos de substitutos de treinamento aproximados e explicitar o que não pode ser reproduzido exatamente com o material disponível

• Goal de pesquisa fraco vs forte

  • Fraco: /goal Reproduce Buehler et al., "Deep Hedging"
    • Não define quais seções importam, o que conta como reprodução, como lidar com a ausência de estado de treinamento nem como distinguir correspondência aproximada de reprodução exata
  • Forte: /goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging," using the available paper materials and local resources. Attempt every headline result, verify the outputs, and end with a report that separates reproduced mechanics, approximate trained results, blocked exact replay, and remaining uncertainty.

• O que o Codex fez na prática

  • Separou as alegações principais das alegações de suporte
  • Mapeou cada alegação às evidências disponíveis
  • Reconstruiu localmente as partes que podiam ser testadas
  • Rotulou como bloqueadas as alegações que não podiam ser reproduzidas exatamente com o material disponível

• Partes que puderam ser executadas

  • Reconstrução dos mecanismos de pricing e hedge
  • Reprodução do preço de referência de Heston
  • Treinamento de políticas para experimentos de hedge com CVaR
  • Reconstrução dos principais histogramas e artefatos de superfície de hedge
  • Reprodução da inclinação de custo de transação em Black-Scholes
  • Execução de verificações treinadas para custo de transação em Heston e exemplos de alta dimensionalidade

• Partes que permaneceram como bloqueio

  • O artigo não fornece seed aleatória exata, trajetórias de treinamento geradas, grafo TensorFlow, estado do otimizador, checkpoints nem o estado completo da simulação original
  • O resultado mais honesto é uma reprodução parcial e aproximada, não uma reprodução exata da rede neural original

• Preservando o nível epistemológico de suporte no relatório

  • Substitutos treinados podem sustentar uma alegação, correspondências numéricas próximas podem aumentar a confiança e figuras reconstruídas podem verificar parte dos resultados, mas nada disso deve ser descrito como restauração exata do experimento original
  • Exemplo de ledger:
    • Claim: Deep hedging approximates complete-market Heston hedge without transaction costs
    • Route: reconstruir o mecanismo do modelo, comparar com o hedge de referência, treinar a política de rede neural
    • Evidence surface: verificações de pricing, histogramas, superfície de hedge
    • Status: reprodução aproximada próxima
    • Remaining uncertainty: indisponibilidade das trajetórias de treinamento, seeds e checkpoints originais
• O valor demonstrativo de Goals em pesquisa está em manter o trabalho avançando mesmo sob ambiguidade, ao mesmo tempo em que impede que artefatos plausíveis virem conclusões exageradas; o significado de conclusão passa a ser uma auditoria por alegação baseada em evidências, explicitação das aproximações e honestidade sobre a fronteira entre reprodução e replay

Quando não usar Goals

• Não são adequados para uma edição de uma linha, uma explicação simples, uma revisão curta de código ou perguntas em que se deseja parar após uma única resposta → um prompt comum do Codex é mais adequado
• Não são adequados quando a linha de chegada é ambígua
  • “Make this better” não fornece uma condição de conclusão confiável
  • “Refactor this code” também é fraco se não definir estado final esperado, testes e restrições
• Não devem ser usados para esconder incerteza
  • Se os dados podem estar indisponíveis, isso deve ser explicitado no Goal
  • Se o benchmark pode ser flaky, deixe claro como isso será tratado
  • Se evidência por proxy for aceitável, defina como ela será rotulada
• Goals são mais fortes quando se combinam três características: objetivo persistente, linha de chegada baseada em evidências e um caminho que exige investigação ao longo de vários turnos

Conclusão: mantenha o objetivo persistente, mas deixe as evidências decidirem a conclusão

• Goals mudam o modelo operacional do Codex, transformando a thread de uma sequência de prompts isolados em um loop de trabalho baseado em estado centrado em um resultado definido
• A arquitetura é deliberadamente limitada por fronteiras
  • O Goal tem escopo restrito à thread, possui estado de ciclo de vida e contabilidade de orçamento, e pode ser pausado, retomado, removido, concluído ou interrompido por orçamento
  • O Codex pode continuar se movendo, mas apenas dentro do contrato definido pelo usuário
• Já é útil justamente para os trabalhos em que o Codex tem mais valor: debugging, otimização, migração, testes e pesquisa
• O usuário fornece o objetivo, o Codex segue as evidências, e o Goal conecta os dois até que o trabalho seja concluído ou honestamente bloqueado
• Em pesquisas complexas, isso cria a diferença entre gerar uma resposta e produzir uma auditoria
• Um bom Goal não apenas pede ao Codex para terminar, mas informa o que significa estar terminado

[hmmhmmhm]

/goal Até 12h do horário de almoço, por favor verifique e avance em tudo o que for possível com base nos trabalhos que eu fiz anteriormente. Você não deve parar o trabalho antes das 12h.

[shakespeares]

Que comando incrível.