O Codex pode trabalhar por longos períodos, especialmente quando um /goal lhe dá um objetivo persistente. A parte mais difícil é manter a orientação enquanto ele trabalha por horas ou dias, descobre novos detalhes de implementação e passa por vários tipos de verificação.
Suposições iniciais frequentemente mudam quando a implementação começa. O modelo de colaboração precisa preservar o objetivo, dando a você e ao Codex espaço para revisar o plano à medida que novas evidências surgem.
Nas últimas semanas, tenho usado cinco práticas:
- Deixar o Codex planejar o trabalho e manter o roteiro.
- Manter o thread principal focado na coordenação.
- Auditar o roteiro e revisar o código após cada marco.
- Usar threads locais para testes com Computer Use.
- Relatar o progresso por meio de atualizações concisas e painéis.
Gerado com GPT Image 2 no Codex
1. Deixar o Codex planejar o trabalho e manter o roteiro
Geralmente começo com uma conversa, em vez do modo /plan. Descrevo o que estou tentando construir, dito pensamentos gerais, compartilho restrições e deixo o Codex fazer perguntas até ter contexto suficiente para propor um plano inicial.
Isso mantém a discussão inicial flexível. Não preciso transformar ideias mal formuladas em uma especificação formal antes que o Codex possa começar a ajudar. Ele pode me entrevistar, refletir sobre o que entendeu, identificar lacunas e, gradualmente, transformar a conversa em um plano viável.
À medida que o projeto toma forma, peço ao Codex para definir o Goal atual. O modo Goal dá ao Codex um objetivo persistente, permitindo que ele continue trabalhando em direção ao mesmo resultado em várias etapas até que o objetivo seja concluído, bloqueado ou substituído.
Posso definir o objetivo eu mesmo com /goal, mas geralmente peço ao Codex para fazê-lo. O modo Goal é exposto através do harness, então o Codex pode sintetizar nossa conversa, o contexto do projeto e tudo o que aprendeu até agora em um objetivo claro. Ele também pode definir as evidências necessárias antes de considerar esse objetivo concluído.
Para projetos maiores, peço ao Codex para escrever o roteiro mais amplo em GOALS.md. Esta é uma convenção do projeto, não um recurso integrado do Codex, e o arquivo pode ter o nome que você preferir.
Geralmente organizo GOALS.md em torno de marcos, em vez de uma lista plana de tarefas. Cada marco registra:
- o resultado pretendido
- o trabalho atualmente no escopo
- decisões importantes
- bloqueadores conhecidos
- as evidências necessárias antes de prosseguir
O Codex mantém o arquivo à medida que o projeto se desenvolve. Novas descobertas podem alterar o escopo de um marco, introduzir outro ou mudar as evidências necessárias para a conclusão.
Apenas um objetivo do modo Goal está ativo por vez. À medida que os marcos são concluídos, o Codex atualiza GOALS.md, ativa o próximo objetivo e continua trabalhando para alcançá-lo.
2. Manter o thread principal focado na coordenação
Uma vez que o roteiro existe, mantenho o thread principal focado no objetivo, restrições, decisões e estado atual do projeto.
Ele decide o que deve acontecer em seguida, delega tarefas delimitadas e avalia os resultados. Não precisa carregar todos os detalhes de implementação.
Um trabalhador pode passar uma hora lendo código desconhecido, tentando várias abordagens ou rastreando um teste com falha. O coordenador só precisa das informações que afetam o projeto mais amplo:
- o que o trabalhador aprendeu
- o que mudou
- as evidências de apoio
- o que deve acontecer em seguida
O Codex pode delegar este trabalho a um subagente ou criar um thread separado. Funcionalmente, eles podem realizar a mesma tarefa. Uso um thread separado quando espero revisitar o trabalho mais tarde, pois ele permanece visível no aplicativo Codex e mantém seu próprio histórico.
Isso se torna especialmente útil quando várias partes do trabalho estão sendo executadas em paralelo. O thread principal pode continuar coordenando o projeto enquanto cada investigação, implementação ou revisão permanece fácil de inspecionar.
3. Auditar o roteiro e revisar o código após cada marco
GOALS.md reflete o que era conhecido quando o Codex o atualizou pela última vez. No final de um marco, o projeto geralmente descobriu algo novo.
Antes de prosseguir, peço a outro thread para comparar o roteiro com o estado atual:
- O marco está realmente completo?
- O próximo objetivo ainda é o correto?
- Algum marco está faltando?
- Novas evidências mudaram a ordem do trabalho?
- A definição de concluído ainda é válida?
Eu realizo esta auditoria no final de cada marco, bem como sempre que novas evidências mudam materialmente a direção do projeto.
Também executo /review na implementação.
Suponha que a implementação e os testes remotos para um fluxo de login estejam completos. A auditoria do roteiro pode notar que ninguém testou o fluxo em um navegador real com sessão iniciada. Ao mesmo tempo, /review pode descobrir que o novo caminho armazena um token incorretamente, mesmo que os testes remotos passem.
O coordenador atualiza GOALS.md, delega a correção do token, adiciona a verificação de navegador ausente e só então ativa o próximo marco.
Geralmente mantenho auditorias e revisões em threads separados. Um subagente poderia realizar o mesmo trabalho, mas um thread separado deixa um registro visível ao qual posso retornar mais tarde.
4. Usar threads locais para testes com Computer Use
A maioria das minhas sessões do Codex é executada em uma instância remota, para que o trabalho possa continuar enquanto meu laptop está fechado. Algumas verificações ainda dependem da minha máquina local:
- um navegador com sessão iniciada
- credenciais locais
- Xcode
- permissões do macOS
- o iOS Simulator
O coordenador remoto pode criar um thread local para uma dessas verificações. Eu aplico o diff remoto ou faço checkout do branch ou commit relevante para que o thread local teste o código correto.
O thread local opera o navegador ou aplicativo e retorna capturas de tela, logs e descobertas. Quando uma verificação falha, um trabalhador remoto corrige o problema e o thread local testa novamente.
Um loop típico se parece com isso:
- Um trabalhador remoto implementa o fluxo de login.
- Testes remotos passam.
- Um thread local usa a extensão Codex para Chrome.
- O teste do navegador revela um bug de redirecionamento.
- Um trabalhador remoto o corrige.
- O thread local repete a verificação.
O projeto permanece remoto por padrão. Meu computador entra apenas para as verificações que o exigem. O thread remoto também pode continuar verificando se o thread local fica disponível novamente quando eu reabro meu laptop.
5. Relatar o progresso por meio de atualizações concisas e painéis
Threads de trabalho geralmente relatam sobre uma tarefa. Quando volto ao projeto, preciso de uma visão geral do estado:
- o que está completo
- o que mudou
- o que resta
- o que precisa de uma decisão
Peço ao Codex para relatar sempre que o estado do projeto muda, usando três seções curtas:
**O que está feito
O que vem a seguir
Quaisquer bloqueadores**
O que é quase como ter uma daily standup com o Codex, embora de hora em hora.
O Codex pode enviar a mesma atualização através do Slack, seja como uma mensagem direta ou em um canal de projeto dedicado.
Enquanto estou no aplicativo Codex, também uso /side para fazer check-in sem interromper o thread principal. No thread lateral, posso pedir um resumo do que foi concluído, o que resta e se algo precisa da minha ajuda—por exemplo, um clique manual, aprovação ou outra peça de clickops.
Obtendo um resumo do thread lateral
Pedindo ao thread lateral para transmitir minhas instruções ao thread principal
Posso então esclarecer uma instrução, resolver um bloqueador, adicionar contexto ou pedir ao thread lateral para enviar orientações atualizadas de volta ao thread principal.
Para projetos com vários marcos ou fluxos de trabalho paralelos, também mantenho um progress-dashboard.html. Este é um artefato de projeto personalizado, não uma interface de usuário integrada do Codex. Ele pode mostrar:
- o objetivo ativo
- marcos concluídos
- evidências
- bloqueadores
- decisões
- atualizações recentes
Quando volto após várias horas, posso entender o estado do projeto sem ler cada thread de trabalhador. O Codex também pode implantar o painel como um Site para que permaneça acessível remotamente.
Resumo
Eu uso esta estrutura quando um projeto provavelmente descobrirá novas informações, envolverá várias partes de trabalho independentes ou exigirá evidências de mais de um ambiente.
O fluxo de trabalho segue um ciclo simples. O Codex transforma a conversa inicial em um roteiro, ativa um marco, delega o trabalho e verifica o resultado antes de prosseguir. Threads locais lidam com as verificações que exigem minha máquina, enquanto atualizações e painéis me ajudam a retornar ao projeto sem reconstruir tudo do zero.
A parte importante é manter o estado do projeto atualizado o suficiente para que a próxima decisão reflita o que o Codex realmente aprendeu.
Experimente
Cole isto em um novo thread do Codex:
Coordene isto como um projeto de longa duração.
Comece entrevistando-me sobre o que estou tentando construir. Deixe-me descrever ideias e restrições gerais de forma conversacional e, em seguida, transforme essa discussão em um plano inicial.
Crie GOALS.md como o roteiro compartilhado. Organize-o em torno de marcos, com o resultado pretendido, escopo, decisões, bloqueadores e evidências necessárias para cada um.
Defina e mantenha um objetivo do modo Goal por vez. O objetivo ativo deve corresponder ao marco atual.
Mantenha este thread focado no objetivo, restrições, decisões e estado do projeto. Delegue a implementação a subagentes ou novos threads.
Exija que os trabalhadores retornem conclusões, mudanças e evidências, em vez de transcrições completas.
Use threads separados quando eu possa querer inspecionar, continuar ou revisar o trabalho mais tarde. Use subagentes para trabalho delimitado que não precisa de seu próprio histórico visível.
Após cada marco, use um thread separado para auditar GOALS.md em relação ao estado atual e executar /review na implementação. Atualize o roteiro antes de ativar o próximo objetivo.
Use threads locais para testes com Computer Use que dependem do meu navegador, aplicativos de desktop, permissões, credenciais ou estado do dispositivo.
*Quando o estado do projeto mudar, relate apenas: - O que está feito - O que vem a seguir - Quaisquer bloqueadores*
Mantenha progress-dashboard.html quando o projeto abranger vários marcos ou trabalhadores. Não declare conclusão até que as evidências acordadas existam.
Alternativamente, você também pode tirar um Appshot deste artigo e pedir ao Codex:
Crie uma habilidade Codex reutilizável chamada orchestrate-projects a partir deste artigo.
Preserve estas práticas:
*- deixe o Codex me entrevistar e criar os planos iniciais - use GOALS.md como um roteiro baseado em marcos - mantenha um objetivo do modo Goal ativo por vez - mantenha o thread principal focado na coordenação - audite o roteiro e execute /review após cada marco - use threads separados para trabalhos que eu possa querer revisitar - use threads locais para testes com Computer Use - relate o progresso por meio de atualizações concisas, Slack e progress-dashboard.html*
