Nota do editor: Este artigo é de Dominik Kundel, membro da equipe de relações com desenvolvedores da OpenAI, e resume sua experiência com a funcionalidade Codex “goal mode //goal”. Ele não aborda uma simples técnica de prompt, mas sim uma mudança de papel nas ferramentas de programação por IA: o Codex já não é mais apenas um assistente de código que responde a instruções únicas, mas passa a atuar como um agente executivo capaz de avançar continuamente em direção a um objetivo claro.

No modo /goal, o que realmente importa não é escrever os requisitos da forma mais longa e detalhada possível, mas sim definir para o Codex critérios de saída claros e verificáveis. Por exemplo: “redução de 30% no tempo de implantação”, “cobertura de testes atingindo 100% de paridade”, “LCP reduzido para abaixo de 2,5 segundos”. Esses indicadores permitem que o Codex determine se a tarefa foi concluída e evitam que ele fique tentando infinitamente em objetivos vagos. Ao mesmo tempo, o usuário precisa fornecer direção suficiente, ferramentas e um ambiente real, para que o Codex possa medir o progresso e validar os resultados, e não apenas concluir uma solução que pareça viável em um ambiente local ou hipotético.

O artigo destaca especialmente que tarefas visuais são as mais propensas a fazer o Codex afundar-se em detalhes. Em vez de exigir "reprodução em nível de pixel de 100%", é melhor decompor os objetivos visuais em uma lista de funcionalidades, normas do sistema de design e métricas avaliáveis. Para tarefas de longa duração, que podem durar horas ou até dias, também é necessário rastrear continuamente o progresso por meio de commits, drafts de PR, documentos de progresso, atualizações no Slack ou bate-papos laterais, evitando assim terminar com um conjunto de alterações impossíveis de rastrear.

A informação adicional deste artigo reside em sua redefinição do /goal como um "mecanismo de gerenciamento de tarefas de longo prazo". Quando a IA pode executar continuamente dezenas ou até centenas de horas, a habilidade central dos desenvolvedores também muda: não se trata mais apenas de fazer a IA gerar código, mas de definir metas para ela, estabelecer sistemas de medição, configurar ambientes de execução e, por fim, realizar revisão e análise pós-execução. Em outras palavras, a programação por IA está evoluindo da "escrita de prompts" para o "gerenciamento de um executor de engenharia que trabalha continuamente".

A seguir está o texto original:

Lançamos o modo meta (goal mode, ou /goal) para ajudá-lo a fazer o Codex avançar continuamente em direção a um resultado específico. Após definir uma meta, o Codex continuará trabalhando até que a meta seja alcançada — independentemente de isso levar algumas horas ou vários dias. Alguém já fez o Codex trabalhar continuamente por mais de 120 horas para a mesma meta.

O modo de meta é muito poderoso. Para maximizar seu uso, observe 7 coisas ao usar /goal.

Defina critérios claros e verificáveis

Ao ativar o modo de destino, as instruções inseridas servem como prompt inicial e, mais importante, tornam-se o critério de conclusão para esse objetivo. O Codex verificará após cada ciclo de trabalho se o objetivo já foi concluído.

Portanto, seu prompt de objetivo não deve ser muito longo, mas sim focado em um critério claro: em quais circunstâncias, o objetivo será considerado alcançado.

Na maioria dos casos, um bom objetivo deve incluir uma métrica numérica clara para o modelo determinar se foi concluído. Por exemplo:

Reduza o tempo de construção e implantação em 30%.

Migrar esta funcionalidade do TypeScript para Rust e alcançar 100% de consistência nos testes.

Otimizar a estrutura da aplicação para garantir que a Pintura de Maior Conteúdo (Largest Contentful Paint, métrica que mede a velocidade de carregamento do conteúdo principal da página) fique abaixo de 2,5 segundos no ambiente de produção.

Este prompt não precisa sempre conter números, mas geralmente os números facilitam os passos subsequentes.

Se você ainda não tiver certeza de como definir um objetivo ou quiser primeiro fazer uma sessão de brainstorming com o Codex sobre este projeto, não precisa iniciar a conversa no modo de objetivo.

O Codex pode definir seus próprios objetivos. Você pode iniciar uma conversa normal e, quando estiver pronto para fazer o Codex começar a executar, permita que ele defina os objetivos com base nas discussões anteriores.

Você também pode editar o objetivo a qualquer momento: clique no botão editar no aplicativo Codex ou use novamente /goal no CLI.

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

Dicas como “reduzir o tempo de construção e implantação em 30%” soam legais e podem levar o Codex a encontrar soluções criativas. Mas se você já tem uma ideia aproximada de onde o problema pode estar, essa dica também pode desviar o Codex do caminho certo.

Portanto, sempre que possível, é melhor informar ao Codex de onde começar a investigar, quais ferramentas podem ser usadas para alcançar o objetivo ou fornecer outras dicas, evitando que ele siga uma direção errada.

Por exemplo, meu colega @reach_vb fez isso em um experimento: ele informou ao Codex que poderia acessar o Google Colab por meio do navegador Chrome e especificou algumas restrições aceitáveis, como permitir que o Codex gere automaticamente o conjunto de dados durante o treinamento do modelo.

Da mesma forma, se você deseja reduzir o tempo de construção e já sabe em qual etapa a maior parte do tempo é consumida, é melhor direcionar inicialmente o Codex para essa área no prompt.

Outra abordagem é permitir que o Codex realize pesquisas iniciais no modo planejamento (plan mode) e crie um arquivo de plano para documentar soluções potenciais. Em seguida, faça seu objetivo referenciar esse plano.

Torne o progresso mensurável

Se o seu objetivo for ambicioso ou se o Codex tiver várias maneiras de se aproximar gradualmente do objetivo, é importante fornecer ao Codex ferramentas para medir o progresso.

Para algumas tarefas, isso pode ser naturalmente verdadeiro. Por exemplo, otimizar o tempo de construção ou aumentar a cobertura de testes, pois o Codex geralmente já consegue usar as ferramentas relacionadas ou criará essas ferramentas naturalmente.

Mas para outros objetivos, é melhor você primeiro fazer um brainstorm com o Codex: quais ferramentas ajudam a avaliar o progresso? Ou dê a ele algumas dicas para que ele saiba como confirmar se está se aproximando do objetivo. Por exemplo, crie uma ferramenta de comparação visual de diferenças entre duas capturas de tela, ou um conjunto de avaliações para o agente que você está depurando.

Eu já pedi ao Codex para replicar alguns componentes com base em um vídeo, e, na época, o Codex criou uma ferramenta para comparar capturas de tela e verificar diferenças. Posteriormente, ele continuou a iterar essa ferramenta, adicionando diferentes modos de comparação de diferenças.

Dependendo da tarefa, você também precisa considerar se há alguns critérios adicionais que precisam ser medidos ou verificados. Caso contrário, o Codex pode achar que a tarefa já foi concluída, mas, em sua opinião, ainda não está completa.

Por exemplo, o Codex pode recortar diretamente a imagem de referência do design e incorporá-la na página para uma "reprodução em nível de pixel"; ou pode reduzir a cobertura dos testes para alcançar 100% de aprovação. Esses não são os verdadeiros métodos desejados para concluir o trabalho.

Crie um ambiente real

Se você deseja que o Codex faça progressos reais em direção ao seu objetivo, ele precisa operar em um ambiente suficientemente realista.

Na prática, isso significa: se você deseja otimizar o tempo de implantação ou problemas de latência, o Codex deve ter acesso aos ambientes de implantação e teste, e esses ambientes devem simular o ambiente de produção da melhor forma possível. Ou seja, use a mesma pilha tecnológica, os mesmos interruptores de configuração e bancos de dados semelhantes.

Por exemplo, anteriormente otimizamos o tempo de construção e implantação do developers.openai.com. Na época, já estávamos usando pré-visualizações de implantação, então o Codex podia aproveitar esses ambientes de pré-visualização para implantar e visualizar os logs relacionados. Mas o problema era que nossas implantações de pré-visualização desativavam certos caminhos de construção em comparação com o ambiente de produção completo.

Por isso, o Codex acabou tendo que fazer um deploy manual, implantando o código em um ambiente mais próximo da configuração de produção para poder realmente identificar o problema.

Da mesma forma, você também pode permitir que o Codex use computer use (a capacidade do modelo de operar interfaces de aplicativos reais) para testar aplicações reais. Para otimizar alguns problemas de desempenho no iOS, @dimillian até utilizou dispositivos físicos para obter o ambiente de teste mais preciso.

Defina metas visuais com cautela

Dar ao Codex um objetivo visual, como “reproduzir este UI em 100% de precisão pixel a pixel com base nesta imagem”, é realmente atraente. Mas, dependendo da configuração específica, isso também pode causar problemas.

Se você não fornecer orientações e limites adequados, o Codex pode se aprofundar em detalhes específicos, acabando por ignorar o objetivo geral. Por exemplo, se a imagem de referência contiver elementos gráficos e você esperar que o Codex os gere—seja ícones SVG ou imagens—ele pode gastar grande parte de seu esforço em "como replicar exatamente esses elementos", em vez de decompor corretamente o problema inteiro.

Além disso, o Codex precisa de ferramentas para realizar comparações visuais corretamente. Isso significa mais entradas de imagens e maior consumo total de tokens, mas não necessariamente fornece ao Codex uma maneira simples de identificar oportunidades de melhoria verdadeiramente valiosas.

Portanto, imagens geralmente são mais adequadas como contexto de destino, e não como único critério de conclusão. Você deve buscar outras maneiras de permitir que o Codex determine se o objetivo já foi atingido, como listas de funcionalidades, especificações de implementação, conformidade com o sistema de design, etc.

Acompanhar o progresso

Se o Codex acabar funcionando em segundo plano por horas ou até dias, mesmo em outro computador, é fácil esquecer até onde ele chegou e quais tarefas já concluiu.

De acordo com diferentes objetivos, descobri que os seguintes métodos são muito úteis:

· Faça o Codex enviar o código nos pontos-chave e empurrá-lo para um PR rascunho. Isso será especialmente útil quando você estiver trabalhando em um site com implantação de pré-visualização.

· Faça o Codex atualizar um artefato destinado à gestão. Pode ser um arquivo HTML que você pode manter aberto no navegador interno do aplicativo; ou uma página implantada via Sites para que a equipe visualize; pode ser um gráfico de progresso renderizado ou apenas um arquivo Markdown comum.

Instrua o Codex a publicar atualizações proativas sobre o progresso. Você também pode incluir isso como um objetivo: fazer com que o Codex envie atualizações para o canal do Slack, ou qualquer outro local onde você deseje registrar o progresso, sempre que houver avanços importantes.

Use outra janela de bate-papo para consultar o status. Se você deseja apenas obter rapidamente o status atual, execute /side para iniciar um novo bate-papo lateral e faça sua pergunta lá. Como ele se ramifica a partir da thread atual, possui todo o contexto até o momento, mas tem um ciclo de vida curto.

Outra abordagem no aplicativo Codex é iniciar um novo chat normal, permitir que o Codex leia outra thread de destino e responda às suas perguntas. Essa abordagem é especialmente poderosa se você configurar o Codex para executar uma tarefa automatizada que verifique regularmente o progresso.

Limpar e confirmar finalmente os resultados

Ótimo, o objetivo finalmente foi alcançado! Agora podemos simplesmente entregar os resultados à equipe e encerrar por hoje?

Geralmente, especialmente em tarefas de otimização, descobri que é útil pedir ao Codex para revisar e avaliar seu próprio trabalho. Você pode começar executando uma revisão local de código com /review, mas também vale a pena pedir ao Codex para refletir mais profundamente: quais caminhos ele tentou para alcançar o objetivo? Quais tentativas foram bem-sucedidas? Quais não funcionaram? Em seguida, limpar o código com base nisso.

Como o Codex continuará trabalhando até atingir o objetivo, ele pode ter tentado alguns métodos com efeitos insuficientes ou completamente ineficazes, e essas alterações residuais podem ainda estar presentes no código final.

Defina um objetivo para a sua próxima tarefa também

A função principal do Codex é uma ferramenta extremamente poderosa que pode ajudá-lo a resolver alguns dos desafios de engenharia mais significativos. Mas apenas quando você fornece o ambiente e as instruções corretos, ele consegue alcançar o objetivo de forma mais eficiente.

O que você já fez com /goal?