Não uso mais o Codex ou o Claude Code diretamente.
Uso o OpenClaw como minha camada de orquestração. Minha orquestradora, Zoe, cria os agentes, escreve seus prompts, escolhe o modelo certo para cada tarefa, monitora o progresso e me avisa no Telegram quando os PRs estão prontos para merge.
Evidências das últimas 4 semanas:
- 94 commits em um dia. Meu dia mais produtivo — tive 3 ligações com clientes e não abri meu editor uma vez. A média é cerca de 50 commits por dia.
- 7 PRs em 30 minutos. Da ideia à produção é incrivelmente rápido porque codificação e validações são majoritariamente automatizadas.
- Commits → MRR: Uso isso para um SaaS B2B real que estou construindo — combinando com vendas lideradas pelo fundador para entregar a maioria dos pedidos de funcionalidades no mesmo dia. Velocidade converte leads em clientes pagantes.

Meu histórico do git parece que acabei de contratar uma equipe de devs. Na realidade, sou só eu passando de gerenciar o claude code para gerenciar um agente openclaw que gerencia uma frota de outros agentes claude code e codex.
Taxa de sucesso: O sistema resolve quase todas as tarefas pequenas e médias sem qualquer intervenção.
Custo: ~$100/mês para Claude e $90/mês para Codex, mas você pode começar com $20.
Aqui está por que isso funciona melhor do que usar Codex ou Claude Code diretamente:
Codex e Claude Code têm muito pouco contexto sobre o seu negócio.
Eles veem código. Eles não veem o quadro completo do seu negócio.
O OpenClaw muda a equação. Ele atua como a camada de orquestração entre você e todos os agentes — ele mantém todo o meu contexto de negócio (dados de clientes, notas de reuniões, decisões passadas, o que funcionou, o que falhou) dentro do meu cofre Obsidian, e traduz o contexto histórico em prompts precisos para cada agente de codificação. Os agentes permanecem focados no código. O orquestrador fica no nível estratégico alto.
Aqui está como o sistema funciona em um nível alto:

Semana passada o Stripe escreveu sobre seu sistema de agentes em segundo plano chamado "Minions" — agentes de codificação paralelos apoiados por uma camada de orquestração centralizada. Eu acidentalmente construí a mesma coisa, mas roda localmente no meu Mac mini.
Antes de eu te contar como configurar isso, você deve saber POR QUE você precisa de um orquestrador de agentes.
Por que uma IA não consegue fazer os dois
Janelas de contexto são soma zero. Você tem que escolher o que entra.
Preencha com código → sem espaço para contexto de negócio. Preencha com histórico do cliente → sem espaço para a base de código. É por isso que o sistema de dois níveis funciona: cada IA é carregada exatamente com o que precisa.
OpenClaw e Codex têm contextos drasticamente diferentes:

Especialização através do contexto, não através de modelos diferentes.
O Fluxo de Trabalho Completo em 8 Etapas
Deixe-me mostrar um exemplo real da semana passada.
Etapa 1: Solicitação do Cliente → Escopo com Zoe
Eu tive uma ligação com um cliente agência. Eles queriam reutilizar configurações que já haviam configurado em toda a equipe.
Após a ligação, conversei sobre a solicitação com a Zoe. Como todas as minhas notas de reunião sincronizam automaticamente para meu cofre obsidian, nenhuma explicação foi necessária da minha parte. Nós escopamos a funcionalidade juntos — e chegamos a um sistema de templates que permite que eles salvem e editem suas configurações existentes.
Então Zoe faz três coisas:
- Adiciona créditos para desbloquear o cliente imediatamente — ela tem acesso de API de admin
- Puxa a configuração do cliente do banco de produção — ela tem acesso de leitura ao banco de produção (meus agentes codex nunca terão isso) para recuperar a configuração existente deles, que é incluída no prompt
- Cria um agente Codex — com um prompt detalhado contendo todo o contexto
Etapa 2: Criar o Agente
Cada agente recebe sua própria worktree (branch isolada) e sessão tmux:
1# Create worktree + spawn agent2git worktree add ../feat-custom-templates -b feat/custom-templates origin/main3cd ../feat-custom-templates && pnpm install45tmux new-session -d -s "codex-templates" \6 -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \7 "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"
O agente roda em uma sessão tmux com registro completo do terminal através de um script.
Aqui está como lançamos agentes:
1# Codex2codex --model gpt-5.3-codex \3 -c "model_reasoning_effort=high" \4 --dangerously-bypass-approvals-and-sandbox \5 "Your prompt here"67# Claude Code8claude --model claude-opus-4.5 \9 --dangerously-skip-permissions \10 -p "Your prompt here"
Eu costumava usar codex exec ou claude -p, mas recentemente mudei para tmux:
tmux é muito melhor porque o redirecionamento no meio da tarefa é poderoso. Agente indo na direção errada? Não o mate:
1# Wrong approach:2tmux send-keys -t codex-templates "Stop. Focus on the API layer first, not the UI." Enter34# Needs more context:5tmux send-keys -t codex-templates "The schema is in src/types/template.ts. Use that." Enter
A tarefa é rastreada em .clawdbot/active-tasks.json:
1{2 "id": "feat-custom-templates",3 "tmuxSession": "codex-templates",4 "agent": "codex",5 "description": "Custom email templates for agency customer",6 "repo": "medialyst",7 "worktree": "feat-custom-templates",8 "branch": "feat/custom-templates",9 "startedAt": 1740268800000,10 "status": "running",11 "notifyOnComplete": true12}
Quando completa, atualiza com número do PR e verificações. (Mais sobre isso na etapa 5)
1{2 "status": "done",3 "pr": 341,4 "completedAt": 1740275400000,5 "checks": {6 "prCreated": true,7 "ciPassed": true,8 "claudeReviewPassed": true,9 "geminiReviewPassed": true10 },11 "note": "All checks passed. Ready to merge."12}
Etapa 3: Monitoramento em Loop
Um cron job roda a cada 10 minutos para cuidar de todos os agentes. Isso basicamente funciona como um Ralph Loop melhorado, mais sobre isso depois.
Mas ele não consulta os agentes diretamente — isso seria caro. Em vez disso, roda um script que lê o registro JSON e verifica:
1.clawdbot/check-agents.sh
O script é 100% determinístico e extremamente eficiente em tokens:
- Verifica se as sessões tmux estão ativas
- Verifica se há PRs abertos nas branches rastreadas
- Verifica o status do CI via gh cli
- Reinicia automaticamente agentes que falharam (máximo de 3 tentativas) se o CI falhar ou feedback crítico de revisão
- Só alerta se algo precisa de atenção humana
Não estou assistindo terminais. O sistema me diz quando olhar.
Etapa 4: Agente Cria PR
O agente commita, envia e abre um PR via \gh pr create --fill\. Neste ponto eu NÃO sou notificado — só um PR não está pronto.
Definição de pronto (muito importante que seu agente saiba disso):
- PR criado
- Branch sincronizada com a main (sem conflitos de merge)
- CI passando (lint, types, testes unitários, E2E)
- Revisão do Codex aprovada
- Revisão do Claude Code aprovada
- Revisão do Gemini aprovada
- Screenshots incluídas (se houver mudanças na UI)
Etapa 5: Revisão de Código Automatizada
Cada PR é revisado por três modelos de IA. Eles pegam coisas diferentes:
- Revisor Codex — Excepcional em casos de borda. Faz a revisão mais completa. Pega erros de lógica, tratamento de erros faltando, condições de corrida. Taxa de falso positivo muito baixa.
- Revisor Gemini Code Assist — Grátis e incrivelmente útil. Pega problemas de segurança, problemas de escalabilidade que outros agentes perdem. E sugere correções específicas. Não pensar duas vezes para instalar.
- Revisor Claude Code — Principalmente inútil — tende a ser excessivamente cauteloso. Muitas sugestões "considere adicionar..." que geralmente são engenharia excessiva. Eu pulo tudo a menos que esteja marcado como crítico. Raramente encontra problemas críticos por conta própria, mas valida o que os outros revisores apontam.
Todos os três postam comentários diretamente no PR.
Etapa 6: Testes Automatizados
Nosso pipeline de CI roda uma quantidade pesada de testes automatizados:
- Verificações de Lint e TypeScript
- Testes unitários
- Testes E2E
- Testes Playwright contra um ambiente de preview (idêntico ao de produção)
Eu adicionei uma nova regra semana passada: se o PR mudar qualquer UI, deve incluir um screenshot na descrição do PR. Caso contrário, o CI falha. Isso encurta dramaticamente o tempo de revisão — posso ver exatamente o que mudou sem clicar no preview.
Etapa 7: Revisão Humana
Agora recebo a notificação do Telegram: "PR #341 pronto para revisão."
Neste ponto:
- CI passou
- Três revisores de IA aprovaram o código
- Screenshots mostram as mudanças na UI
- Todos os casos de borda estão documentados nos comentários de revisão
Minha revisão leva de 5 a 10 minutos. Muitos PRs eu faço merge sem ler o código — o screenshot me mostra tudo que preciso.
Etapa 8: Merge
PR faz merge. Um cron job diário limpa worktrees órfãs e o json do registro de tarefas.
O Ralph Loop V2
Isso é essencialmente o Ralph Loop, mas melhor.
O Ralph Loop puxa contexto da memória, gera saída, avalia resultados, salva aprendizados. Mas a maioria das implementações roda o mesmo prompt a cada ciclo. Os aprendizados destilados melhoram recuperações futuras, mas o prompt em si permanece estático.
Nosso sistema é diferente. Quando um agente falha, Zoe não apenas o reinicia com o mesmo prompt. Ela analisa a falha com contexto completo de negócio e descobre como desbloqueá-lo:
- Agente ficou sem contexto? "Foque apenas nesses três arquivos."
- Agente foi na direção errada? "Pare. O cliente queria X, não Y. Aqui está o que eles disseram na reunião."
- Agente precisa de esclarecimento? "Aqui está o email do cliente e o que a empresa dele faz."
Zoe cuida dos agentes até a conclusão. Ela tem contexto que os agentes não têm — histórico do cliente, notas de reunião, o que tentamos antes, por que falhou. Ela usa esse contexto para escrever prompts melhores em cada tentativa.
Mas ela também não espera que eu atribua tarefas. Ela encontra trabalho proativamente:
- Manhã: Escaneia Sentry → encontra 4 novos erros → cria 4 agentes para investigar e corrigir
- Após reuniões: Escaneia notas de reunião → sinaliza 3 pedidos de funcionalidades que clientes mencionaram → cria 3 agentes Codex
- Noite: Escaneia git log → cria Claude Code para atualizar changelog e documentação do cliente
Eu saio para uma caminhada depois de uma ligação com cliente. Volto para o Telegram: "7 PRs prontos para revisão. 3 funcionalidades, 4 correções de bugs."
Quando agentes têm sucesso, o padrão é registrado. "Essa estrutura de prompt funciona para funcionalidades de faturamento." "Codex precisa das definições de tipo antecipadamente." "Sempre inclua os caminhos dos arquivos de teste."
Os sinais de recompensa são: CI passando, todas as três revisões de código passando, merge humano. Qualquer falha aciona o loop. Com o tempo, Zoe escreve prompts melhores porque ela lembra o que foi enviado.
Escolhendo o Agente Certo
Nem todos os agentes de codificação são iguais. Referência rápida:
Codex é meu cavalo de batalha. Lógica de backend, bugs complexos, refatorações em múltiplos arquivos, qualquer coisa que exija raciocínio através da base de código. É mais lento, mas completo. Eu o uso para 90% das tarefas.
Claude Code é mais rápido e melhor para trabalho de frontend. Também tem menos problemas de permissão, então é ótimo para operações git. (Eu costumava usar mais para conduzir o dia a dia, mas Codex 5.3 é simplesmente melhor e mais rápido agora)
Gemini tem um superpoder diferente — sensibilidade de design. Para UIs bonitas, peço ao Gemini para gerar uma especificação HTML/CSS primeiro, e depois passo para o Claude Code implementar em nosso sistema de componentes. Gemini projeta, Claude constrói.
Zoe escolhe o agente certo para cada tarefa e roteia saídas entre eles. Um bug no sistema de faturamento vai para Codex. Uma correção de estilo de botão vai para Claude Code. Um novo design de dashboard começa com Gemini.
Como Configurar Isso
Copie este artigo inteiro no OpenClaw e diga: "Implemente esta configuração de enxame de agentes para minha base de código."
Ele lerá a arquitetura, criará os scripts, configurará a estrutura de diretórios e configurará o monitoramento cron. Feito em 10 minutos.
Nenhum curso para te vender.
O Gargalo que Ninguém Espera
Aqui está o limite que estou enfrentando agora: RAM.
Cada agente precisa de sua própria worktree. Cada worktree precisa de seu próprio
ode_modules\. Cada agente roda builds, verificações de tipo, testes. Cinco agentes rodando simultaneamente significa cinco compiladores TypeScript paralelos, cinco executores de teste, cinco conjuntos de dependências carregadas na memória.
Meu Mac Mini com 16GB atinge o limite com 4-5 agentes antes de começar a fazer swap — e preciso ter sorte de que eles não tentem construir ao mesmo tempo.
Então comprei um Mac Studio M4 max com 128GB RAM ($3,500) para alimentar este sistema. Chega no final de março e compartilharei se vale a pena.
A Próxima: A Empresa de Um Milhão de Dólares com Uma Pessoa
Vamos ver muitas empresas de um milhão de dólares com uma pessoa começando em 2026. A alavancagem é massiva para aqueles que entendem como construir agentes auto-melhoráveis recursivamente.
É assim que se parece: um orquestrador de IA como uma extensão de si mesmo (como Zoe é para mim), delegando trabalho a agentes especializados que lidam com diferentes funções de negócio. Engenharia. Suporte ao cliente. Operações. Marketing. Cada agente focado no que é bom. Você mantém foco laser e controle total.
A próxima geração de empreendedores não contratará uma equipe de 10 para fazer o que uma pessoa com o sistema certo pode fazer. Eles construirão assim — permanecendo pequenos, movendo-se rápido, enviando diariamente.
Há tanto lixo gerado por IA agora. Tanto hype em torno de agentes e "centros de comando" sem construir nada realmente útil. Demos chiques sem benefícios no mundo real.
Estou tentando fazer o oposto: menos hype, mais documentação de construção de um negócio real. Clientes reais, receita real, commits reais que vão para produção, e perda real também.
O que estou construindo? Agentic PR — uma empresa de uma pessoa enfrentando os titãs de relações públicas empresariais. Agentes que ajudam startups a obter cobertura de imprensa sem um retentor de $10k/mês.
Se você quiser ver até onde vou com isso, acompanhe.





