For/Goal testado: Claude Code vs Codex criaram meu app em 32 min

For/Goal testado: Claude Code vs Codex criaram meu app em 32 min

Acionei o cronômetro às 14h47 de uma quarta-feira. Às 15h19, duas janelas de terminal em meu monitor esquerdo haviam terminado de montar um aplicativo Next.js funcional - fluxo de integração, painel, página de destino, telas de autenticação, toda a forma de um produto real. Sessenta e duas tarefas de roteiro. Ambos os aplicativos. Trinta e dois minutos cada. Eu estava reabastecendo meu café.

Esta é a parte em que o pessoal da demonstração no Twitter geralmente grava um lapso de tempo de trinta segundos e encerra o dia. Quero mostrar a você as costuras reais. Porque o recurso for/goal – o loop autônomo de longa duração que chegou em Claude Code 2.1.139 e vem em Codex CLI 0.128.0 – parece apenas mágica. Embaixo dela há uma receita muito específica, e essa receita é a diferença entre um agente que envia um aplicativo real em meia hora e um agente que fica em loop indefinidamente, reescrevendo a mesma função quebrada até você encerrar o processo por pena.

Tenho executado for/goal quase todos os dias desde que o recurso foi lançado. Dois projetos paralelos. Mesma especificação do produto. O mesmo roteiro de seis fases. Uma execução em Claude Code, uma em Codex. Ambos terminaram. Ambos produziram algo que eu poderia git clone e demonstrar para um cliente amanhã. Eles também produziram aplicativos muito diferentes a partir do mesmo prompt, e as diferenças indicam exatamente qual agente procurar e quando.

Este é o colapso que eu gostaria de ter antes de começar.

O que For/Goal realmente é - e por que não é apenas mais um comando de barra

Deixe-me tirar a linguagem de marketing primeiro.

For/goal é um modo objetivo persistente. Você define uma meta uma vez, o agente trabalha nela em vários turnos – às vezes horas, às vezes um dia inteiro – e um segundo modelo menor verifica após cada turno se a meta foi realmente alcançada. Se o validador disser não, o modelo principal recebe aquele “não” mais uma razão de uma frase e continua trabalhando. Se o validador disser sim, o loop termina e seu terminal devolve o controle. Essa é toda a forma.

Em Claude Code, o comando é literalmente /goal. Ele foi enviado na versão 2.1.139, lançada no início de maio de 2026. O validador é executado em qualquer modelo que você configurou como seu modelo pequeno e rápido – Haiku por padrão – e o custo do token do validador é cobrado separadamente do orçamento do turno principal, o que é importante quando você está executando uma meta por seis horas.

Em Codex CLI, a superfície de comando tem a mesma ideia. Codex chama o loop primitivo for/goal, e os comandos de barra na versão 0.128.0 são /goal, /goal pause, /goal resume, /goal clear, além de um thread /side para fazer uma pergunta rápida sem perturbar a execução principal. Mesma arquitetura: o modelo principal faz o trabalho, o modelo pequeno julga a conclusão.

Esta é, mecanicamente, uma evolução do padrão de loop Ralph – o bash one-liner que engenheiros como Adam Tuttle e o repositório snarktank transformaram em metodologia nos últimos doze meses. Ralph era um wrapper while true em torno do seu agente de codificação, com um comando de verificação na outra extremidade do canal. For/goal pega essa ideia e a incorpora no próprio agente, com uma arquitetura de supervisor real e um gancho de parada com reconhecimento de estado.

Aqui está a parte que demorei três vezes para internalizar: isso não é mais um bate-papo. É um processo de trabalho com uma lista de verificação. Você não fala com isso. Você define o destino e verifica se ele está acessível. O agente faz o resto.

O que parece simples. Não é, e vou mostrar o porquê.

A configuração: um PRD, dois agentes, sessenta e duas tarefas

O aplicativo de teste era uma ferramenta de revisão de conteúdo – algo entre um espaço de trabalho estilo Notion e uma fila de anotações de vídeo. Nada de abalar o mundo. Eu o escolhi porque o escopo era grande o suficiente para ser interessante (precisava de autenticação, um conceito de espaço de trabalho, uma fila de revisão, um fluxo de integração e uma página de configurações), mas pequeno o suficiente para que eu pudesse ler todos os arquivos produzidos pelo agente e dizer o que realmente estava lá.

A especificação eram cinco arquivos na raiz do projeto antes de eu tocar em qualquer outra coisa:

• prd.md — o documento de requisitos do produto. Cerca de 1.400 palavras. Público, problema, as três tarefas principais que o aplicativo precisava realizar, o modelo de dados em inglês simples e uma lista de itens fora do escopo para que o agente não se desviasse para recursos que eu não queria. - productroadmap.mmd — um roteiro da Mermaid com seis fases e sessenta e duas tarefas de folha. A Fase 1 foi o andaime e a autenticação, a Fase 2 foi o conceito do espaço de trabalho, a Fase 3 foi a fila de revisão e assim por diante até a Fase 6, que foi o polimento e a integração. - design.md — direção front-end. Paleta de cores, pilha de tipografia, preferências de densidade de layout ("visualizações de tabela densas sobre grades de cartões para páginas de fila") e uma lista de componentes que eu esperava ver (tabelas de dados, painéis deslizantes, paleta de comandos). - claude.md — Arquivo de regras em nível de projeto do Claude Code.

Pilha fixada no roteador de aplicativos Next.js 15, TypeScript estrito, Tailwind v4, shadcn/ui, sem Redux, sem componentes estilizados, ações do servidor para mutações. - agents.md — Arquivo de regras equivalente do Codex com as mesmas restrições, escrito no formato preferido do Codex.

O objetivo que dei a cada agente foi idêntico, palavra por palavra:

Crie o aplicativo completo descrito em prd.md seguindo as tarefas em productroadmap.mmd até que todas as tarefas sejam concluídas e verificadas. Use design.md para direção de design de front-end. Nova versão do aplicativo Next.js. Execute com a aprovação automática ativada. Continue até que o validador confirme que todas as tarefas do roteiro foram verificadas e que o aplicativo foi compilado e limpo.

Essa frase de meta está dando muito trabalho. Deixe-me desvendar o que o faz sobreviver a uma execução autônoma de trinta minutos, porque queimei três tentativas anteriores de frases mais fracas antes de chegar aqui.

A frase “até que todas as tarefas sejam concluídas e verificadas” é a condição de parada. Ele aponta o validador para algo concreto a ser verificado – o arquivo do roteiro – em vez de pedir que ele avalie a qualidade, que é um trabalho que pequenos modelos fazem terrivelmente. "Nova versão do aplicativo Next.js" é o limite máximo do escopo. Diz ao agente "não tente integrar com nada que já exista neste diretório, você possui a árvore inteira". E "Executar com aprovação automática ativada" é a concessão de permissão - sem ela, o Claude Code em particular irá parar a cada quarenta segundos para perguntar se pode instalar um pacote.

You'll see what happens when one of those clauses is missing in a few sections. Stick around for the second-half mistakes section.

Como escrever uma meta For/Goal que realmente termine

Esta é a parte que quero desacelerar, porque a diferença entre uma corrida de meta que se completa e uma corrida de meta que gira indefinidamente é quase sempre a própria sentença de meta.

Um destino for/goal funcional tem quatro partes, nesta ordem:

1. O que alcançar. Um estado final mensurável. Não "torne isso legal". Não "melhorar o UX". Algo que o validador possa ler e responder sim ou não sem fazer um julgamento. "Todas as sessenta e duas tarefas do roteiro marcadas como concluídas no arquivo." "Aprovações de construção de produção." "Todos os testes do dramaturgo são verdes."

2. O que mudar. Escopo. Quais arquivos, quais diretórios e quais superfícies o agente pode tocar. Se você pular isso, os agentes autônomos refatorarão o código adjacente no caminho para a meta, e você obterá uma comparação de trinta páginas que inclui nove arquivos que você nunca quis que fossem tocados.

3. O que validar. O comando ou sinal real que o validador deve procurar. "pnpm build sai do zero." "O arquivo do roteiro não contém nenhum item desmarcado." Isso é o que alimenta o modelo pequeno e rápido após cada turno.

4. Quando parar. A condição de saída. Geralmente é o mesmo que o sinal de validação, mas às vezes você quer cinto e suspensórios - "pare quando o validador confirmar E os testes de integração tiverem sido executados pelo menos uma vez".

Uma meta maior que um único prompt, mas menor que uma lista de pendências aberta. Esse é o tamanho ideal. "Refatorar esta função" é muito pequeno - basta solicitar. “Construir um SaaS” é muito grande – o agente não tem ideia do que significa feito e entrará em espiral. "Construa o aplicativo descrito em prd.md até que todas as tarefas em productroadmap.mmd sejam verificadas e a construção de produção seja aprovada" é exatamente o tamanho para o qual o /goal foi projetado.

Nota lateral: testei isso em uma manhã de fim de semana, alimentado quase inteiramente por café expresso e teimosia. Os resultados poderiam ter sido diferentes em uma segunda-feira com sono melhor. Mas duvido. A disciplina de redação de metas é mais importante do que o modelo que você aponta, que é a lição inesperada dos últimos dois meses.

Execute um: Claude Code em /goal

Acertei /goal em Claude Code primeiro. Colou a frase do gol. Assistido.

A primeira virada foi uma virada de planejamento. Claude Code leu prd.md, leu productroadmap.mmd, leu design.md, leu claude.md e, em seguida, imprimiu um resumo de um parágrafo do que estava prestes a fazer e fez uma pergunta: "Várias tarefas de roteiro fazem referência a integrações externas de API - Stripe para faturamento, Reenviar para email transacional, Supabase para autenticação e persistência. Você tem credenciais para isso ou devo construir com dados simulados e clientes stubados para que o aplicativo seja executado offline?

Essa única pergunta é o momento de engenheiro sênior que já vi um agente produzir em liberdade. Ele identificou que o aplicativo não poderia ser concluído sem credenciais externas, reconheceu que eu não havia fornecido nenhuma e propôs um substituto que permitiria enviar algo executável em vez de paralisar. Eu disse para ele construir offline com simulações e uma lista TODO claramente marcada de pontos de integração, e ele continuou.

A partir daí, durou vinte e nove minutos sem outra pergunta.

O padrão era o mesmo em todos os turnos: escolha a próxima tarefa de roteiro não verificada, leia os arquivos relevantes, escreva ou modifique o código, execute uma validação focada (pnpm tsc --noEmit para alterações de tipo, pnpm lint para alterações de componentes, pnpm build após marcos importantes), marque a tarefa no arquivo de roteiro e retorne ao validador. O validador respondeu “não” após cada turno, exceto o último. O "não" voltou com um motivo de uma linha - "Fase 3, tarefa 4 ainda desmarcada" ou "A última construção foi concluída há vinte minutos, verifique se ainda funciona após os novos componentes" - e o turno seguinte começou com esse motivo como a primeira entrada.

No minuto vinte e nove, o validador disse “sim”. Claude Code parou, resumiu o que construiu e listou os pontos de integração TODO que havia eliminado. Eu verifiquei o repositório. Sessenta e duas tarefas marcadas. Construção aprovada. Limpe os fiapos.

Então li o aplicativo real.

A página de destino estava repleta de textos. Hierarquia de títulos real. Bloco de depoimentos com três personas citadas que correspondiam ao público descrito no PRD. Uma tabela de preços com três níveis, cada um baseado em uma tarefa a ser realizada de acordo com as especificações. O painel tinha muito texto, mas estava claramente estruturado – barra lateral com o alternador de espaço de trabalho, uma barra superior com o gatilho da paleta de comandos, um painel principal cujo padrão era a fila de revisão. A fila de revisão em si era uma tabela densa com colunas classificáveis, exatamente o que design.md havia solicitado. Houve um fluxo de integração com três etapas e microcópia limpa.

O autor foi ridicularizado. Login redirecionado para o painel após um atraso falso. A sessão foi armazenada em um cookie com um comentário TODO apontando para o ponto de integração do Supabase. O botão de checkout do Stripe abriu um modal que explicava o que aconteceria quando a integração fosse conectada. Cada integração externa era uma costura claramente marcada, não uma ligação interrompida.

Essa era a versão que eu enviaria a um cliente para mostrar como é sua ideia. Ele não sobreviveria ao contato com um usuário pagante – a autenticação por si só é um incidente de segurança esperando para acontecer – mas sobreviveria absolutamente ao contato com uma reunião de demonstração na terça-feira.

Total decorrido: 32 minutos e 14 segundos. Duas execuções do validador Haiku me custaram quarenta e sete centavos. O gasto do token do agente principal foi, pela calculadora de custos, de US$ 11,20 no Sonnet 4.6.

Execute dois: Codex CLI em /goal

Limpei o diretório, restaurei os arquivos de especificações e cliquei em /goal em Codex.

Codex não fez a pergunta env-vars. Apenas começou.

Este é o primeiro lugar onde os dois agentes divergiram de uma forma importante. Codex presumiu que tinha licença para construir com simulações em qualquer lugar onde faltassem credenciais externas. O que é – no final das contas – o que eu teria dito para fazer de qualquer maneira. Mas o comportamento de pausa para confirmar do Claude Code é, para trabalho de produção, o melhor padrão. O comportamento do Codex de apenas decidir é o caminho mais rápido quando a especificação é inequívoca, e isso ocorre na maioria das vezes.

O padrão de execução do Codex era quase idêntico ao do Claude Code no nível do loop – planejar, agir, validar, repetir – mas a forma como sequenciava o trabalho era diferente. Claude Code passou fase por fase, terminando a Fase 1 inteiramente antes de tocar na Fase 2. Codex trabalhou mais em forma de treliça: ele construiu todo o esqueleto do aplicativo primeiro (todas as seis fases de rotas vazias e stubs de componentes), depois voltou e os preencheu. Codex prefere decompor o trabalho. Ele primeiro constrói a silhueta do produto acabado e depois esculpe.

Minuto trinta e um, o validador disse que sim. Eu li o aplicativo.

Visualmente, o app Codex era o mais bonito. Tipografia mais limpa (escolheu Geist em vez do Inter que Claude Code padronizou, o que corresponde à conversa de design de front-end que estou começando a ver na maioria dos designers de produtos seniores em 2026). A página de destino tinha imagens reais do produto - Codex extraiu imagens de espaço reservado de uma coleção limpa do Unsplash em vez de descartar componentes Image com atributos src quebrados, como Claude Code fez uma vez durante um teste anterior. As guias estavam mais limpas, os ícones eram arredondados, o sistema de realce de cores extraía detalhes em vermelho do arquivo de design de forma consistente em todas as páginas.

Funcionalmente, Codex fez algumas coisas que Claude Code não fez. A fila de revisão tinha edição embutida – você podia clicar em uma pílula de status e alterá-la sem sair da página. O sistema de filtros na fila tinha três filtros funcionais, além de um menu suspenso de visualização salva. A página de configurações tinha uma camada de dicas que explicava cada campo. Havia um espaço de trabalho de demonstração pré-preenchido com conteúdo falso, de modo que o estado vazio de cada página mostrava algo em vez de um espaço reservado para “adicione seu primeiro item”.

As perdas, porque sempre há perdas: dois ícones foram quebrados — Codex referenciou nomes de ícones lucide-react que não existem na versão atual, e tive que trocá-los manualmente. O substituto de autenticação foi inteligente, mas frágil - o cliente simulado tinha 50% de chance de retornar o usuário de demonstração na verificação da sessão, o que tenho certeza que foi um artefato de como Codex escreveu o stub e não um design deliberado. A cópia da página de destino era esparsa em comparação com a de Claude Code - Codex colocou o polimento visual primeiro e deixou as palavras passarem.

Total decorrido: 32 minutos e 42 segundos. Aproximadamente o mesmo gasto de token. Aproximadamente a mesma taxa de conclusão de tarefas.

Dois agentes. Mesma especificação. Mesma arquitetura de loop. Produtos diferentes.

Lado a lado: para que cada agente otimizou

Aqui está a comparação que eu gostaria que me fosse entregue antes de iniciar este experimento.

1,20 principal + validador de $ 0,47 | Aproximadamente equivalente |

Se você está procurando o título: Claude Code escreveu uma história de produto melhor, Codex escreveu um shell de produto melhor. O aplicativo de Claude Code converteria melhor em uma página de destino; O aplicativo Codex ficaria melhor em uma demonstração de produto. Qual deles é importante para você depende inteiramente do que você está enviando.

Para meu próprio fluxo de trabalho, comecei a buscar Claude Code em execuções for/goal onde a saída precisa * se comunicar * - páginas de destino, páginas de marketing, qualquer coisa que precise ser lida como uma pessoa escreveu. Eu procuro Codex em execuções for/goal onde a saída precisa se comportar - painéis, ferramentas, aplicativos internos com muita superfície de interação. Essa heurística resistiu a cerca de uma dúzia de execuções desde então.

O que isso significa para a maneira como construo

Deixe-me diminuir o zoom, porque a implicação aqui é maior do que qual agente escolher.

Por cerca de dezoito meses, o padrão dominante no desenvolvimento assistido por AI tem sido o ciclo de chamada e resposta. Você solicita, o agente faz uma coisa, você revisa e solicita novamente. Até mesmo os melhores fluxos de trabalho que criei - e escrevi sobre a maioria deles, incluindo o fluxo de trabalho de dois agentes Claude Code e Codex e o ciclo de planejamento Claudeex - eram variações de chamada e resposta com um segundo par de olhos adicionado.

For/goal quebra esse padrão. O agente não está pedindo permissão. O agente tem um destino, um orçamento e um validador, e sua tarefa antes da execução é escrever o destino com clareza suficiente para que o validador possa reconhecer quando ele foi alcançado. Seu trabalho durante a corrida é estar em outro lugar. Seu trabalho após a execução é ler a saída e decidir o que é bom.

Esse é um músculo diferente. É mais próximo escrever um briefing para um empreiteiro do que programar em pares. A habilidade está na especificação, não na solicitação. Se seu PRD for nítido, seu roteiro for granular e seu documento de design for concreto, for/goal torna você mais rápido de uma forma que a geração anterior de agentes de codificação não conseguia. Se algum desses três for vago, for/goal produzirá uma execução lindamente concluída que enviará o produto errado.

A razão pela qual isso é importante: pela primeira vez, o gargalo na construção assistida por AI não é o modelo. É o trabalho de preparação. E o trabalho de preparação é algo em que a maioria dos engenheiros - inclusive eu - subinveste porque não parece construir. A mudança para as forças /goal é que o trabalho de preparação se torna a construção. O código está a jusante da especificação, e a especificação é onde reside agora o julgamento da engenharia.

Eu teria dito a você há seis meses que o futuro da codificação era a orquestração multiagente - Claude Code conversando com Codex conversando com Gemini, com transferências, ciclos de revisão e decisões de consenso. Ainda acho que isso faz parte. Mas for/goal me fez perceber que há um futuro mais simples rodando em paralelo: um destino bem especificado, um agente capaz, uma condição de parada verificável. Sem orquestração. Sem transferências. Apenas um gol e um loop.

É menos interessante escrever artigos sobre esse futuro. É mais interessante enviar o produto.

Os erros que cometi (e você cometerá)

Três erros nas minhas primeiras dez execuções for/goal, caso você queira pular a mensalidade.

Erro um: dei ao for/goal um objetivo vago. "Construir uma ferramenta de gerenciamento de projeto" em vez de "criar o aplicativo descrito em prd.md até que todas as tarefas do roteiro sejam verificadas e a construção seja aprovada". O agente funcionou por duas horas, produziu seis versões diferentes de uma página de configurações e nunca parou porque não havia nenhum sinal concreto para o validador verificar. A solução: sempre aponte o validador para um arquivo ou comando, nunca para um sentimento.

Erro dois: esqueci de ativar a aprovação automática. Sem ela, o Claude Code em particular fará uma pausa para pedir permissão para cada instalação de pacote, cada exclusão de arquivo, cada comando shell fora de uma pequena lista de permissões. Para uma execução de sessenta e duas tarefas, isso significa que o agente para cerca de quarenta vezes para perguntar, o que torna discutível toda a questão da autonomia de longa duração. Habilite-o explicitamente em sua frase de objetivo – “executar com aprovação automática ativada” – ou defina-o em sua configuração antes de começar.

Erro três: deixei o agente inventar as especificações durante a execução. Apresentei um resumo de uma página e disse "descubra o resto". Ele descobriu. O resto não era o que eu queria. For/goal não substitui pensar no que você está construindo. É um substituto para digitar o que você já pensou. Essas são habilidades diferentes. O primeiro ainda mora com você.

Há uma versão mais profunda do erro três, sobre a qual ninguém escreve: agentes de longa data são muito bons em fazer qualquer especificação parecer correta quando terminam. O produto final terá uma aparência elegante, passará por seu próprio validador, parecerá concluir todas as tarefas – e será exatamente tão bom quanto a especificação com a qual você começou, nada melhor. Se a especificação for fina, o produto polido é um produto fino vestindo uma camisa limpa. O agente não vai resistir ao pensamento fraco do produto. Isso ainda depende de você.

Esta é a parte do for/goal que mais exige adaptação, especialmente para engenheiros que aprenderam a construir iterando com um colega de equipe. O colega de equipe agora é o validador, e o validador está lendo um arquivo de roteiro, não o seu pensamento de roteiro. Se o roteiro estiver errado, o loop construirá fielmente a coisa errada. O trabalho que costumava acontecer durante a implementação agora precisa acontecer antes de você pressionar Enter na meta. Essa mudança mental é a habilidade que separa os engenheiros que concluem funcionalidades de duas semanas em uma tarde daqueles que concluem funcionalidades de duas semanas em oito horas de loops frustrantes.

Ainda estou me adaptando. A disciplina de escrever um roteiro que um agente possa executar fielmente é genuinamente diferente da disciplina de escrever um roteiro que você possa executar, porque você e o agente falham de maneiras diferentes. Você fica à deriva. O agente não. Você compensa a ambigüidade exercendo o julgamento no momento. O agente compensa a ambiguidade inventando detalhes, muitas vezes errados. Portanto, o roteiro deve ser mais rígido do que aquele que você escreveria para si mesmo. Essa é a nova forma do trabalho.

Quando alcançar For/Goal - e quando não

Três categorias de trabalho onde for/goal ganha seu sustento:

Andaime de aplicativo de primeira passagem a partir de especificações claras. Exatamente o experimento nesta postagem. Você tem um PRD, um roteiro, um documento de design. Você deseja um shell executável com a maioria das superfícies no lugar. For/goal é imbatível aqui. Trinta e dois minutos para o que um engenheiro júnior levaria quase uma semana.

Refatores de horizonte longo com estados finais mensuráveis. "Migrar todos os componentes neste diretório da sintaxe de classe para função até que pnpm tsc --noEmit seja aprovado." "Converta toda a busca de dados useEffect em ações do servidor até que nenhum useEffect faça referência a fetch em qualquer lugar da base de código." Qualquer coisa com uma condição de parada mensurável e um caminho mecânico. O pessoal do Ralph-loop já faz isso há um ano; for/goal apenas o torna um recurso de primeira classe.

Campanhas de correção de bugs. "Resolva todos os erros TypeScript no repositório sem alterar o comportamento do tempo de execução." O validador verifica a contagem de erros. O agente trabalha até zero. Vai para casa.

Três categorias em que for/goal é a ferramenta errada:

Qualquer coisa que exija avaliação do produto durante o voo. "Melhore o fluxo de integração." Isso não é um destino, é uma opinião. O agente produzirá algo. Ele não produzirá o que você deseja, a menos que você escreva primeiro o que deseja nas especificações. Apenas avise.

Qualquer coisa relacionada a sistemas de produção. For/goal é para ambientes onde o pior resultado é "o agente desperdiçou minha tarde". Não "o agente apagou um banco de dados". Aprovação automática e acesso à produção são uma categoria de erro que não gostaria que nenhum de nós cometesse.

Qualquer coisa em que o validador precise avaliar a qualidade. Modelos pequenos não podem responder "este código é bom?" de forma confiável. Eles podem responder "este comando sai do zero?" de forma confiável. Elabore sua pergunta do validador em torno de quais modelos pequenos são bons - decisões yes/no com sinais concretos - ou seu loop irá parar mais cedo ou nunca mais parar.

Se o seu trabalho não se enquadra nessas três categorias "boas", você provavelmente deseja o loop de bate-papo normal Claude Code ou Codex, não o for/goal. A maior parte do meu trabalho real ainda reside no bate-papo normal. For/goal é a ferramenta especializada que uso duas ou três vezes por semana, não o driver diário.

O que eu executaria de maneira diferente na próxima vez

Três pequenas coisas que mudarei em meu próximo experimento for/goal.

Eu adicionaria um arquivo tests.md ao lado de prd.md e pediria ao agente para escrever testes de integração para os caminhos críticos como Fase 0, antes de qualquer UI. Os testes tornam-se então o sinal de parada do validador, que é muito mais forte do que "todas as tarefas do roteiro marcadas". No momento, o loop confia na verificação do próprio agente de que o roteiro está completo; se os testes fossem verdadeiros, o agente não poderia mentir para si mesmo.

Eu apertaria o documento de design. Meu design.md tinha cerca de trezentas palavras de preferências. O próximo terá seiscentas palavras com padrões de componentes específicos destacados - tokens de espaçamento exato, escala de fonte exata, hierarquia exata de botões. Quero dar ao agente menos espaço para inventar o julgamento do design, porque os momentos em que Claude Code e Codex divergiram mais acentuadamente foram os momentos em que o documento de design ficou em silêncio e cada um deles escolheu um padrão diferente.

Eu executaria o mesmo objetivo em ambos os agentes e em um terceiro - Gemini 3 Pro por meio de seu novo CLI, que ainda não testei de estresse neste período de execução. Se dois agentes divergem tanto na mesma especificação, quero saber o que um terceiro me dá. Esse é um post para o próximo mês.

A mudança de mentalidade, declarada claramente

Aqui está o que eu sempre volto.

Seis meses atrás, construir um aplicativo significava escrever código com a ajuda de um agente. O agente foi um acelerador do trabalho. Eu era o motor.

Hoje, com for/goal, construir um aplicativo significa escrever uma especificação com a ajuda de um agente, depois entregá-la a um agente diferente e ler o que retorna. O agente é o motor. Eu sou o arquiteto.

Essa frase é fácil de digitar e difícil de viver. Na maioria dos dias, ainda continuo abrindo o editor e escrevendo o primeiro componente sozinho, porque esse foi o movimento que fiz dez mil vezes. A disciplina de não fazer isso — de permanecer no arquivo de especificações por mais uma hora, de escrever a pergunta do validador em vez da implementação — é a nova habilidade. Os engenheiros que o desenvolverem primeiro serão aqueles que enviarão cinco produtos no tempo que levava para enviar um.

Os dois terminais no meu monitor esquerdo às 15h19 daquela tarde de quarta-feira não eram, em retrospectiva, a parte impressionante. A parte impressionante foram as quatro horas que passei no dia anterior a escrever o PRD, o roteiro e o documento de design. Os agentes executaram em meia hora o que eu teria levado uma semana. O pensamento que tornou possível a meia hora ainda durou o dia.

Esse é o comércio. Tenho certeza que quero isso.

Perguntas frequentes

O que é for/goal em Claude Code e Codex?

For/goal é um modo objetivo persistente em que o agente trabalha de forma autônoma em vários turnos até que um pequeno modelo validador confirme que uma condição de conclusão definida foi atendida. No Claude Code, ele é enviado como /goal na versão 2.1.139; em Codex CLI, o mesmo primitivo reside por trás do /goal e dos comandos de barra relacionados na versão 0.128.0. Consulte "O que For/Goal realmente é" acima para obter a mecânica completa.

Quanto tempo pode durar uma execução for/goal?

As execuções do For/goal são limitadas pelo orçamento que você definiu – turnos, tokens ou tempo de parede – e não por um teto rígido. Já vi execuções de andaimes de 32 minutos e execuções de refatoração noturna bem-sucedidas. O teto prático é o seu orçamento simbólico e a sua disposição de deixar o ciclo continuar sem supervisão.

For/goal é o mesmo que o loop Ralph?

For/goal é uma evolução do padrão de loop Ralph. Ralph era um wrapper bash while true em torno de um agente de codificação com uma etapa de verificação externa; for/goal incorpora a mesma ideia no próprio agente com uma arquitetura de supervisor integrada e um gancho de parada com reconhecimento de estado. Mesma forma, mecânica mais limpa, melhor integração do validador.

Preciso de um PRD para usar for/goal?

Você precisa de um destino claro e baseado em arquivo. Um PRD mais um roteiro é a combinação mais confiável, mas você também pode apontar para/goal em um conjunto de testes, um comando de construção ou uma métrica mensurável. A regra é: o validador tem que ser capaz de responder “o objetivo foi alcançado?” com uma decisão de sim ou não baseada num sinal concreto e não num julgamento de qualidade.

Qual é melhor para for/goal — Claude Code ou Codex?

Nenhum dos dois é estritamente melhor. Em meus testes, Claude Code produz resultados mais comunicativos - páginas de destino, superfícies de marketing, páginas com muitos textos lidas como se uma pessoa as tivesse escrito. Codex produz resultados mais ricos em interação – painéis, ferramentas internas, superfícies com células editáveis ​​e filtros parecem mais sofisticados imediatamente. Escolha pelo que você está enviando.

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