Engenharia de loops: loops vencem onde a verificação é barata

Boris Cherny, o engenheiro que criou Claude Code, mantém de cinco a 10 sessões abertas com algumas centenas de agentes rodando durante o dia e alguns milhares rodando toda noite.² Quando um trecho em que ele diz “eu não escrevo mais prompts para o Claude… meu trabalho é escrever loops” se espalhou pelo X nesta última semana, a maior parte dos comentários tratou a frase como profecia sobre desenvolvimento de software autônomo, e em poucos dias Addy Osmani já tinha batizado uma disciplina com ela: engenharia de loops.⁷ Fui atrás das transcrições completas das três palestras por trás do trecho. Elas contam uma história mais discreta, e é a versão discreta que vale a pena usar como alicerce: todo loop que Cherny realmente cita tem uma condição de sucesso que uma máquina consegue conferir de graça. É o custo da verificação, e não a construção do loop, que define o que dá para automatizar. Rodo loops em produção desde fevereiro, e meus logs concordam com as transcrições, inclusive em dois incidentes que me ensinaram a lição do jeito difícil.

TL;DR / Pontos principais

• A citação viral vem da entrevista de Cherny ao Acquired Unplugged, onde ele apresenta os loops como o próximo passo de uma linha contínua que vai dos cartões perfurados ao assembly, depois às linguagens de alto nível e aos prompts.¹ E dá prazo curto à transição: “os próximos meses e talvez o resto do ano.”¹
• A mecânica é intencionalmente banal. Na palestra da Sequoia, Cherny descreve o /loop como o Claude usando cron para agendar uma tarefa recorrente.² Os loops que ele cita ficam de babá dos pull requests, mantêm o CI saudável e agrupam feedback do Twitter a cada 30 minutos.²
• Todos esses loops são serviço de zeladoria. Cada um tem um estado final que a máquina consegue conferir: CI verde, PR rebaseado, feedback agrupado. Nenhum dos exemplos citados constrói funcionalidades sem supervisão.
• O trabalho de escrever loops já está se dissolvendo dentro do modelo. Cherny relata que os modelos mais novos iniciam loops por conta própria, e chama a construção de loops pelo usuário de “um problema de design de produto” que significa “eu não estou fazendo um bom trabalho.”⁵
• A habilidade duradoura por baixo do meme: decidir o que é seguro automatizar sem supervisão. Essa decisão é um julgamento sobre verificabilidade, e continua com você depois que a sintaxe dos loops desaparecer.

O que ele disse de fato

O trecho que todo mundo compartilhou saiu de uma entrevista ao vivo do Acquired. Cherny prepara a frase com história de família: o avô programava com cartões perfurados na União Soviética, e o pai escrevia assembly e “teria tirado sarro de mim por escrever Python.” Aí vem a parte que viajou:

“Essa é meio que a natureza da programação: o nível de abstração sempre sobe… O jeito que eu programava um ano atrás era escrevendo código com algum tipo de autocomplete numa IDE. Em novembro, eu desinstalei minha IDE, porque não estava usando… Naquele momento, eu rodava uns cinco, dez Claudes em paralelo, e programar, para mim, era escrever prompts pro Claude escrever código. Agora subiu de nível de novo… e eu não escrevo mais prompts pro Claude. Tenho loops rodando. São eles que escrevem os prompts pro Claude e meio que descobrem o que fazer. Meu trabalho é escrever loops.”¹

A entrevista completa do Acquired Unplugged; o trecho sobre loops começa em 11:14.

Dois detalhes da transcrição completa nunca chegaram aos cortes. Primeiro, o próprio Cherny data a transição: loops são o que “vamos ver nos próximos meses e talvez no resto do ano.”¹ Ele descreve uma fase, não um destino. Segundo, uma nota de procedência para quem quiser rastrear o debate: vários posts virais atribuíram o material sobre loops à participação dele no podcast de uma hora da Y Combinator. Li a transcrição completa daquele episódio. Não há uma única menção a loops; o episódio trata da origem do produto e dos sub-agentes.⁶ A substância está na entrevista do Acquired e numa palestra de 24 minutos na Sequoia.

Um loop é um cron job

A palestra da Sequoia entrega a mecânica, e ela é propositalmente sem graça:

“É só isso: você faz o Claude usar o cron para agendar uma tarefa para algum momento no futuro, e é uma tarefa que se repete. E ela pode rodar a cada minuto, a cada cinco minutos, todo dia.”²

A palestra da Sequoia entrega cada detalhe mecânico que os cortes virais deixaram de fora; a parte sobre loops começa em 7:56.

Cherny mantém dezenas deles rodando. Os que ele cita: um loop de babá dos PRs (consertando o CI, fazendo rebase automático), um loop que mantém o CI saudável (ele conserta testes instáveis) e um loop que puxa feedback do Twitter e o agrupa a cada 30 minutos.² As Routines, anunciadas no evento Code with Claude da Anthropic em maio, levam o mesmo padrão para o servidor, de modo que o loop sobrevive a um laptop fechado.² Simon Willison, cobrindo o keynote ao vivo, registrou o enquadramento que a própria Anthropic usa: Routines são “prompts de ordem superior.”¹² Cherny já vinha dizendo havia meses que /loop e /schedule eram dois dos recursos mais poderosos do produto; o exemplo inicial canônico dele é um loop de cinco minutos que fica de babá dos PRs.¹¹

O padrão tem um ancestral mais tosco. A técnica Ralph Wiggum, de Geoffrey Huntley, é, nas palavras dele, “o Ralph é um loop de Bash”: um while true que alimenta o agente com o mesmo arquivo de prompt para sempre, com o progresso persistindo em arquivos e no histórico do git entre as iterações.⁹ A Anthropic hoje distribui o Ralph como plugin oficial, que intercepta as tentativas de saída do agente e reapresenta o prompt até aparecer uma string de conclusão ou até bater o teto de iterações.⁹ The Register confirmou que o próprio Cherny usa o Ralph, e citou o alerta de Huntley sobre onde a economia disso vai dar: startups vão usar a técnica para clonar negócios SaaS existentes e vender mais barato, porque programação com agentes custa por volta de US$ 10 por hora.¹⁰ A linhagem importa porque mostra a idade real da ideia: o loop é a estrutura de controle mais antiga da computação, e não há nada de novo na estrutura em si.¹⁵

Todo loop que ele cita é zeladoria

Aqui está a observação que o debate pulou. Liste os loops de Cherny de novo e olhe os estados finais:

Cada um deles ou tem condição de sucesso conferível por máquina, ou produz uma saída em que errar não custa nada. Nenhum dos exemplos citados é “construa a funcionalidade enquanto eu durmo.” O sujeito que roda alguns milhares de agentes toda noite descreve a própria automação pessoal como conserto de CI, rebase e triagem de feedback.

O suposto contraexemplo confirma a regra. O time de engenharia da própria Anthropic rodou 16 agentes em loops infinitos por duas semanas e produziu um compilador C de 100.000 linhas em Rust, ao custo de uns US$ 20.000 em computação.⁸ Um compilador é o artefato mais verificável que existe em software: uma suíte gigante de programas ou compila e roda corretamente, ou não. O time escolheu um alvo em que a verificação é quase gratuita e, mesmo assim, Nicholas Carlini, que conduziu o experimento, escreveu que programadores implantarem software que nunca verificaram pessoalmente é “uma preocupação real.”⁸

O ensaio de Addy Osmani que batiza a disciplina de “engenharia de loops” chega à mesma restrição pelo lado do design: “Um loop rodando sem supervisão é também um loop errando sem supervisão.”⁷ A arquitetura que ele propõe (agentes verificadores separados, para que quem produz nunca corrija o próprio trabalho) é uma tentativa de fabricar verificação barata onde ela não aparece naturalmente.⁷

O que meus próprios loops me ensinaram

Escrevi sobre meu sistema de agentes noturnos em fevereiro, quando o nome educado da técnica ainda era uma referência aos Simpsons.¹⁶ De lá para cá, todos os loops que sobreviveram no meu setup convergiram para o mesmo formato, e os que falharam me ensinaram mais do que os que funcionaram.

Os sobreviventes têm formato de verificação. Um loop noturno lê os commits do dia, mapeia os arquivos alterados para URLs em produção, carrega cada página afetada e reporta passou ou falhou, com os tempos de carregamento. Um loop de segurança fica de olho nos endpoints durante a madrugada e escreve um resumo matinal. Um loop de crawl lê a atividade do Googlebot e do Bingbot nas minhas propriedades e reporta desvios de indexação. Nenhum deles cria nada. Cada um observa, compara com um estado esperado e reporta. Quando um deles falha, o custo é um relatório desatualizado, não um produto quebrado. A leitura matinal leva minutos porque a saída é binária por item: passou, falhou, olhe aqui.

As falhas foram loops que agiram. Um recurso de isolamento que criava worktrees do git automaticamente para agentes paralelos apagou, duas vezes, diretórios de rascunho que ele julgou descartáveis; o raio de impacto da automação incluía arquivos que ela não criou e não entendia. Uma limpeza de cache agendada rodou uma vez na ordem errada em relação a um deploy, e os crawlers de busca passaram 11 horas recebendo 404 em páginas que existiam, porque a limpeza removeu do cache respostas corretas antes de a origem servir as substitutas.¹⁶ Nenhuma das duas falhas veio de um modelo ruim. As duas vieram de eu ter dado acesso de escrita a um loop cujas precondições eu não tinha fixado. Cada um deles hoje tem uma trava: a automação de worktree está bloqueada de vez, e as limpezas de cache só rodam depois que a verificação do deploy passa. A regra geral que extraí: um loop que só lê precisa de um agendamento; um loop que escreve precisa de uma prova de ordenação e de um limite de raio de impacto antes de merecer o agendamento.

Essa regra também explica a parte do setup de Cherny que as pessoas acham mais difícil de acreditar. “Hoje, na verdade, faço a maior parte do meu trabalho pelo celular”, diz ele, rodando sessões pela aba de código do app do Claude.² O celular é um lugar terrível para revisar código e um ótimo lugar para ler um relatório de passou/falhou. A afirmação sobre o celular é, na verdade, uma afirmação sobre verificação disfarçada: os loops dele emitem uma saída legível o bastante para ser aceita ou rejeitada num relance, o que só é possível quando as condições de sucesso foram desenhadas antes de o loop começar a rodar.

A escada do custo de verificação

Se a tese se sustenta, escolher o que automatizar se reduz a uma pergunta: quem verifica o resultado, e quanto custa essa verificação? Esta é a escada que uso antes de qualquer tarefa ganhar um agendamento.

A coluna que decide é a segunda, e a dificuldade da tarefa nunca aparece nela. Uma tarefa difícil com verificador gratuito (o teste instável) é automatizada antes de uma tarefa fácil com verificador caro (uma mudança de texto de uma linha que precisa de aprovação humana). Os loops de Cherny, o compilador da Anthropic e os meus sobreviventes ficam todos na metade de cima da escada; o comentário viral presumiu a metade de baixo.

O formato que sobrevive à escada se parece com um único padrão de supervisão, independentemente da escala:

A anatomia de um loop que merece seu agendamento. O verificador aparece com traço mais forte porque é a caixa que sustenta a estrutura: tire-o e o loop continua rodando, só que ninguém sabe o que ele fez.

O menor loop que vale a pena rodar é somente leitura, se autoverifica e é de leitura rápida, o que o torna seguro de escrever hoje e chato de acompanhar amanhã:

# Nightly site check: observes and reports, never edits.
# Run it under a permission mode that blocks writes outside reports/.
while true; do
  claude -p "Read today's commits. For each changed file that maps to a live
    page, fetch the staging URL and confirm it returns 200 and renders its
    headline. Append PASS or FAIL per page, with the reason, to
    reports/site-check-$(date +%F).md. Write nothing outside reports/."
  sleep 86400
done

Dentro do Claude Code, esse mesmo loop cabe em uma linha: /loop 24h seguido da instrução. A promoção vem depois. Quando o relatório tiver ficado chato por um mês, o loop terá conquistado o direito de ser considerado para o próximo degrau da escada, e não antes.

O trabalho que sobra

A passagem mais estranha da palestra da Sequoia derruba o meme que ela gerou. Cherny conta que os modelos mais novos começaram a iniciar loops sem que ninguém pedisse: ele solicita uma consulta de dados, e o modelo percebe que os dados mudam com o tempo, propõe um relatório recorrente a cada 30 minutos e conecta o relatório ao Slack por conta própria.⁵ A conclusão dele: “Não é papel do usuário descobrir como segurar melhor a ferramenta… na verdade é um problema de design de produto e eu não estou fazendo um bom trabalho.”⁵ O argumento de regressão infinita que os céticos levantaram no X (se hoje humanos escrevem os loops, amanhã os modelos escrevem os loops) acaba sendo o roadmap da Anthropic, admitido pela pessoa sobre quem o meme fala.

Ele vai além: “Conforme o modelo foi ficando melhor, a estrutura local meio que vai ficando menos importante”, prevendo que modos de permissão, defesas contra injeção de prompt e checkpoints com humano no circuito vão desaparecendo à medida que o alinhamento melhora.³ Fico do outro lado em metade dessa aposta. O andaime de segurança pode encolher. Já o andaime de orquestração está virando o trabalho inteiro, pelo relato do próprio Cherny: os agentes dos engenheiros da Anthropic se coordenam entre si pelo Slack enquanto seus donos trabalham, e “não temos mais nenhum código escrito à mão em lugar nenhum da empresa. Todo o SQL é escrito por modelos.”⁴ Alguém decide no que esses agentes podem mexer, o que conta como pronto e o que acontece quando dois deles discordam. Essa camada de decisão é a verdadeira interface do agente, e o cron é a parte fácil dela.

Então a habilidade duradoura não é a sintaxe dos loops, que o modelo já está absorvendo, nem escrever prompts, que os loops absorveram primeiro. A habilidade duradoura é o julgamento que sustenta as duas: decidir o que é seguro automatizar sem supervisão. Esse julgamento é sempre uma pergunta sobre custo de verificação. O conserto de CI foi automatizado primeiro porque a suíte de testes já era o verificador. O agrupamento de feedback foi automatizado porque errar sai de graça. O desenvolvimento de funcionalidades resiste porque a verificação ainda custa uma pessoa lendo o diff, e um engenheiro sênior no Hacker News colocou a armadilha resultante sem rodeios: a ferramenta exige julgamento apurado para ser conduzida, e usar a ferramenta corrói exatamente esse julgamento.¹⁴

A entrevista de Casey Newton com Cherny na Platformer saiu com o título “O criador do Claude Code sobre o fim do engenheiro de software”. Nela, Cherny prevê que o cargo de “engenheiro de software” se dissolve em algo como “construtor” até o fim do ano, enquanto o número de pessoas escrevendo código por meio de agentes cresce cem vezes.¹³ Construtores, nessa previsão, são as pessoas que escolhem os loops. Escolher bem significa saber, antes de qualquer coisa rodar, como você vai saber que deu certo.

Pontos principais

Para quem programa com agentes: - Avalie as automações candidatas pelo custo de verificação, não pela empolgação. Conserto de CI, rebase, monitoramento e geração de relatórios já têm verificadores gratuitos hoje; automatize esses primeiro. - Aplique a separação leitura/escrita: um loop somente leitura precisa de um agendamento, enquanto um loop com acesso de escrita precisa de uma restrição explícita de ordenação e de um limite de raio de impacto antes de rodar sem supervisão. - Desenhe o relatório antes do loop. Se você não consegue rejeitar a saída do loop pelo celular em 10 segundos, ele não está pronto para rodar de madrugada.

Para quem lidera times: - O teto do paralelismo útil é a sua capacidade de revisão, não a quantidade de agentes. Adicionar agentes acima desse teto produz merges não revisados, não throughput. - Separe quem faz de quem confere. Um agente que verifica o próprio trabalho apenas afirma que acertou; um verificador separado, com outro ponto de vista, ao menos tem chance de flagrar a alegação.

Para quem constrói ferramentas: - Cherny classifica a construção de loops pelo usuário como falha de design de produto, e os modelos já iniciam loops sozinhos.⁵ Construir UX de autoria de loops é construir para uma camada que o fornecedor do modelo pretende absorver. A superfície mais duradoura é a verificação: evidência, rastreamento e a ergonomia de aceitar ou rejeitar.

Perguntas frequentes

Referências