Engenheiro do Google ensina o que é Engenharia de Loop? Cinco blocos + memória externa, a disciplina obrigatória de IA para 2026

Loop Engineering é um sistema que executa automaticamente a proxy de prompt, composto por cinco blocos: Automations, Worktrees, Skills, Plugins/Connectors, Sub-agents, além de uma memória externa. Este artigo é originado do engenheiro de software do Google, Addy Osmani.
(Preâmbulo: Anthropic adicionou detecção de destilação ao Claude Fable 5, pode bloquear modelos open source chineses?)
(Complemento de contexto: Anthropic: liderando modelos de IA nos EUA para proteger a democracia, propondo que ataques de destilação sejam crimes)

Índice deste artigo

Alternar

• Os cinco blocos, com algumas notas
• Automations: o batimento do coração do ciclo
• Worktrees: evitar que paralelos se tornem caos
• Skills: finalmente não precisar repetir seu projeto toda vez
• Plugins e connectors: o ciclo estende a mão para suas ferramentas reais
• Sub-agents: separar quem faz de quem verifica
• Como é um ciclo
• O que o ciclo ainda não faz por você
• Montar o ciclo, mas continuar sendo engenheiro

Loop engineering é trocar o "prompt manual do proxy" por um sistema que você projeta para fazer isso. O que chamamos de "ciclo" aqui pode ser entendido como um objetivo recursivo: você define um propósito, a IA itera repetidamente até completar. Acredito que essa pode ser a nossa futura forma de colaborar com agentes de codificação.

Mas, antes de tudo, ainda é muito cedo, eu mesmo tenho dúvidas, e você precisa estar atento ao custo de tokens. Quero dividir essa discussão: o que é isso, e o que isso significa.

Peter Steinberger recentemente disse: "Você não deve mais promptar seu agente de codificação. Você deve projetar o ciclo que prompta seu agente." Boris Cherny, responsável pelo Claude Code na Anthropic, também falou algo semelhante: "Eu não prompto mais Claude. Deixo o ciclo rodar, promptando o Claude, com o ciclo decidindo o que fazer."

Quase dois anos atrás, para obter resultados de um agente de codificação, você escrevia um bom prompt e fornecia contexto suficiente. Você digitava uma parte, recebia a resposta, digitava a próxima. O agente era uma ferramenta, e você a controlava do começo ao fim, rodada após rodada. Essa fase está quase encerrada, ou pelo menos alguns pensam assim.

Agora, você constrói um pequeno sistema: ele busca tarefas, as distribui, verifica o progresso, registra o que foi concluído e decide a próxima ação, tudo isso acionando o agente, não você. Eu já escrevi sobre seu parente próximo, "agent harness engineering", que cria um ambiente de execução para um único agente, ou seja, uma "fábrica de software".

Loop engineering é uma camada acima do harness: o harness ainda existe, mas agora ele segue o ritmo, gera assistentes, se alimenta sozinho.

Para minha surpresa, isso já não é mais uma questão de ferramenta. Há um ano, para criar um ciclo, você precisava montar uma pilha de bash, manter tudo, era uma coisa pessoal. Agora, esses componentes estão embutidos no produto. A lista de Steinberger quase que completamente corresponde ao Codex app, e também ao Claude Code. Quando você percebe que a forma é realmente a mesma, não discute mais qual ferramenta usar; você apenas projeta um ciclo que pode rodar em qualquer ferramenta.

Os cinco blocos, com algumas notas

Um ciclo precisa de cinco elementos, mais uma memória. Vou listar e fazer a correspondência.

2. Automations: acionamento por agendamento, descoberta e triagem automáticas.
3. Worktrees: evitar que agentes paralelos se prejudiquem.
4. Skills: codificar o conhecimento do projeto que antes só se podia adivinhar.
5. Plugins e connectors: conectar seu agente às ferramentas que você já usa.
6. Sub-agents: um que gera ideias, outro que verifica.

E o sexto elemento: memória. Um arquivo markdown, ou um quadro Linear, qualquer coisa que exista fora da conversa única, usada para registrar "o que foi feito, qual é o próximo passo". Parece bobo, ninguém usaria. Mas é o truque do qual todo agente de longa duração depende, como já discuti no artigo sobre agentes de longa duração: o modelo esquece tudo entre execuções, então a memória deve estar no disco, não no contexto. O agente esquece, o repositório não.

Hoje, esses cinco elementos estão presentes em dois produtos.

| Termo original | | --- | Na função do ciclo | Codex app | Claude Code | | --- | --- | --- | --- | | Automations | Descoberta e triagem agendadas | Aba de Automations: escolher projeto, prompt, frequência, ambiente; resultados vão para triagem; /goal para rodar até terminar | Tarefas agendadas, cron, /loop, /goal, hooks, GitHub Actions | | Worktrees | Isolamento de desenvolvimento paralelo | Cada thread tem seu worktree embutido | git worktree, --worktree, isolamento no subagent: worktree | | Skills | Codificar conhecimento do projeto | Agent Skills (SKILL.md), chamado por $nome ou implicitamente | Agent Skills (SKILL.md) | | Plugins / connectors | Conectar às suas ferramentas | Connectors (MCP) + plugins de distribuição | Servidores MCP com plugins | | Sub-agents | Ideias e validações | Definidos em .codex/agents/ usando TOML | Em .claude/agents/ com Task subagents, equipes de agentes | | State | Rastreamento do progresso | Markdown ou via connector para Linear | Markdown (AGENTS.md, progresso) ou via MCP para Linear |

Os nomes variam um pouco, mas a capacidade essencial é a mesma. Vou detalhar cada um, porque, honestamente, o diabo está nos detalhes: se o ciclo vai se manter estável ou vazará, tudo depende desses detalhes.

Automations: o batimento do coração do ciclo

Automations é o que faz o "ciclo" realmente virar um ciclo, e não só "você rodando uma vez". No Codex app, você cria uma automação na aba de Automations, escolhe projeto, prompt, frequência, se roda local ou em background com worktree. Descobertas vão para a triagem, as que não são descobertas são arquivadas, é bem conveniente.

Dentro do OpenAI, eles usam isso para tarefas rotineiras: distribuir issues diários, resumir falhas de CI, briefing de commits, identificar quem colocou bugs na semana passada. Automations pode chamar skills, então suas tarefas periódicas podem ser mantidas: você só dispara $skill-nome, ao invés de colocar uma grande quantidade de comandos em uma tarefa agendada que ninguém vai atualizar.

Claude Code chega ao mesmo ponto, mas de outro caminho, usando agendamento e hooks. Você pode usar /loop para fazer prompts ou comandos repetirem em intervalos, agendar cron, usar hooks em pontos específicos do ciclo de vida do agente para rodar comandos shell, ou até enviar tudo para GitHub Actions para continuar após fechar o laptop. O conceito é o mesmo: definir uma tarefa automática, dar ritmo, e as descobertas aparecem na sua frente, sem precisar abrir o código.

Outro comando importante na sessão é o /loop, que roda em ritmo definido. /goal roda até que uma condição escrita seja satisfeita, com uma verificação feita por um modelo menor ao final de cada rodada, para decidir se terminou. Assim, "escrever código" não é "pontuar" o código, mas sim uma condição de parada.

Se você dá uma condição como "todos os testes em auth/pass passam, lint está limpo", ele para. Codex também tem /goal, que roda várias rodadas até uma condição de parada verificável, podendo pausar, retomar, limpar. O mesmo comando, duas ferramentas, mesma pattern.

Então, essa parte é "mostrar o trabalho". O restante do ciclo é "fazer algo com esses trabalhos".

Worktrees: evitar que paralelos se tornem caos

Se você roda mais de um agente ao mesmo tempo, os arquivos começam a conflitar, e aí a falha acontece. Dois agentes escrevendo no mesmo arquivo, como dois engenheiros fazendo commit na mesma linha de código sem comunicação prévia. git worktree resolve isso: é um diretório de trabalho separado, com sua própria branch, compartilhando o histórico do repositório, assim um agente não consegue fisicamente sobrescrever o trabalho do outro.

Codex tem suporte embutido a worktree, então vários threads podem trabalhar no mesmo repositório sem conflito. Claude Code usa git worktree, a flag --worktree (para abrir uma sessão em seu próprio checkout), e a configuração isolation: worktree no subagent (cada assistente tem seu checkout limpo, que é criado e descartado ao terminar). No artigo sobre orquestração, escrevi do ponto de vista humano: worktree resolve colisões mecânicas, mas o limite real é sua capacidade de revisão, que define quantos agentes você consegue rodar simultaneamente.

Skills: você finalmente não precisa repetir seu projeto toda hora

Skills é o que te permite não precisar recontar o projeto toda sessão. Ambas as ferramentas usam o mesmo formato: uma pasta com SKILL.md, contendo comandos e metadados, além de scripts, referências, assets opcionais. No Codex, você chama skills com $ ou /skills, ou elas ativam automaticamente quando o objetivo bate com a descrição. Por isso, uma descrição precisa e direta vence uma mais bonita ou inteligente. Claude Code faz o mesmo, como descrevi na artigo sobre agent skills.

Skills também representam "intenção sem precisar pagar por ela". Já discuti isso na "dívida de intenção": agentes sempre começam do zero, e tentam preencher as lacunas com hipóteses confiantes. Skills externalizam essa intenção — regras, passos de build, referências a eventos passados —, que ficam acessíveis a cada execução. Sem skills, cada rodada recomeça do zero; com skills, a acumulação é como juros compostos.

Importante distinguir: skill é o formato de escrita, plugin é a forma de distribuição. Quando você compartilha skills entre repositórios ou agrupa várias skills, empacota como plugin. Codex faz assim, Claude Code também.

Plugins e connectors: o ciclo estende a mão às suas ferramentas reais

Um ciclo que só acessa o sistema de arquivos é limitado. Connectors, construídos sobre MCP, permitem que o agente acesse issues, bancos de dados, APIs staging, envie mensagens no Slack. Codex e Claude Code usam MCP, então um connector criado para um pode ser usado pelo outro. Plugins agrupam connectors e skills, facilitando a instalação por seus colegas, sem precisar lembrar de tudo.

Essa é a diferença entre "o agente te diz 'isso é uma mudança' " e "o ciclo faz um PR, conecta ao ticket Linear, envia para CI e avisa no canal". Connectors são o que permite ao ciclo agir no ambiente real, não só informar o que poderia fazer.

Sub-agents: separar quem faz de quem verifica

A estrutura mais útil no ciclo é separar quem escreve de quem verifica. O modelo de escrita tende a ser muito indulgente consigo mesmo. Um segundo agente, com comandos diferentes ou até um modelo diferente, consegue pegar o que o primeiro se convenceu de fazer.

Codex só gera subagents quando você pede, executa em paralelo, e combina os resultados. Você define seus agentes em .codex/agents/ usando TOML, cada um com nome, descrição, instruções, modelo e esforço de raciocínio — seu auditor de segurança pode usar um modelo forte com alto orçamento de raciocínio, seu explorador pode ser algo rápido e somente leitura. Claude Code também usa subagents e equipes de agentes em .claude/agents/: uma exploração, uma implementação, uma verificação contra o spec.

Já defendi duas vezes: uma chamada code agent orchestra, outra adversarial code review. No ciclo, essa separação é especialmente importante porque ele roda quando você não está olhando — um verificador confiável é a única garantia de que pode seguir em frente. Subagents consomem tokens, pois cada um roda seu próprio modelo e ferramentas. Então, invista onde vale a pena: em "obter uma segunda opinião". O /goal do Claude Code funciona assim: um modelo novo decide se o ciclo terminou, não o modelo que escreveu o código — "quem faz vs quem verifica" na condição de parada.

Como é um ciclo

Juntando tudo, um único thread vira uma espécie de painel de controle. Meu formato favorito é assim:

Um automation roda todo dia de manhã no repositório. Ele chama um skill de triagem, que lê falhas de CI, issues abertas, commits recentes, e registra tudo em um markdown ou quadro Linear. Para cada descoberta relevante, esse thread cria um worktree isolado, despacha um subagent para redigir uma solução, e outro subagent para revisar a proposta com base nas skills do projeto e testes existentes.

Connectors fazem PRs, atualizam tickets. Tudo que o ciclo não consegue fazer fica na triagem. O arquivo de estado é a espinha dorsal, registrando o que foi tentado, o que passou, o que ainda está aberto — assim, a próxima manhã pode retomar de onde parou.

Ao revisar, você só projetou uma vez. Nenhuma etapa é promptada por você. Essa é a implementação concreta da frase de Steinberger. E o mesmo ciclo funciona no Codex e no Claude Code, porque os componentes são os mesmos.

O que o ciclo ainda não faz por você

O ciclo muda a forma do trabalho, mas não te substitui. E há três problemas que, ao melhorar, ficam mais evidentes, não menos.

Verificação ainda é sua responsabilidade. Um ciclo que roda sem supervisão é um ciclo sem erros controlados. Separar o verificador do criador faz a "conclusão" do ciclo ter sentido; mesmo assim, "concluir" é uma afirmação, não uma prova. Como já disse na "review de código na era da IA": seu trabalho é lançar código que você confirmou pessoalmente que funciona.

Sua compreensão ainda pode se deteriorar, se você permitir. Quanto mais rápido o ciclo entrega "não é seu código", maior a lacuna entre "o que existe" e "o que você realmente tem". Isso é a dívida de compreensão, e um ciclo fluido só acelera isso — a menos que você leia o que o ciclo faz.

Postura confortável é postura perigosa. Quando o ciclo roda sozinho, você tende a querer parar de ter opiniões, aceitar o que ele devolve. Chamo isso de "rendição cognitiva". Projetar o ciclo é uma cura quando você tem julgamento, mas um acelerador quando quer evitar pensar — a mesma ação, resultados opostos.

Montar o ciclo, mas continuar sendo engenheiro

Acredito que essa seja uma previsão do futuro do nosso trabalho. Mas, se eu não revisar o código pessoalmente, ou confiar totalmente no ciclo automático, a qualidade do produto cai. Eu provavelmente ficarei preso numa espiral descendente, cavando cada vez mais fundo.

Ou seja, construa seu ciclo — mas não esqueça que promptar seu agente diretamente também funciona. Tudo é uma questão de equilíbrio.

O ciclo também varia muito dependendo de quem o opera. Duas pessoas usando o mesmo ciclo podem obter resultados completamente opostos. Uma usa para acelerar trabalhos que conhece bem, outra para evitar entender qualquer coisa. Se o ciclo não diferencia esses usos, você não entende seu poder.

Por isso, o design do ciclo é mais difícil do que o prompt engineering. Cherny não quer dizer que o trabalho ficou mais fácil, mas que o ponto de alavanca mudou.

Construa seu ciclo, mas como alguém que pretende continuar sendo engenheiro, não como alguém que só quer apertar o botão de start.