No último mês de dezembro, Boris Cherny enviou 259 pull requests em um único mês. Todas escritas pelo Claude. Ele diz que não abriu um editor o tempo todo.
O trabalho dele não era escrever código. Era escrever a coisa que escreve o código. Peter Steinberger resumiu em duas linhas que já foram vistas mais de 8 milhões de vezes: "Você não deveria mais dar prompts para agentes de código. Você deveria projetar loops que dão prompts para seus agentes."
Isso é engenharia de loops. Você constrói um sistema pequeno que encontra o trabalho, entrega para um agente, verifica o resultado e decide o próximo passo; então você o deixa rodar enquanto dorme.
A pegadinha chegou no mesmo mês. O loop de outra pessoa rodou por onze dias sem supervisão e queimou $47.000 antes que alguém percebesse. Então, na verdade, são duas habilidades, e quase todo mundo ensina só a primeira: construir um loop que entrega trabalho, e construir os freios que impedem que ele te jogue de um penhasco.
Uma pergunta decide qual loop você construiu: ele converge para algo verdadeiro, ou é apenas uma caminhada aleatória cara?
1. Um loop tem seis partes e uma pergunta
Por baixo do barulho, um loop funcional tem seis partes. A lista parece simples demais na primeira vez que você a vê. O detalhe dentro de cada parte é onde um loop ou se sustenta ou vaza dinheiro durante a noite.
Você não constrói mais nada disso manualmente. Um ano atrás, um loop significava uma pilha de shell scripts que você possuía e cuidava para sempre. Agora, as peças vêm dentro dos produtos, e as mesmas seis se aplicam tanto ao aplicativo OpenAI Codex quanto ao Claude Code. Depois que você percebe isso, a ferramenta deixa de ser o argumento e o loop se torna o design.
1PEÇA FUNÇÃO NO LOOP CODEX CLAUDE CODE2------------- ------------------------ ------------------------- --------------------------3Estado lembrar entre execuções markdown / Linear (MCP) markdown / Routines + MCP4Automações rodar em um agendamento Guia Automações + Triage /loop (skill), Routines, /goal5Worktrees isolar agentes paralelos Worktree por thread --worktree, isolation: worktree6Habilidades codificar sua intenção ~/.agents/skills/SKILL.md ~/.claude/skills/SKILL.md7Conectores tocar suas ferramentas reais Servidores MCP (config.toml) Servidores MCP (.mcp.json)8Subagentes separar quem faz de quem verifica TOML em .codex/agents/ .claude/agents/ + agent teams
2. Estado é a única coisa que a próxima execução herda
Comece pela base, porque todo o resto depende dela.
Um modelo esquece quando uma execução termina. A conversa morre, o contexto é limpo, a próxima execução acorda sem saber de nada. A memória no chat morre com a execução. Ela precisa viver no disco.
Na prática, isso é um arquivo. Um STATUS.md no repositório, ou um quadro do Linear acessado por um conector, contendo o que está feito, o que está em andamento, o que vem a seguir e as poucas coisas que o loop nunca deve tocar.
1# STATUS.md (o loop lê isso primeiro, escreve por último)2## Feito3- [x] auth: migrado para tokens v2, testes verdes4## Em andamento5- [ ] billing: refatoração do webhook (PR #214, CI vermelho)6## Próximo7- [ ] dashboard: teste instável em test/charts8## Nunca9- não modificar infra/ sem um humano
Trate o loop como um turno noturno que você nunca observa. Você não é julgado pelo que ele fez às 3h da manhã. Você é julgado pelo bilhete esperando na sua mesa às 9h. Projete esse bilhete primeiro e a maior parte do loop se projeta sozinha.
3. Automações são a diferença entre um loop e algo que você executou uma vez
Um loop só merece o nome quando dispara sozinho.
No aplicativo Codex, você constrói um na guia Automações: o repositório, o prompt, a cadência. Execuções que encontram algo vão para uma caixa de entrada Triage; execuções que não encontram nada se arquivam. A OpenAI usa isso para a espinha dorsal nada glamorosa de uma base de código: triagem diária de issues, resumos de falhas de CI, pegar o bug que alguém introduziu na semana passada.
O Claude Code chega lá através de alguns primitivos, e os artigos populares erram os detalhes, então vale a pena ser exato. /loop é uma habilidade, não um comando nativo, e reexecuta um prompt em uma cadência enquanto sua sessão estiver aberta. Tarefas recorrentes em nuvem são Routines, definidas com /schedule, com um mínimo de uma hora, e continuam rodando com seu laptop fechado. Não há crontab local.
Vale a pena aprender /goal. Ele é executado até que uma condição que você escreveu seja verdadeira, e após cada turno, um modelo separado e menor verifica se você realmente terminou. O agente que escreveu o código não pode avaliá-lo.
1# Claude Code: executar até estar genuinamente terminado, não até parecer terminado2/goal todos os testes em test/auth passam e a etapa de lint está limpa34# Claude Code: uma tarefa recorrente em nuvem (mínimo de 1 hora)5/schedule triagem diária de PRs às 9h67# Codex: um prompt de automação (defina a cadência no formulário)8"Dias úteis 9h: escanear PRs abertos, sinalizar CI com falha ou sem revisor, postar no Triage."
Escreva a condição de parada como um contrato. "Todos os testes em test/auth passam" é um contrato. "Melhorar" é como um loop roda até o dia do pagamento.
4. Worktrees mantêm agentes paralelos fora do caminho um do outro
No momento em que você executa mais de um agente, o modo de falha muda. Não é mais o modelo. São dois agentes escrevendo o mesmo arquivo, a mesma bagunça de dois engenheiros commitando nas mesmas linhas sem ninguém conversar.
Um git worktree é a parede entre eles: um diretório de trabalho separado em seu próprio branch, compartilhando o histórico do repositório, para que as edições de um agente não alcancem o checkout do outro.
1# Claude Code: um checkout isolado por agente2claude --worktree feature-auth34# ou em um subagente, no frontmatter de .claude/agents/<nome>.md:5# isolation: worktree67# Codex: escolha "Worktree" ao abrir uma thread (cada uma com HEAD destacado)
Uma ressalva que a ferramenta não mencionará. Worktrees removem a colisão, não o gargalo. Você ainda é o teto. Não importa quantos agentes você inicie, sua própria largura de banda de revisão decide quantos você pode confiar.
5. Habilidades são sua intenção, escritas uma vez, do lado de fora
Um agente começa cada execução frio e preenche qualquer lacuna em sua intenção com um palpite confiante. Uma habilidade é essa intenção escrita onde o modelo a lê cada vez, para que ele pare de adivinhar.
O formato é o mesmo em ambas as ferramentas: uma pasta com um SKILL.md contendo instruções e uma descrição, além de quaisquer scripts que ela precise. Ela é acionada quando você a chama pelo nome ou quando sua tarefa corresponde à sua descrição, que é exatamente o motivo pelo qual uma descrição plana e literal é melhor do que uma engenhosa.
1# .claude/skills/triage/SKILL.md (Codex: ~/.agents/skills/triage/SKILL.md)2---3name: triage4description: Ler as falhas de CI de ontem, issues abertas e commits5 recentes; escrever cada descoberta em STATUS.md como uma tarefa.6---71. Pegar falhas de CI e agrupar por causa raiz.82. Corresponder cada uma à issue aberta ou commit que a causou.93. Escrever uma tarefa STATUS.md por descoberta real. Ignorar o ruído.
Sem habilidades, cada ciclo reaprende seu projeto do zero. Com elas, o loop fica um pouco mais afiado a cada manhã.
6. Conectores permitem que o loop aja, não apenas converse
Um loop que só consegue ver o sistema de arquivos é um brinquedo. Conectores, construídos sobre o padrão MCP compartilhado, permitem que o agente leia seu rastreador de issues, acesse uma API de staging, consulte um banco de dados, publique em um canal.
1# Claude Code2claude mcp add --transport http linear https://mcp.linear.app/mcp34# Codex5codex mcp add linear --url https://mcp.linear.app/mcp
Esta é a linha entre um agente que diz "aqui está a correção" e um loop que abre o pull request, vincula o ticket e reporta verde por conta própria. Como ambas as ferramentas falam MCP, um conector que você configura para uma geralmente se encaixa na outra.
7. Subagentes mantêm quem faz longe de quem verifica
O movimento de maior valor em qualquer loop é separar o agente que escreve do agente que verifica.
Um modelo revisando seu próprio trabalho é aprovado por si mesmo todas as vezes. Um segundo agente, com instruções diferentes e idealmente um modelo diferente, pega o que o primeiro se convenceu a fazer.
1# Codex: .codex/agents/reviewer.toml2name = "reviewer"3description = "Revisor de PR adversarial: correção, segurança, testes ausentes."4developer_instructions = "Revise como um proprietário. Assuma que o autor está5 errado até que o diff prove o contrário."6model_reasoning_effort = "high"78# Claude Code: frontmatter de .claude/agents/reviewer.md9# name: reviewer10# description: Revisor adversarial. Use após qualquer alteração de código.11# model: opus
Um explora, um implementa, um verifica contra a especificação. Isso é o que /goal já faz internamente: um modelo novo decide se o trabalho está concluído. Segundas opiniões custam tokens, porque cada agente executa seu próprio modelo e ferramentas, então gaste-os onde estar errado é caro.
8. Como é um loop
Junte as seis partes e uma única thread se torna uma pequena máquina.
Uma automação agendada é executada todas as manhãs no repositório. Ela chama sua habilidade de triagem, que lê as falhas de CI da noite anterior, as issues abertas e os commits recentes, e escreve cada descoberta real em STATUS.md. Para cada descoberta que vale a pena fazer, o loop abre um worktree isolado, envia um subagente para redigir a correção e um segundo para revisá-la de acordo com suas habilidades e testes. Conectores abrem o PR e atualizam o ticket. O que ele não puder lidar espera em sua caixa de entrada de triagem. O STATUS.md lembra o que passou e o que ainda está aberto, para que amanhã comece de onde hoje parou.
O que você realmente encontra ao acordar é uma breve transferência, não uma parede de logs:
1# 9:00 — a transferência noturna do loop (sua caixa de entrada Triage)2PRONTO PARA MESCLAR3 PR #218 corrigir teste instável em test/charts CI verde4 PR #219 repetir webhook no 429, adicionar teste de backoff CI verde5PRECISA DE VOCÊ6 auth/session.ts duas maneiras seguras de corrigir isso; eu não escolhi nenhuma, você decide7SILENCIOSO8 7 execuções agendadas não encontraram nada e se arquivaram
Você projetou uma vez. Você não deu prompt em nada disso.
9. Construa os freios antes de se afastar
Esta é a metade que ninguém ensina, e ela decide se seu loop é um ativo ou um passivo.
Aquela conta de $47.000 não foi um modelo inteligente que ficou maluco. Foram dois agentes, um analisador e um verificador, cada um pedindo educadamente mais trabalho ao outro, sem limite de etapas, sem teto de orçamento e sem condição de parada. Funcionou por onze dias. Um único limite teria matado no primeiro.
Instale os freios antes da potência. Não entregue o motor até ter entregue o pedal do freio.
1# Fixe estes ANTES de se afastar:2- limite de etapas: --max-turns 50 (parada forçada, sem exceções)3- teto de orçamento: claude -p --max-budget-usd 10 (modo de impressão; por fase)4- raio de explosão: um worktree, um branch, somente leitura fora de src/5- disjuntor: mesma ferramenta + mesmos args 3x seguidas = parar6- interruptor de homem-morto: escrever um heartbeat em STATUS.md a cada execução; silêncio te notifica
Escolha o escopo de um loop pelo que ele pode destruir, não pelo que você quer que ele faça: quais repositórios, quais branches, quantos dólares, quantas etapas antes de forçar a saída. Escolha o raio de explosão primeiro, a tarefa depois.
E precifique honestamente. A frota de cem agentes de Steinberger é real e custa cerca de $1,3 milhão por mês. Funciona porque a OpenAI agora o emprega e paga a conta. O caso de ponta é patrocinado. O seu não é. Em um plano de $20 a $200, o loop que compensa é pequeno, limitado e apontado para um trabalho chato, não para um enxame.
1A DISTRIBUIÇÃO DE CUSTOS (tudo real, tudo dos últimos seis meses)2-----------------------------------------------------------------3259 PRs em 30 dias um engenheiro, 100% escritos pelo Claude4$47.000 em 11 dias um loop descontrolado sem limite, ninguém vigiando5~$1,3M por mês uma frota de 100 agentes (a conta é patrocinada)6-----------------------------------------------------------------7Mesma tecnologia. A diferença são os freios.
10. Como os loops morrem
Todo loop que falha morre de uma de quatro maneiras. Aprenda os nomes agora para identificá-los às 3h da manhã.
Recursão descontrolada. Dois agentes se alimentam para sempre. A cura é o limite de etapas e o teto de orçamento acima, nada mais engenhoso.
Morte silenciosa. A execução noturna de um desenvolvedor atingiu uma janela de contexto cheia, parou e então continuou tentando retomar no mesmo obstáculo enquanto ainda parecia ativa. Seu loop pode estar morto por horas e ainda relatar progresso. A cura é um heartbeat e um contexto novo por fase, não uma execução interminável.
A caminhada aleatória. Sem uma condição de parada verificável, o loop se afasta do objetivo em vez de se aproximar. Um conjunto de testes bem-sucedido é um ponto fixo que ele pode alcançar. "Parece concluído" não é.
Dívida de compreensão. Quanto mais rápido um loop entrega código que você não escreveu, maior a lacuna entre o que seu repositório faz e o que você entende. Deixe-o rodar por tempo suficiente sem ser lido e você deixa de ser o engenheiro para se tornar um carimbo. A cura é uma barreira de leitura humana que o loop nunca tem permissão para pular.
11. Construa o loop. Continue sendo o engenheiro.
Duas pessoas podem construir o loop idêntico e obter resultados opostos. Uma o usa para se mover mais rápido em um trabalho que entende profundamente. A outra o usa para parar de entender o trabalho completamente. O loop não consegue distingui-las. Você consegue.
O argumento de Cherny nunca foi que o trabalho ficou mais fácil. É que a alavancagem mudou: do prompt para o loop, e da digitação para o julgamento. Esse é um trabalho mais difícil do que dar prompts, não mais fácil.
Então aqui está o próximo passo, e é pequeno de propósito, porque isso é cedo e os custos variam loucamente. Amanhã de manhã, pegue o trabalho mais chato que você ainda faz manualmente — triar CI, fechar issues obsoletas, perseguir um teste instável — e envolva um loop limitado em torno dele. Freios primeiro. Pequeno o suficiente para que você ainda leia cada diff que ele produzir.
Ninguém que envia 200 pull requests por mês começou com cem agentes. Eles começaram com um loop em que confiavam, e permaneceram engenheiros o caminho todo. Construa esse.
