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

Nota do editor: Este artigo é uma síntese da experiência de uso da funcionalidade Codex «goal mode / /goal» pelo membro da equipe de Relações 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 atuar como um Agente executável que pode avançar continuamente em torno de um objetivo claro.

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 orientaçõ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 destaca especialmente 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 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 irreconhecíveis e não rastreáveis.

A inovação principal do artigo é redefinir o /goal como uma «mecanismo de gestão 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 basta fazer a IA gerar código, é preciso 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 potencial, 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 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: 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 é considerado realizado.

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.»

O 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, pedir que ele defina um objetivo com base na discussão anterior.

Você também pode editar o objetivo a qualquer momento: clicando no botão de editar na interface 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 de onde o problema está, esse tipo de prompt pode fazer o Codex se perder em 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 isso 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 durante o treinamento do modelo.

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 documento de plano com 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 Codex já consegue usar ferramentas relacionadas ou criá-las automaticamente.

Para outros objetivos, é 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 que 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 agente que você está ajustando.

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 aprimorando essa ferramenta, adicionando diferentes modos de comparação.

Imagem: uma captura de tela gerada pelo Codex, usada para comparação visual de duas imagens.

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 terminou, quando na verdade ainda não está completa.

Por exemplo, para «reprodução pixel a pixel» de uma interface, o Codex pode recortar referências de design e embutir na página, ou reduzir a cobertura de testes para atingir 100%. Essas não são as formas ideais de concluir a tarefa.

Criar 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 que, 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, configurações, bancos de dados semelhantes.

Por exemplo, ao depurar a otimização de tempos de build e implantação do developers.openai.com, usamos ambientes de pré-visualização. Assim, o Codex pôde usar esses ambientes para fazer deploys e verificar logs. Mas, como esses ambientes de pré-visualização não são idênticos ao ambiente de produção, tivemos que fazer deploys manuais em ambientes mais próximos do real para verificar os problemas.

Da mesma forma, você pode usar o «computer use» (capacidade do modelo de operar interfaces reais) para testar aplicações reais. Para otimizar problemas de desempenho no iOS, @dimillian usou 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 aprofundar demais em detalhes, negligenciando 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 esses recursos com precisão, ao invés de dividir o problema corretamente.

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

Por isso, imagens geralmente são melhores como contexto do objetivo, 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 ou conformidade com o sistema de design.

Acompanhar o progresso

Se o Codex trabalha horas ou dias nos bastidores, ou roda em outra máquina, é fácil perder de vista onde ele está, o que já foi feito.

Para diferentes objetivos, algumas estratégias ajudam bastante:

· Fazer o Codex criar commits em pontos-chave e enviá-los para um rascunho de PR. Especialmente útil em sites com pré-visualizações.

· Pedir ao Codex que atualize 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 canais do Slack ou outros locais de registro, ao atingir marcos importantes.

· 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, pedir ao Codex que leia um outro thread de objetivo, e responder às suas perguntas. Se você configurar tarefas automáticas de verificação de progresso, essa abordagem fica ainda mais poderosa.

Finalizar e confirmar resultados

Ótimo, o objetivo foi atingido! Agora, será que dá para passar o resultado para a equipe e encerrar?

Normalmente, especialmente em tarefas de otimização, é útil fazer o Codex revisar e avaliar o que foi feito. Você pode usar /review para uma revisão de código local, mas também é interessante que o Codex reflita mais profundamente: quais caminhos tentou, quais funcionaram, quais não funcionaram, e limpar o código com base nisso.

Como o Codex trabalha até atingir o objetivo, ele pode ter tentado métodos pouco eficazes ou até inválidos, que podem deixar resíduos 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 complexos. Mas só funciona bem se você fornecer o ambiente e as instruções corretas, para que ele possa alcançar o objetivo de forma eficiente.

Você já usou /goal?

[Link do artigo original]

Clique para conhecer as vagas na BlockBeats

Participe da comunidade oficial da BlockBeats:

Telegram: https://t.me/theblockbeats

Telegram: https://t.me/BlockBeats_App

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