Título original: Um guia para /goal
Autor original: @dkundel, membro da equipe de relacionamento com desenvolvedores da OpenAI
Tradução: Peggy

Nota do editor: Este artigo é um resumo da experiência de uso da funcionalidade Codex 「goal mode / /goal」 pelo membro da equipe de relacionamento com desenvolvedores da OpenAI, Dominik Kundel. Ele discute não uma técnica comum de prompt, mas uma mudança de papel que está ocorrendo na ferramenta de programação AI: o Codex não é mais apenas um assistente de código que responde a comandos de uma única rodada, mas começa a se tornar um Agente de execução capaz de avançar continuamente em torno de objetivos claros.

No modo /goal, o que realmente importa não é escrever requisitos cada vez mais detalhados, mas definir padrões de saída claros e verificáveis para o Codex. Por exemplo: «Reduzir o tempo de implantação em 30%», «Cobertura de testes atingindo 100% de paridade», «LCP abaixo de 2,5 segundos». Esses indicadores permitem que o Codex avalie se a tarefa foi concluída e evitam que ele fique em um ciclo infinito de tentativa e erro em objetivos vagos. Ao mesmo tempo, o usuário precisa fornecer direções, ferramentas e um ambiente real suficiente para que o Codex possa medir o progresso, validar resultados, e não apenas concluir uma solução aparentemente viável localmente ou sob condições hipotéticas.

A artigo especialmente alerta que tarefas visuais são as mais propensas a fazer o Codex se perder em detalhes. Em vez de exigir «reprodução pixel a pixel 100%», é melhor decompor o objetivo visual em uma lista de funcionalidades, especificações do sistema de design e métricas de avaliação. Para tarefas de longo prazo, que duram horas ou até dias, também é necessário acompanhar continuamente por meio de commits, drafts de PR, documentos de progresso, atualizações no Slack ou chats paralelos, para evitar que o resultado final seja apenas uma série de mudanças não rastreáveis.

A inovação desta mensagem é que ela redefine o /goal como um «mecanismo de gerenciamento de tarefas de longo prazo». Quando a IA pode executar continuamente por dezenas ou centenas de horas, a capacidade do desenvolvedor também muda: não apenas fazer a IA gerar código, mas definir objetivos, estabelecer métricas, configurar o ambiente de execução e, por fim, revisar e refletir sobre o trabalho realizado. Em outras palavras, a programação com IA está evoluindo de «escrever prompts» para «gerenciar um executor de engenharia que trabalha continuamente».

A seguir, o texto original:

Lançamos o modo de objetivos (goal mode, ou /goal) para ajudar você a fazer o Codex avançar continuamente em direção a um resultado específico. Quando você define um objetivo, o Codex trabalhará até que o objetivo seja alcançado — seja em algumas horas, ou vários dias. Já houve casos de Codex trabalhando por mais de 120 horas seguidas em um mesmo objetivo.

O modo de objetivos é muito poderoso. Para maximizar seu uso, há 7 pontos importantes ao usar /goal.

Defina padrões claros e verificáveis

Ao ativar o modo de objetivos, o prompt que você insere pode servir como uma sugestão inicial, mas mais importante, ele se tornará o padrão de saída para determinar quando o objetivo foi atingido. O Codex verificará após cada rodada de trabalho: o objetivo foi concluído?

Portanto, seu prompt de objetivo não deve ser excessivamente longo, mas focar em um padrão claro: em que condições o objetivo será considerado alcançado.

Na maioria dos casos, um bom objetivo inclui uma métrica numérica clara para o modelo avaliar se foi atingido. Por exemplo:

«Reduzir o tempo de construção e implantação em 30%.»

«Migrar essa funcionalidade de TypeScript para Rust e atingir 100% de cobertura de testes.»

«Otimizar o scaffolding da aplicação para que o Largest Contentful Paint (medidor de velocidade de carregamento do conteúdo principal da página) fique abaixo de 2,5 segundos.»

Esse prompt nem sempre precisa incluir números, mas, geralmente, números facilitam o avanço nas etapas seguintes.

Se você ainda não sabe exatamente como definir seu objetivo, ou quer fazer uma sessão de brainstorming com o Codex antes de usar o modo de objetivos, não há problema em começar uma conversa normal e, quando estiver pronto para que o Codex execute, definir o objetivo com base na discussão anterior.

Você também pode editar o objetivo a qualquer momento: clicando no botão de editar na aplicação do Codex, ou usando /goal novamente no CLI.

Forneça orientações sempre que possível

Prompts como «Reduzir o tempo de construção e implantação em 30%» parecem impressionantes e podem levar o Codex a soluções criativas. Mas, se você já tem uma ideia geral de onde o problema está, esse tipo de prompt pode fazer o Codex se perder por caminhos errados.

Por isso, sempre que possível, é melhor orientar o Codex sobre onde começar a investigação, quais ferramentas usar, ou fornecer dicas adicionais para evitar que ele siga na direção errada.

Por exemplo, meu colega @reach_vb fez assim em uma experiência: ele disse ao Codex que poderia usar o Chrome para acessar o Google Colab, e explicou algumas restrições aceitáveis, como permitir que o Codex gere seus próprios conjuntos de dados ao treinar modelos.

Da mesma forma, se você quer reduzir o tempo de construção e já sabe onde o maior consumo de tempo ocorre, é melhor direcionar o prompt para essa área específica.

Outra abordagem é fazer o Codex inicialmente em modo de planejamento (plan mode), para que ele pesquise e crie um plano preliminar, registrando possíveis soluções. Depois, o objetivo pode fazer referência a esse plano.

Tornar o progresso mensurável

Se seu objetivo for ambicioso ou o Codex tiver várias maneiras de se aproximar dele, é fundamental fornecer ferramentas para medir o avanço.

Para algumas tarefas, isso é natural — como otimizar tempos de build ou aumentar cobertura de testes — porque o próprio Codex já consegue usar ferramentas relacionadas ou criá-las automaticamente.

Para outros objetivos, o melhor é fazer uma sessão de brainstorming com o Codex: quais ferramentas podem ajudar a verificar o progresso? Ou dar dicas para que ele saiba como confirmar se está se aproximando do objetivo. Por exemplo, criar uma ferramenta de comparação visual de diferenças entre duas capturas de tela, ou montar um conjunto de avaliação para o seu agente inteligente.

Já pedi ao Codex que reproduzisse componentes a partir de um vídeo, e ele criou uma ferramenta para comparar capturas de tela e verificar diferenças. Depois, ele continuou iterando essa ferramenta, adicionando diferentes modos de comparação.

Imagem: uma captura de tela gerada pelo Codex, usada para comparação visual entre dois quadros.

Dependendo da tarefa, você também deve considerar se há padrões adicionais que precisam ser medidos ou verificados. Caso contrário, o Codex pode achar que a tarefa acabou, quando na verdade ainda não.

Por exemplo, para «reprodução pixel a pixel» de uma interface, o Codex pode simplesmente recortar uma referência de design e embutir na página; ou, para atingir 100% de taxa de sucesso em testes, reduzir a cobertura de testes. Essas não são as formas que você realmente deseja.

Crie um ambiente real

Se você quer que o Codex avance de forma efetiva em direção ao objetivo, ele precisa rodar em um ambiente suficientemente realista.

Na prática, isso significa: se você quer otimizar tempos de implantação ou latência, o Codex deve ter acesso ao ambiente de implantação e testes, que deve simular o mais próximo possível o produção. Ou seja, usar a mesma stack tecnológica, as mesmas configurações, e bancos de dados semelhantes.

Por exemplo, já trabalhamos na otimização de tempos de build e implantação do developers.openai.com. Como usamos previews de implantação, o Codex pôde usar esses ambientes para fazer deploys e verificar logs. Mas o problema é que esses previews não eram idênticos ao ambiente de produção, pois alguns caminhos de build estavam desativados.

Por isso, o Codex acabou tendo que fazer deploy manualmente em um ambiente mais próximo do de produção, para realmente verificar os problemas.

Da mesma forma, você pode usar o recurso de computer use (capacidade do modelo de operar interfaces reais) para testar aplicações reais. Para otimizar problemas de desempenho no iOS, @dimillian chegou a usar dispositivos físicos, para obter o ambiente mais preciso possível.

Cuidado ao definir objetivos visuais

Dar ao Codex um objetivo visual, como «reproduzir 100% pixel a pixel essa interface», parece tentador. Mas, dependendo de como for configurado, isso pode gerar problemas.

Se você não fornecer orientações e restrições adequadas, o Codex pode se perder em detalhes, esquecendo o objetivo geral. Por exemplo, se a referência contém elementos gráficos, e você espera que o Codex gere esses elementos — seja ícones SVG ou imagens — ele pode gastar muito tempo tentando reproduzir exatamente esses materiais, ao invés de dividir o problema corretamente.

Além disso, o Codex precisa de ferramentas para fazer comparações visuais. Isso significa mais entradas de imagens, maior consumo de tokens, e ainda assim, não garante que ele consiga identificar melhorias realmente valiosas.

Por isso, objetivos visuais geralmente são melhores como contexto, e não como padrão único de sucesso. Você deve buscar outras formas de verificar se o objetivo foi atingido, como listas de funcionalidades, especificações de implementação, conformidade com o sistema de design, etc.

Acompanhe o progresso

Se o Codex trabalha horas ou dias em segundo plano, ou roda em outra máquina, é fácil perder de vista o que foi feito e onde está o progresso.

Algumas estratégias que ajudam:

· Fazer o Codex enviar commits em pontos-chave, e criar um draft de PR. Especialmente útil em sites com pré-visualizações de deploy.

· Fazer o Codex atualizar uma entrega para a gestão, como um arquivo HTML acessível no navegador, uma página publicada no Sites, um gráfico de progresso renderizado, ou um simples arquivo Markdown.

· Instruir o Codex a enviar atualizações de progresso em momentos importantes, por exemplo, enviando mensagens ao Slack ou outro canal.

· Usar outro chat para consultar o status. Você pode iniciar um /side para uma conversa paralela, que terá o contexto atual, mas será curta.

· Ou abrir uma nova conversa normal, fazer o Codex ler outro thread de objetivo, e perguntar. Se você automatizar verificações periódicas, essa abordagem fica ainda mais poderosa.

Limpe e confirme o resultado final

Ótimo, o objetivo foi atingido! Agora, é hora de entregar o resultado ao time e encerrar?

Normalmente, especialmente em tarefas de otimização, é útil fazer o Codex revisar e refletir sobre o que foi feito. Você pode usar /review para uma revisão local do código, mas também vale a pena pedir ao Codex que analise mais profundamente: quais caminhos tentou, quais funcionaram, quais não, e fazer uma limpeza no código final.

Como o Codex trabalha até atingir o objetivo, ele pode ter tentado métodos pouco eficazes ou até inválidos, que podem ficar no código final.

Defina um goal para sua próxima tarefa

A funcionalidade de objetivos do Codex é uma ferramenta extremamente poderosa para resolver desafios de engenharia. Mas só funciona bem se você fornecer o ambiente e as instruções corretas, para que ele possa chegar ao resultado de forma mais eficiente.

O que você já fez com /goal?

[Link do original]

Clique para conhecer as vagas na BlockBeats em ritmo de movimento

Participe do grupo oficial da BlockBeats no Telegram:

https://t.me/theblockbeats

Grupo de discussão no Telegram:

https://t.me/BlockBeats_App

Conta oficial no Twitter: https://twitter.com/BlockBeatsAsia