- O principal critério para escolher um agente de programação está mudando do desempenho do modelo em si para o tempo disponível do usuário e o tempo de execução autônoma, com uso de Claude Code e Codex em paralelo conforme a situação
- O Opus se destaca em gerenciamento de janela de contexto e uso de ferramentas, sendo vantajoso para exploração rápida e planejamento ao executar vários subagentes ao mesmo tempo
- O Codex supera o Opus em precisão de código, mas tem a desvantagem de ser mais lento por carecer de delegação de trabalho entre janelas de contexto
- Por meio da automação com skills, foi construído gradualmente um loop de planejamento → implementação → revisão → correção de bugs, e a abordagem eficaz foi automatizar aos poucos o trabalho manual repetitivo, em vez de tentar projetar tudo desde o início
- Em última instância, o caminho aponta para um futuro em que agentes trabalham de forma autônoma 24/7, mas os limites da janela de contexto e a resistência a prompt injection seguem como os principais obstáculos
Contexto
- Trabalhei em tarefas relacionadas à versão web do Codex e saí da OpenAI em julho de 2025
- Organizei este texto para consolidar estratégias mais detalhadas de uso de agentes de programação após o podcast YC Lightcone
- O critério de escolha de agentes está migrando do desempenho do modelo para tempo de execução autônoma e importância da tarefa
- Assino Claude Max, ChatGPT Pro e Cursor Pro+, e a relação custo-benefício em produtividade é alta
Princípio central: entender contexto
- Para usar bem agentes de programação, é indispensável entender contexto (context)
- Por melhor que o agente seja, no fim ele executa next token prediction, e todos os tokens precisam caber dentro da janela de contexto
- Os principais princípios derivados disso:
- É preciso dividir o problema em tamanhos adequados para a janela de contexto; problemas grandes demais demoram mais e produzem resultados piores
- Compaction é uma técnica com perdas: o agente decide o que incluir e o que omitir, e quanto mais compaction houver, maior tende a ser a degradação de desempenho
- Ao externalizar o contexto para o sistema de arquivos com documentos de planejamento e similares, o agente pode ler e lembrar seletivamente sem preencher todo o contexto da conversa
- É importante permanecer na “metade inteligente” da janela de contexto; como o treinamento funciona melhor com contextos menores, resultados melhores tendem a surgir quando a janela está menos cheia — Dex Horthy descreve isso como ficar fora da 'dumb zone'
- Se o agente deixar passar arquivos ou pacotes relevantes, pode seguir por um caminho inesperado; a “divulgação progressiva (progressive disclosure)” da estrutura e arquitetura do codebase ajuda — a OpenAI já publicou um post no blog sobre como estrutura vários arquivos Markdown
- O desempenho e a velocidade do modelo dependem não só da capacidade bruta do modelo, mas também da habilidade de gerenciar múltiplas janelas de contexto e delegar a subagentes/equipes
Opus: gerenciamento de contexto, uso de ferramentas e sensação mais humana
- Uso o Claude Code como ferramenta principal para planejamento, orquestração de terminal e gestão de tarefas com git/GitHub
- O Opus foi treinado para operar de forma muito eficiente entre várias janelas de contexto, então ao usar Claude Code ele parece mais rápido que o Codex
- É comum observar o Opus executando vários subagentes em paralelo, como chamadas
Explore ou Task
- A ferramenta Explore usa Haiku, então consegue processar grandes volumes de tokens rapidamente e repassar o contexto relevante ao Opus
- Ele também é bem treinado para usar ferramentas locais como
gh, git e vários servidores MCP
- A extensão
/chrome também permite verificar bugs, embora possa ser lenta e instável
- O modelo de permissões do Claude Code é mais fácil de entender do que o do Codex — o modelo do Codex tende a roteirizar comandos no bash, o que dificulta whitelisting granular de ferramentas CLI
- Pequenas vantagens de UX do Claude Code: atualiza o título do terminal com o conteúdo da tarefa, mostra o PR atual na barra de status e exibe mensagens curtas de estado
- O Opus é melhor que o Codex para gerar descrições de PR fáceis para humanos entenderem e diagramas de arquitetura detalhados
- Quando quero pedir explicações sobre a estrutura do código, costumo usar Claude Code
- O Opus é mais “criativo” no planejamento, propondo pontos que o usuário não mencionou ou chamando atenção para áreas ambíguas
Codex: precisão de código esmagadora
- A área em que o Codex realmente brilha é a correção (correctness) do código, e outros desenvolvedores que usam bastante modelos concordam com isso
- Quando executado com GPT-5.3-Codex-xhigh ou high, o código do Codex apresenta visivelmente menos bugs
- Erros frequentes do Opus:
- Um componente React passa nos testes unitários, mas ele esquece de adicioná-lo ao
<App> de nível superior
- Não detecta um erro off-by-one óbvio
- Deixa passar dangling references ou race conditions sutis
- Durante muito tempo achei que a diferença entre os dois modelos fosse desprezível, mas depois de ver PRs suficientes com o review automático do Codex e do Cursor Bugbot, concluí que a qualidade de código dos modelos da OpenAI é superior
- Para fazer um teste A/B direto, basta fazer checkout da branch e comparar o
/code-review do Claude Code com o /review do Codex
- Porém, o Codex é lento — a principal razão parece ser a falta de delegação entre janelas de contexto, e a latência entre tokens também parece maior
- O suporte experimental a subagentes (com o toggle
/experimental) funciona, mas ainda não é tão fluido quanto no Claude e ainda carece de paralelismo
- Na prática, o padrão é começar com Claude Code, deixá-lo aberto e, na etapa de codificação de fato, migrar para o Codex
Ferramentas e configurações úteis
- Atualmente estou trabalhando em um codebase greenfield, muito menor e mais eficiente em tokens do que um codebase de produção
- Estrutura do repositório: em todos os repositórios há uma pasta
plans/ com planos numerados, uma pasta apps/ para separar serviços, gerenciamento de monorepo TypeScript com turborepo e instalação rápida com bun
- Ghostty: terminal do Mitchellh, rápido, nativo e em melhoria contínua — por um tempo eu executava várias instâncias de Claude/Codex com tmux, mas hoje uso vários panes na mesma aba do terminal
- Next.js na Vercel, API com Cloudflare Durable Objects: estrutura que pré-particiona o banco de dados, o desperta sob demanda e reduz a preocupação com escritas concorrentes — adequada, do ponto de vista de infraestrutura, para uma era em que agentes lidam com pequenos fragmentos de dados
- A Cloudflare está expandindo nessa direção com a biblioteca cloudflare/actors, unindo computação e armazenamento pequeno co-localizado
- Worktrees: como o código é leve, uso worktrees em paralelo e valido localmente em cada um com
bun install → bun run dev — uso a skill worktree, que copia o plano, variáveis de ambiente e atualizações relacionadas, e inicia uma nova branch
- Antes dos agentes de programação eu usava mais branches, mas a combinação de worktree com Claude Code é extremamente útil
- Plan, Implement, Review: quase sempre faço o modelo começar pelo plano — 1) para externalizar contexto além de uma única janela 2) para poder revisar ou questionar o que foi feito — se o agente parar, é possível retomar o plano em uma nova janela de contexto
- Preview deploys: toda branch recebe um novo deploy de Web + API, o que favorece execução paralela e testes rápidos — é difícil trabalhar sem isso
- Cursor Bugbot e Codex Code Review: uso ambos para entender o código em nível de arquitetura e fazer verificações pontuais, mas cada vez menos leio todas as linhas de todos os PRs — os agentes são melhores para encontrar bugs sutis
- Em certo momento usei Claude Code, Cursor Bugbot e Codex ao mesmo tempo, mas como o Claude Code não detectava problemas relevantes, hoje considero o Cursor a opção padrão, embora o Codex também tenha bons resultados
Skills: a chave da automação
- Defino várias skills e um AGENTS.md/CLAUDE.md compartilhado em um repositório chamado claudefiles
- Regra para adicionar skill: não adiciono precipitadamente; só crio uma depois de repetir algumas vezes e o fluxo de trabalho estar estável
- AGENTS/CLAUDE.md é útil para orientar o modelo de forma geral, e as skills têm dois propósitos:
- Encadear workflows e automatizar — transformar planejamento → implementação por etapas → revisão em skills separadas e compor uma meta-skill que as executa em sequência
- Dividir a janela de contexto — ao configurar
context: fork na chamada de skill no Claude Code, ela pode rodar em uma nova janela, separando o “orquestrador mestre” dos subagentes
- Skills são muito eficientes em contexto: ao contrário de chamadas MCP, que podem consumir milhares de tokens, normalmente usam ~50-100 tokens
Evolução da automação com skills
- No começo, eu me interessava pela ideia de um marketplace de skills (instalar design de frontend, checagem de segurança, revisão de arquitetura etc.), mas ao longo do trabalho abandonei a maioria das skills escritas por outras pessoas
- Em vez disso, passei a fazer primeiro o trabalho manualmente e só depois pensar em como automatizá-lo
- Evolução das skills:
/commit: em vez de instruir o modelo de várias formas a fazer commit e push, consolidei tudo em uma única skill — inspirada diretamente no Claude Code/worktree: faz o agente trabalhar em um worktree separado, criando um novo worktree com base no número do plano (ex.: 00034-add-user-auth)/implement: reúne em uma única skill o trabalho repetitivo de executar uma etapa do plano e depois rodar /commit/implement-all: vincula o caminho do worktree atual ao número do plano e implementa automaticamente todas as etapas — em execuções noturnas, uso /ralph-loop para continuar até concluir tudo, e um /codex-review local para criar o processo codex --review/address-bugs: busca comentários do Cursor + Codex via API do GitHub desde o último commit e tenta validar e corrigir bugs/pr-pass: executa ao fim de /implement-all e 1) faz push remoto 2) espera todo o CI passar 3) executa /address-bugs, repetindo opcionalmente a etapa 1/focus: consulta o diretório plans, PRs incompletos e worktrees para refrescar a memória e ajudar a rastrear o trabalho
- Se eu tivesse tentado criar esse processo desde o início, provavelmente não teria dado certo; o ponto-chave foi construí-lo gradualmente, descobrindo pequenas áreas automatizáveis com o tempo
Outras ferramentas
- Testei recentemente o Codex App e tive impressão positiva dos detalhes e pequenos toques — ainda assim, prefiro a flexibilidade da CLI e não migrei totalmente
- Também experimentei o Cowork, mas foi difícil fazê-lo funcionar direito; nos dois casos, o modelo de sandboxing faz grande diferença
- Uso ocasionalmente interfaces web para trabalho assíncrono, mas estou cada vez mais dependente da CLI — em contraste com 6 meses atrás, quando eu usava principalmente o Cursor e seus agentes/extensões embutidos
- Estou usando pencil.dev para trabalho de UI de frontend — o modelo de deploy, que faz shell out para um Claude Code local e reutiliza assinaturas existentes, é interessante
- Sinto necessidade de um issue tracker mais estruturado, e Dex, do David Cramer, e beads, do Steve Yegge, parecem promissores, mas ainda me parecem mais complexos do que o necessário
- No momento, não uso MCPs automatizados de e2e como Playwright
Conselhos para os laboratórios
-
Feedback para a Anthropic
- Modelo: o Opus tem sensação mais humana, é excelente com ferramentas de engenharia, divisão de contexto e em sugerir “o que o usuário pode ter esquecido”, mas carece de precisão de código — espero um modo “Opus Strict” que reforce RL no modelo base para melhorar o desempenho
- Eu começo com Opus, mas quem escreve o código é o Codex; se houver restrição de orçamento, eu escolheria Codex
- Harness de produto: há muito pouco a criticar, e as ideias do Boris e da Cat são excelentes
- Gostaria que adotassem um padrão de agent skills — trabalhar com symlinks de diretório entre CLIs é inconveniente
- Gostaria que publicassem o formato de saída de
--stream-json — tenho interesse em executar Claude Code em sandbox em nome dos usuários, mas mudanças de formato preocupam, e configurar caminhos é mais trabalhoso do que em outras CLIs como Codex, Cursor e Gemini
-
Feedback para a OpenAI
- Modelo: a principal prioridade de melhoria é divisão entre janelas de contexto e delegação a subagentes — também seria útil a noção de “fazer mais do que foi pedido” que o Opus demonstra no planejamento
- Feedback detalhado sobre o harness de produto:
- O modelo de sandboxing é difícil de entender em comparação com o Claude Code — como o modelo tenta criar scripts, há muitos pedidos de aprovação, o que preocupa ao rodar em modo
--yolo
- Gostaria de um guia do usuário embutido na CLI, como no Claude Code — para poder perguntar sobre localização de skills, campos suportados, configuração do modelo de sandboxing etc.
- Gostaria que
/review fosse convertido de comando empacotado para skill genérica, para que o modelo possa chamá-lo dinamicamente
- Gostaria que a execução mudasse o título da aba do terminal para algo relacionado à tarefa, como no Claude Code — dezenas de abas
codex geram confusão
- É preciso treinamento especializado para descrições de PR e commits — o estilo conciso do Codex é bom, mas falta expandir explicações
- Gostaria de suporte a
context: fork em definições de skill
- Corrigir links em pane para que continuem clicáveis mesmo quando quebram de linha
- Gostaria de ver o worktree/PR/nome da branch atual na barra inferior de status
Perspectivas futuras
- Cita o post Gas Town, de Steve Yegge — a ideia é usar sempre o máximo de tokens, manter um pool de trabalhadores rodando 24/7 e esperar que muitos planos sejam feitos e descartados
- Independentemente de a abstração estar exatamente correta ou não, a avaliação é de que a direção está absolutamente certa
- Futuro ideal: um laptop ou sandbox na nuvem processando ideias continuamente em segundo plano, enquanto o usuário ajusta a direção, faz pesquisa ou revisa resultados
- Trabalhar com agentes de programação parece parecido com o papel de gerente de engenharia, mas sem precisar se preocupar com motivação ou personalidade dos agentes
- Hoje já estamos bastante próximos desse futuro — no Twitter há exagero, mas na prática já existe a rotina de iniciar 3 ou 4 tarefas no Codex antes de dormir e revisar tudo pela manhã
- Ainda assim, ainda não estamos no nível de rodar agentes 24/7
- Há duas barreiras principais impedindo um avanço maior:
- Tamanho/coordenação da janela de contexto — o agente não pode comprimir e reutilizar infinitamente a mesma janela; são necessários harnesses ou mecanismos de delegação mais inteligentes
- Resistência a prompt injection — o agente pede aprovações em poucos minutos, e não dá para confiar no modo
--yolo, embora exista um subconjunto aceitável de permissões/domínios
- Sobre o primeiro problema, o Cursor está forçando os limites de um swarm de agentes em múltiplas janelas de contexto; o segundo continua sendo uma área ativa de pesquisa
- Executar em sandbox é hoje o melhor contorno, mas a configuração ainda é trabalhosa, e se o agente tiver acesso à internet aberta e a dados privilegiados ao mesmo tempo, ele fica vulnerável ao que Simon Willison chamou de “Lethal Trifecta”
- Como engenheiro solo, o gargalo já está sendo ter as ideias certas, e cada vez mais ideias, arquitetura e sequenciamento de projetos serão os fatores limitantes para construir ótimos produtos
4 comentários
Até a arquitetura também..?
Se o Codex tivesse ao menos a função de subagentes, acho que eu migraria. Mas enfim, será que não têm interesse nisso..
https://developers.openai.com/codex/multi-agent
Ainda está em fase experimental, mas parece que estão avançando.
No codex cli, se você digitar o comando
/experimental, ele oferece Multi-agents como recurso experimental.› [x] Multi-agents Ask Codex to spawn multiple agents to parallelize the work and win in efficiency.
Não sei se isso é exatamente da mesma linha que o subagente que você mencionou, mas vale a pena dar uma olhada.