Em dezembro passado, Boris Cherny enviou 259 pull requests em um único mês. Todos escritos por Claude. Ele diz que não abriu um editor durante todo esse tempo.
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 comandos para agentes de codificação. Você deveria projetar loops que comandam seus agentes."
Isso é engenharia de loops. Você constrói um pequeno sistema que encontra o trabalho, entrega a um agente, verifica o resultado e decide o próximo passo. Depois, deixa ele rodar enquanto você 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 notasse. Então, isso são na verdade duas habilidades, e quase todo mundo ensina apenas a primeira: construir um loop que entrega trabalho, e construir os freios que impedem que ele te leve ao desastre.
Uma pergunta decide que tipo de loop você construiu: ele converge para algo verdadeiro, ou é apenas um passeio aleatório caro?
1. Um loop tem seis peças 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 se mantém sólido ou vaza dinheiro durante a noite.
Você não constrói mais nada disso manualmente. Há um ano, um loop significava uma pilha de scripts shell que você possuía e cuidava para sempre. Agora, as peças vêm embutidas nos produtos, e as mesmas seis se aplicam tanto ao app OpenAI Codex quanto ao Claude Code. Depois que você percebe isso, a ferramenta deixa de ser o centro da discussão 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 cronograma Aba Automações + Triage /loop (skill), Routines, /goal5Worktrees isolar agentes paralelos Worktree por thread --worktree, isolation: worktree6Skills codificar sua intenção ~/.agents/skills/SKILL.md ~/.claude/skills/SKILL.md7Conectores tocar suas ferramentas Servidores MCP (config.toml) Servidores MCP (.mcp.json)8Subagentes separar criador de revisor 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 disso.
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 único arquivo. Um STATUS.md no repositório, ou um quadro do Linear acessado por um conector, contendo o que foi 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 vermelha)6## Próximo7- [ ] dashboard: teste instável em test/charts8## Nunca9- não modificar infra/ sem um humano
Trate o loop como um turno da noite que você nunca observa. Você não é julgado pelo que ele fez às 3 da manhã. Você é julgado pela nota esperando na sua mesa às nove. Projete essa nota primeiro e a maior parte do loop se projeta sozinha.
3. Automações são a diferença entre um loop e uma coisa que você executou uma vez
Um loop só merece o nome quando é acionado por conta própria.
No app Codex, você constrói um na aba Automações: o repositório, o prompt, a cadência. Execuções que encontram algo vão parar em uma caixa de entrada de Triagem; execuções que não encontram nada se arquivam sozinhas. A OpenAI usa isso para a espinha dorsal não glamorosa de uma base de código: triagem diária de issues, resumos de falhas de CI, capturar 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 skill, não um comando embutido, e reexecuta um prompt em uma cadência enquanto sua sessão estiver aberta. Trabalhos recorrentes na nuvem são Routines, definidos com /schedule, com um mínimo de uma hora, e continuam rodando mesmo com seu laptop fechado. Não existe crontab local.
O que vale a pena aprender é /goal. Ele executa 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 avaliar a si mesmo.
1# Claude Code: executar até estar genuinamente finalizado, não até parecer finalizado2/goal todos os testes em test/auth passam e a etapa de lint está limpa34# Claude Code: um trabalho recorrente na 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 às 9h: escanear PRs abertos, sinalizar CI com falha ou sem revisor, postar na Triagem."
Escreva a condição de parada como um contrato. "Todos os testes em test/auth passam" é um contrato. "Melhorar isso" é 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 no mesmo arquivo, a mesma bagunça de dois engenheiros fazendo commit 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 um 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 em quantos você pode confiar.
5. Skills são sua intenção, escrita uma vez, do lado de fora
Um agente começa cada execução frio e preenche qualquer lacuna na sua intenção com um palpite confiante. Uma skill é 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 arquivo SKILL.md contendo instruções e uma descrição, além de quaisquer scripts necessários. Ela é acionada quando você a chama pelo nome ou quando sua tarefa corresponde à sua descrição, e é exatamente por isso que 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 no STATUS.md como uma tarefa.6---71. Buscar falhas de CI e agrupar por causa raiz.82. Corresponder cada uma à issue aberta ou commit que a causou.93. Escrever uma tarefa no STATUS.md por descoberta real. Ignorar o ruído.
Sem skills, 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 relata sucesso 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 o criador longe do revisor
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 toda vez. 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. Suponha 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. Usar após qualquer alteração de código.11# model: opus
Um explora, um implementa, um verifica contra a especificação. É isso 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 peças 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 skill de triagem, que lê as falhas de CI da noite anterior, as issues abertas e os commits recentes, e escreve cada descoberta real no STATUS.md. Para cada descoberta que vale a pena fazer, o loop abre um worktree isolado, envia um subagente para rascunhar a correção e um segundo para revisá-la de acordo com suas skills e seus testes. Conectores abrem o PR e atualizam o ticket. Tudo o que ele não consegue 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 é um resumo curto, não uma parede de logs:
1# 9:00 — o resumo noturno do loop (sua caixa de entrada de Triagem)2PRONTO PARA MERGE3 PR #218 corrige 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; não escolhi nenhuma, você decide7SILENCIOSO8 7 execuções agendadas não encontraram nada e se arquivaram
Você projetou uma vez. Não deu nenhum comando a nenhum deles.
9. Construa os freios antes de se afastar
Esta é a metade que ninguém ensina, e é ela que decide se seu loop é um ativo ou um passivo.
Aquela conta de $47.000 não foi um modelo inteligente que se tornou rebelde. 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 interrompido no primeiro.
Instale os freios antes da potência. Não entregue o motor até ter entregue o pedal do freio.
1# Instale 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 argumentos 3x seguidas = parar6- verificação de pulso: escrever um heartbeat no 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 DISPERSÃO DE CUSTOS (todos reais, todos dos últimos seis meses)2-----------------------------------------------------------------3259 PRs em 30 dias um engenheiro, 100% escrito por 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 das quatro maneiras. Aprenda os nomes agora para identificá-los às 3 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 inteligente.
Morte silenciosa. A execução noturna de um desenvolvedor atingiu uma janela de contexto cheia, parou e depois continuou tentando retomar no mesmo obstáculo enquanto ainda parecia ativa. Seu loop pode estar morto por horas e ainda assim relatar progresso. A cura é um heartbeat e um contexto novo por fase, não uma execução interminável.
O passeio aleatório. Sem uma condição de parada verificável, o loop se afasta do objetivo em vez de se aproximar. Um conjunto de testes que passa é 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 tempo suficiente sem ser lido e você deixa de ser o engenheiro para se tornar um carimbo. A cura é uma barreira de revisão humana que o loop nunca pode pular.
11. Construa o loop. Continue sendo o engenheiro.
Duas pessoas podem construir o mesmo 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 ponto 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 comandos, não mais fácil.
Então, aqui está o movimento, e é propositalmente pequeno, porque isso é recente e os custos variam muito. Amanhã de manhã, pegue o trabalho mais chato que você ainda faz manualmente — triar CI, fechar issues antigas, perseguir um teste instável — e envolva um loop limitado nele. Freios primeiro. Pequeno o suficiente para que você ainda leia cada diff que ele entregar.
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 continuaram sendo engenheiros durante todo o caminho. Construa esse loop.
