Codex /goal command: minha visão honesta sobre autonomous coding

A primeira vez que dei um Codex a /goal e me afastei da minha mesa, voltei quarenta minutos depois e descobri que ele havia reescrito a mesma função onze vezes. Onze. Cada versão um pouco diferente. Nenhum deles objetivamente melhor que o anterior. O agent estava em loop - não no sentido produtivo do Ralph-loop, mas no sentido de "não tenho ideia de quando parar". Meu objetivo era "tornar a renderização mais rápida". Esse foi o prompt completo. Esse era todo o problema.

Eu dei a um agent autônomo de longa duração um alvo vago e depois agi surpreso quando ele vagou.

O comando Codex /goal chegou à versão 0.128.0 no final de abril e muda a forma do que uma codificação agent deve fazer. A maioria dos comandos de barra são reativos – você pergunta, ele responde, você pergunta novamente. /goal é o oposto. Você define um objetivo uma vez e Codex continua planejando, agindo, testando, avaliando e repetindo, até que o objetivo seja cumprido de forma verificável ou você diga para parar. É a coisa mais próxima de "disparar e esquecer" autonomous coding que usei e que não parece completamente perturbado.

Mas “não se sente completamente perturbado” está dando muito trabalho nessa frase. Porque a diferença entre uma execução /goal que oferece um ganho de desempenho de 25% e outra que produz onze versões da mesma função quebrada não é o modelo. Também não é o prompt. É algo mais sutil - e uma vez que você vê, você não pode deixar de ver.

Passei as últimas duas semanas vivendo dentro deste comando. Aqui está o que aprendi, o que errei e a estrutura que uso agora para decidir se um trabalho pertence a uma execução /goal ou a uma solicitação pull normal.

O que o comando Codex /goal realmente é

Deixe-me primeiro retirar a linguagem de marketing, porque o changelog do OpenAI é - como sempre - extremamente conciso sobre o que foi enviado.

O comando Codex /goal é um modo objetivo persistente para o Codex CLI. Você dá um alvo. Não retorna o controle após uma resposta. Ele mapeia seu repo, planeja, edita arquivos, executa testes, avalia o resultado em relação aos seus critérios de parada e declara a meta concluída ou inicia outra iteração. O agent permanece conectado ao encadeamento em muitas chamadas de ferramenta. Ele sobrevive aos limites de contexto devido à forma como Codex compacta e reutiliza o estado. Ele registra o progresso. Respeita as regras de aprovação.

Isto não é um bate-papo. É um processo de trabalho com uma lista de verificação.

Ele foi enviado como um recurso experimental, que é a expressão OpenAI para "isso é real, mas ainda não o estamos colocando na página inicial". Você o habilita manualmente em seu arquivo de configuração, executa Codex em seu terminal e um pequeno conjunto de novos comandos de barra aparece na TUI.

Aqui está a superfície de comando real a partir do Codex CLI 0.128.0:

/goal <objective> — defina uma meta de longo prazo e inicie o ciclo
/goal pause — conclua a etapa atual e faça uma pausa
/goal resume — retoma uma meta pausada
/goal clear — limpe totalmente o objetivo ativo
/goal (sem argumentos) — mostra o progresso, o uso do token e o tempo decorrido
/side <prompt> — abra um tópico lateral para fazer uma pergunta sem atrapalhar o objetivo principal; volte com a tecla Escape

O comando /side é a parte sobre a qual ninguém fala e é secretamente o melhor recurso do pacote. Mais sobre isso mais tarde.

Agora, antes de começar a usar isso, há uma coisa no vídeo de origem que assisti que está errada e você evitará uma tarde frustrante se souber disso agora.

O único detalhe de configuração que todos erram

O passo a passo que segui originalmente me dizia para habilitar metas em config.yml. Passei vinte minutos confusos me perguntando por que nada estava acontecendo antes de verificar a documentação real do Codex.

Codex CLI não usa YAML. Ele usa TOML.

O arquivo é ~/.codex/config.toml e o sinalizador reside em uma tabela [features]. O bloco de ativação mínimo é assim:

[features]
goals = true

Você também pode fazer isso na linha de comando – codex features enable goals grava o mesmo valor no mesmo arquivo. De qualquer forma, salve o arquivo, reinicie o Codex e os comandos /goal e /side aparecerão na paleta de comandos de barra. Caso contrário, você editou o arquivo errado ou está em uma versão Codex anterior a 0.128.0. Execute codex --version para confirmar.

Depois que features.goals = true for definido globalmente, o recurso funcionará tanto no aplicativo Codex CLI quanto no aplicativo Codex. Você só precisa habilitá-lo uma vez, no CLI, e ele se propaga.

Pequeno detalhe. Grande diferença entre “isso funciona” e “estou perdendo uma hora”.

Com isso resolvido, vamos falar sobre o que realmente importa - que é quando você deve usar esse comando em primeiro lugar, porque a resposta é "com muito menos frequência do que você imagina".

Os dois tipos de codificação – e por que /goal é errado para um deles

Aqui está o modelo mental que levei uma semana de uso indevido para chegar.

Quase todo trabalho de codificação que faço se enquadra em uma de duas categorias. As categorias parecem semelhantes por fora. Um engenheiro sênior geralmente consegue diferenciá-los em cerca de trinta segundos. Um codificador agent – e francamente, muitos engenheiros juniores – não consegue diferenciá-los. E /goal é apenas a ferramenta certa para um deles.

Categoria um: trabalho bem definido. Você conhece a entrada. Você conhece o resultado. Você sabe aproximadamente como é a diferença antes de começar. "Integre o Notion API para que possamos sincronizar os resumos do cliente no banco de dados de um projeto." "Adicione um manipulador de webhook Stripe que registra em nossa tabela de eventos existente." "Migrar o modelo de usuário de chaves primárias baseadas em email para chaves primárias baseadas em UUID." Essas tarefas têm uma forma. Há um número finito de arquivos que precisam ser alterados, uma definição clara do que está concluído e o caminho é principalmente mecânico depois que você pensa sobre isso por dez minutos.

Para esse tipo de trabalho, /goal é um exagero que beira o prejudicial. Você não quer um ciclo de autoavaliação. Você quer um PR limpo. Você deseja que o agent faça exatamente o que você pediu, devolva o controle e permita que você revise. O fluxo de trabalho padrão do Codex – prompt único, resposta única, revisão normal – lida com isso perfeitamente. Escrevo sobre como executo esse loop em meu [detalhamento do fluxo de trabalho Codex e Claude Code de dois agent] (https://www.mejba.me/blog/claude-code-codex-two-agent-workflow), e 90% do meu trabalho real ainda reside lá.

Categoria dois: trabalho exploratório. É aqui que o objetivo é conhecido, mas o caminho não. "Corte a latência P95 neste API em 20%." "Reduza nosso consumo de memória no pool de trabalhadores." "Encontre e corrija a mudança de layout que causou a cratera na pontuação do Lighthouse no celular." Você pode descrever o resultado desejado com uma métrica. Você não pode, entretanto, descrever a diferença antecipadamente. A solução pode ser uma mudança de configuração, uma otimização de consulta, um refatorador de código, uma troca de algoritmo – ou alguma combinação de todos os quatro descobertos em sequência após a execução de criadores de perfil.

É para isso que o /goal foi construído. O ciclo de raciocínio – planejar, agir, testar, avaliar, iterar – tem exatamente o formato certo para exploração. Você define uma meta verificável e deixa o agent trabalhar. Ele tenta alguma coisa. Os testes informam se a mudança mudou a métrica. Se sim, ele tenta ir mais longe. Se não, ele recua e tenta um ângulo diferente.

A história de melhoria de 25% do FPS que você verá nas demos do Codex? Essa é a categoria dois. Alguém deu ao Codex um problema de desempenho de renderização com um alvo mensurável claro e o deixou rodar por horas. Eles não sabiam qual otimização chegaria antes de começar. O agent descobriu o que tentar e o que manter.

O insight mais profundo aqui, que tive de aprender da maneira mais difícil: a maioria dos engenheiros adota o pensamento da categoria um mesmo quando estão trabalhando em problemas da categoria dois. Eles tentam especificar a solução antes de compreenderem o espaço de busca. /goal força você a inverter isso – você tem que se comprometer com o destino sem se comprometer com a rota. Isso é desconfortável. É também onde está a alavancagem.

Mas só funciona se o seu destino for real. O que nos leva à disciplina que faz ou quebra cada meta alcançada.

A verificabilidade da meta é o jogo completo

Veja o que acontece quando você atribui a Codex um objetivo vago.

Eu tentei /goal make the search faster em um pequeno projeto paralelo do Laravel. Codex começou executando a pesquisa existente, obtendo uma linha de base (boa). Em seguida, adicionou um índice na coluna mais consultada (bom). Em seguida, fez benchmarking novamente e encontrou uma melhoria de 14% (bom). Então continuou. Ele adicionou cache de resultados de consulta. Em seguida, refatorou o controlador de pesquisa. Em seguida, adicionou uma camada Redis. Em seguida, sugeriu uma migração da pesquisa de texto completo para o Meilisearch. Em nenhum momento ele parou, porque em nenhum momento eu lhe disse o que significava “rápido o suficiente”.

Codex injeta uma instrução de sistema no início de cada iteração que diz, em essência, "tratar a incerteza como não alcançada". É uma proteção contra falsas alegações de conclusão. Mas isso corta nos dois sentidos. Se o seu objetivo for genuinamente não verificável – se não houver nenhuma métrica, nenhuma lista de verificação, nenhum teste que possa retornar uma aprovação limpa – então o agent tratará o objetivo como perpetuamente não alcançado. Ele continuará iterando até que você fique sem tokens, paciência ou dinheiro.

A correção é simples de descrever e surpreendentemente difícil de executar. Cada /goal definido deve conter duas coisas:

Uma meta concreta. Uma métrica ("P95 abaixo de 250ms"), um teste de aprovação ("todos os testes e2e em tests/checkout/ verde") ou uma lista de verificação verificável ("a barra lateral do painel mostra o link de administração do Filament, testes automatizados são aprovados, nenhum novo erro de console no log de construção").
Uma definição de que o agent pode verificar a si mesmo. Não "até que pareça bom". Não "até que o desempenho seja aceitável". O agent deve ser capaz de executar um comando, observar um resultado e decidir com base apenas nessa observação.

Compare esses dois prompts. Mesma intenção. Comportamento totalmente diferente:

Ruim: /goal speed up the dashboard
Bom: /goal Reduce dashboard initial paint from current 2.4s baseline to under 1.0s on the staging environment. Success criteria: Lighthouse performance score above 90 on /dashboard, all existing e2e tests in tests/dashboard/ continue to pass, no new TypeScript errors in the build.

O primeiro é um desejo. O segundo é um contrato. Codex pode cumprir contratos. Não consegue realizar desejos – e pior, fingirá que está tentando.

Quando não tenho certeza de como redigir o contrato, faço algo que os documentos do OpenAI Codex recomendam explicitamente e que agora me recuso a pular: faço um brainstorming do objetivo com Codex primeiro, no modo de bate-papo normal, antes de executar o /goal. Eu descrevo o problema. Pergunto ao Codex quais critérios de sucesso verificáveis ele proporia. Eu discuto com isso. Eu aperto os critérios. Então, e somente então, abro um thread limpo e executo /goal com o contrato refinado. Essa etapa de brainstorming leva talvez dez minutos de trabalho e me economizou horas de desperdício de tokens.

O que o Codex realmente faz quando a meta começa

Deixe-me percorrer o circuito, porque a mecânica é importante.

Quando você digita /goal <objective>, Codex faz algo que parece normal, mas na verdade é a base de tudo o que se segue: ele mapeia o repository. Ele lê estruturas de arquivos, configurações principais, manifestos de pacotes. Ele esboça um modelo do que é o seu projeto e como ele está conectado. Isso não é gratuito – custa tokens – mas é a diferença entre um agent que escreve código de aparência plausível e outro que escreve código que realmente se ajusta à sua base de código. Eu investigo por que esse tipo de carregamento de contexto inicial é importante em [meu artigo sobre context engineering] (https://www.mejba.me/blog/ai-agent-context-beats-configuration), e /goal é uma das expressões mais claras desse princípio em qualquer ferramenta AI atual.

Então ele planeja. Codex esboça uma sequência de etapas que acredita que irão avançar em direção à meta. Ele escolhe o primeiro passo. Ele executa isso. A "execução" pode ser qualquer coisa - editar arquivos, executar comandos shell, executar testes, acessar um API, ler logs. Então ele avalia. A etapa moveu a métrica? Passou nos testes? Satisfez um item da lista de verificação?

Se sim, ele escolhe a próxima etapa. Se não, ele tenta uma variante ou desiste e tenta um ângulo diferente. O ciclo continua.

Você pode assistir isso acontecer em tempo real e é genuinamente hipnótico. Há um ritmo nisso. Leia, escreva, teste, observe, decida. O agent não está esperando por você. Está apenas funcionando.

Enquanto funciona, você pode emitir comandos. /goal pause termina a etapa atual e interrompe o loop de forma limpa - sem edições aplicadas pela metade, sem chamadas de ferramentas órfãs. /goal resume continua de onde parou. /goal sem argumentos mostra um resumo do progresso, gasto de token e tempo decorrido sem interromper nada.

E depois há /side.

/side <prompt> abre um thread secundário efêmero que não atrapalha o objetivo principal. O loop principal continua funcionando. Você pode fazer uma pergunta ao Codex - "espere, qual é a diferença entre um manipulador de rolagem revertido e acelerado novamente?" - e obtenha uma resposta em um contexto separado e, em seguida, volte para o tópico principal para continuar observando a meta ser executada. Isso parece insignificante. Não é. Antes do /side, cada interrupção interrompia o fluxo do agent. Com o /side, você pode verificar a sanidade de decisões, procurar informações não relacionadas ou até mesmo iniciar um pequeno experimento de esclarecimento, tudo sem envenenar o contexto do objetivo principal.

Esse único recurso foi o que me fez começar a confiar no /goal para execuções mais longas. A capacidade de perguntar sem interromper muda o relacionamento de “Tenho que me comprometer totalmente e ter esperança” para “Posso supervisionar sem sabotar”.

O problema da compactação que ninguém prevê

É aqui que as coisas ficam técnicas e onde reside a diferença entre uma execução /goal produtiva e uma execução condenada.

Contexto de acumulação agents de longa duração. Cada chamada de ferramenta, cada arquivo lido, cada resultado de teste – tudo isso se acumula no histórico de conversas. Eventualmente você atinge a janela de contexto do modelo e algo tem que acontecer. Codex lida com isso com o prompt compaction. Ele resume as transformações anteriores em um briefing mais restrito e continua a partir daí.

A compactação parece simples. Não é.

O bom compaction preserva o que importa: o objetivo, o estado atual do trabalho, as coisas que funcionaram, as coisas que falharam e por quê, as restrições, as preferências do usuário. Depois de um bom compaction, o agent continua de onde parou e o trabalho parece contínuo. compaction ruim elimina o contexto conquistado a duras penas - o motivo específico pelo qual uma abordagem anterior falhou, a escolha de configuração que tornou um benchmark válido, a compensação que o usuário escolheu explicitamente. Depois de um compaction ruim, o agent tenta novamente abordagens com falha, faz novamente perguntas resolvidas e lentamente se afasta da intenção original.

Eu assisti isso acontecer em um projeto real. Codex estava executando um /goal para otimizar um pipeline de consulta de banco de dados. Por volta do terceiro compaction, perdi o fato de que eu havia optado explicitamente pela desnormalização. Ele sugeriu novamente a desnormalização. Eu peguei porque estava assistindo, mas se eu estivesse AFK, o agent teria passado uma hora percorrendo um caminho que eu já havia fechado.

Há boas pesquisas da comunidade sobre como Codex compaction realmente funciona nos bastidores - [a investigação de Simon Zhou] (https://simzhou.com/en/posts/2026/how-codex-compacts-context/) e [o resumo mais amplo da pesquisa compaction] (https://gist.github.com/badlogic/cd2ef65b0697c4dbe2d13fbecb0a0a5f) valem seu tempo se você quiser os detalhes da sala de máquinas. A versão resumida: A qualidade do compaction é uma função de como o arnês agent resume, o que preserva e o que descarta. Codex é razoavelmente bom nisso, mas não é perfeito, e objetivos mais longos o enfatizam mais.

A implicação prática para os usuários do /goal é pequena, mas importante: escreva sua definição de objetivo no tipo de linguagem que sobrevive ao compaction. Use números específicos. Use arquivos e funções nomeados. Declare restrições explicitamente com “não faça” em vez de “prefiro não fazer”. Qualquer coisa que você disser uma vez e presumir que o agent se lembrará está em risco. Qualquer coisa que você inserir na definição da meta será reinjetada em cada limite de iteração, o que significa que sobreviverá a cada compaction.

Agora escrevo minhas definições de metas como se estivesse escrevendo um contrato que deve ser lido em voz alta no início de cada reunião, porque é efetivamente isso que está acontecendo.

O meio ambiente é mais importante do que a escolha do modelo

Essa é a parte do /goal que mais me surpreendeu.

Presumi que a diferença entre uma ótima corrida e uma medíocre dependeria do modelo que eu escolhesse. Não aconteceu. A maior variável na qualidade do /goal, por uma ampla margem, é o ambiente em que o agent opera.

Uma execução do /goal é tão boa quanto os sinais disponíveis para o agent. Se a meta for "reduzir a latência do P95 em 20%" e o agent não tiver como medir a latência do P95, a meta não poderá ser verificada na prática, não importa o quão limpo você a tenha escrito. O agent irá adivinhar. Ele otimizará o que pode ver, espera que se correlacione com o que não pode e produzirá mudanças que podem ou não alterar a métrica real.

Ambientes ricos produzem ótimas execuções de /goal. Rico significa:

Logs reais. Logs de aplicativos, estruturados e consultáveis, idealmente de um ambiente de teste que reflete o comportamento de produção.
Um cluster de preparação ou teste. Distribuído se o objetivo envolver algo relacionado à rede. O agent precisa ser capaz de fazer uma alteração, implantá-la e observar.
Métricas de custo e desempenho. Ativas, consultáveis e com linhas de base claras. Se o agent não conseguir extrair os números atuais, ele não poderá decidir se isso foi feito.
Gráficos de chama e criadores de perfil. Para trabalho de desempenho, isso não é negociável. O agent não encontrará um caminho ativo apenas lendo o código-fonte.
Acesso total à base de código com permissão para modificar, executar testes e inspecionar o estado do git. Uma execução /goal que precisa pedir permissão para cada comando consumirá seu tempo em prompts de aprovação em vez de progresso.

Para objetivos de alto risco ou que consomem muitos recursos — qualquer coisa que destrua a CPU por horas, martele um banco de dados ou execute um longo conjunto de benchmarks — eu não os executo em minha máquina local. Eu aciono um VPS na nuvem, clone o repo lá, executo o Codex de dentro de uma sessão SSH e deixo funcionar. Não se trata apenas de custo de recursos. Trata-se de não ter o ventilador do meu laptop gritando por seis horas enquanto um loop de benchmark é executado. Trata-se de isolar o ambiente para que "o agent quebrou alguma coisa" permaneça contido.

Se você está adiando a execução de cloud-based agent, este é o caso de uso que finalmente justifica configurá-lo corretamente. Abordo o padrão mais amplo em [meu artigo de longa duração sobre o chicote agent] (https://www.mejba.me/blog/anthropic-long-running-agent-harness) e os slots /goal nesse padrão são tão limpos quanto qualquer coisa que já vi.

The Scrappy Branch Trap - e o loop PRD que corrige isso

Aqui está a coisa mais contra-intuitiva que aprendi sobre as execuções de /goal e é a lição que gostaria que alguém tivesse me dado antes de começar.

A saída de uma execução bem-sucedida do /goal quase nunca é um código que você deve enviar.

Essa frase soará errada se você não a tiver vivido. Deixe-me explicar.

Uma execução /goal é, por design, exploratória. O agent está em busca de uma solução que não conhece antecipadamente. O caminho a seguir incluirá becos sem saída, instruções de impressão de depuração, valores codificados usados para testes, comentários como // TODO: revisit this hack e atalhos que funcionaram localmente, mas não sobreviverão à revisão do código. O agent não está sendo preguiçoso. É fazer exatamente como é o trabalho exploratório quando um humano o faz: fazer algo funcionar, validar a abordagem e depois limpar. Exceto que /goal geralmente fica sem tempo, tokens ou paciência antes da fase de limpeza.

O resultado é o que agora chamo de "branch fragmentado". Funciona. Ele move a métrica. Satisfaz a definição do objetivo. É também, frequentemente, uma bagunça absoluta.

Nas primeiras vezes que executei /goal, tentei mesclar esses branches diretamente. Sempre um erro. Eu encontraria impressões de depuração no código de produção duas semanas depois. Eu encontraria um hack que dependesse de um arquivo específico existente apenas no diretório de trabalho do agent. Eu encontraria abordagens que resolvessem o objetivo imediato, mas introduzissem dívidas técnicas sutis.

A correção é um fluxo de trabalho, não um sinalizador de configuração. Depois que uma execução do /goal é concluída com êxito, trato o resultado como uma prova de conceito, não como uma entrega. Eu li a diferença com atenção. Eu extraio o insight – a técnica real que resolveu o problema. Depois escrevo um breve PRD descrevendo o que foi aprendido: a abordagem, as compensações, as restrições, as partes que funcionaram e as partes que precisam de limpeza.

Então jogo fora o branch.

Abro um novo thread, dou ao Codex o PRD como uma especificação limpa e executo uma tarefa normal – trabalho de categoria um, pela minha definição anterior – para implementar o mesmo insight em uma base de código limpa. O resultado é dramaticamente melhor. Sem impressões de depuração. Sem hacks. Nenhum tecido cicatricial acumulado na fase de exploração. Apenas uma implementação limpa de uma abordagem que agora comprovadamente funciona.

Esse padrão de duas fases — exploração por meio de /goal e, em seguida, implementação por meio de fluxo de trabalho normal — é o padrão de codificação AI de maior aproveitamento que encontrei este ano. Isso reflete como bons engenheiros humanos realmente trabalham em problemas difíceis. Você explora. Você aprende. Você joga a ponta fora. Você constrói a coisa real.

Alguns engenheiros da comunidade Ralph-loop têm escrito sobre PRD controlado por autonomous coding em linhas semelhantes, e a convergência não é uma coincidência. O padrão funciona porque separa dois tipos de cognição que o agent não deveria realizar simultaneamente: descobrir o que construir e construí-lo bem.

Minha estrutura de decisão para /goal versus fluxo de trabalho normal

Após duas semanas de testes, aqui está a árvore de decisão que uso agora antes de chegar ao /goal:

Pergunta 1: você pode descrever a diferença antes de começar?

Se sim → fluxo de trabalho padrão. Escreva um prompt focado, obtenha uma resposta focada, revise o PR. /goal não acrescenta nada aqui.
Se não → continue para a questão 2.

Pergunta 2: você pode descrever a meta como um resultado verificável e mensurável?

Se sim → /goal está na mesa. Continuar.
Se não → você não está pronto. Faça um brainstorming da meta no modo normal até que você possa redigir um contrato limpo.

Pergunta 3: O agent tem acesso aos sinais que precisa verificar?

Se sim → /goal é a ferramenta certa. Execute-o.
Se não → conserte o ambiente primeiro. Adicione métricas. Adicione um cluster de preparo. Adicione registros reais. Então reavalie.

Pergunta 4: após o término da execução — você está tratando o resultado como uma entrega ou um pico?

Trate isso como um pico. Sempre. Descubra o insight em um PRD. Execute um passo de implementação limpo em relação às especificações refinadas. Envie isso.

É isso. Essa é a estrutura. Isso me economizou dinheiro real em tokens e horas reais em trabalho de limpeza, e é a lente através da qual agora leio todas as demonstrações do /goal no Twitter.

Se alguém lhe disser que o código /goal foi enviado diretamente para o main, eu perguntaria educadamente como será a taxa de bugs em duas semanas. Porque eu estive lá. A primeira corrida é inebriante. A limpeza é onde mora a lição.

Onde eu acho que isso vai acontecer

/goal é experimental. Vai evoluir rápido. Algumas coisas que estou assistindo:

A fronteira entre a exploração /goal e a execução de tarefas estruturadas vai se confundir. O padrão de loop PRD que descrevi acima provavelmente será incorporado à própria ferramenta - destilar, refatorar, implementar - em vez de viver como um fluxo de trabalho manual no topo. Quando isso acontecer, a lacuna entre “Tive uma ideia” e “Tenho um PR limpo” diminui drasticamente.

O problema ambiental será resolvido com padrões melhores. No momento, fazer com que um /goal execute sinais ricos o suficiente para verificar seu próprio trabalho é um exercício que exige muita configuração. A maioria dos projetos não tem isso. A próxima onda de ferramentas agent será fornecida com ambientes de teste gerenciados, observabilidade integrada e modelos de metas para alvos de otimização comuns. Ainda não chegamos lá. Estaremos em breve.

As diferenças de qualidade compaction entre as ferramentas de codificação AI se tornarão um importante fator de seleção. No momento, a maioria dos engenheiros escolhe uma codificação agent com base no modelo. Em um ano, eles escolherão com base em como o equipamento gerencia o contexto em execuções autônomas de horas de duração. Codex, Claude Code, Anthropic gerenciado por agents - o modelo não é o fosso. O arnês é.

Se você quiser continuar acompanhando esse espaço, escrevo sobre as novas ferramentas de codificação AI todas as semanas, e a [cobertura Codex / Claude Code é onde chega a maioria das lições práticas] (https://www.mejba.me/blog/codex-vs-claude-code-subscription).

Perguntas frequentes

Como habilito o comando Codex /goal?

Adicione [features] seguido de goals = true ao seu arquivo ~/.codex/config.toml, salve e reinicie o Codex CLI. Como alternativa, execute codex features enable goals, que grava o mesmo valor automaticamente. Verifique executando codex --version e confirmando que você está na versão 0.128.0 ou posterior – /goal e /side aparecerão na paleta de comando de barra depois de ativados.

O comando Codex /goal é seguro para execução autônoma?

É mais seguro do que executar um loop Ralph arbitrário, mas eu não permitiria que ele fosse executado completamente desacompanhado em código adjacente à produção. Use um VPS em nuvem ou ambiente isolado, defina um orçamento de token e revise cuidadosamente o branch resultante. Trate a saída como um pico, não como uma entrega - consulte a seção fragmentada branch acima.

Quando devo usar /goal versus um prompt Codex normal?

Use /goal apenas para trabalhos exploratórios onde você conhece o destino, mas não a rota — otimizações de desempenho, reduções de latência, investigações para encontrar o bug. Use prompts normais para qualquer tarefa onde você possa descrever a diferença antes de começar. A maior parte do trabalho real de codificação se enquadra na segunda categoria.

Qual é a diferença entre /goal e /side em Codex CLI?

/goal define um objetivo persistente e inicia um loop autônomo de longa duração. /side abre uma conversa paralela temporária que não interrompe uma meta ativa – você pode fazer perguntas, procurar informações ou realizar pequenos experimentos enquanto a meta principal continua em execução. Volte para o tópico principal com a tecla Escape.

Por que minha execução do /goal nunca termina?

Quase sempre porque o objetivo não é verificável. Codex injeta "tratar a incerteza como não alcançada" em cada iteração, portanto, um objetivo vago como "torná-lo mais rápido" é repetido indefinidamente. Reescreva o objetivo como um contrato concreto — métrica específica, testes nomeados, lista de verificação explícita — e o ciclo terminará corretamente quando os critérios forem atendidos.

Vamos trabalhar juntos

Procurando construir sistemas AI, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.

Fiverr (compilações e integrações personalizadas): fiverr.com/s/EgxYmWD
Portfólio: mejba.me
Ramlit Limited (soluções empresariais): ramlit.com
ColorPark (design e marca): colorpark.io
xCyberSecurity (serviços de segurança): xcybersecurity.io

Codex /goal command: minha visão honesta sobre autonomous coding