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 texto é originado do engenheiro de software da Google, Addy Osmani.
(Preâmbulo: Anthropic adicionou detecção de destilação ao Claude Fable 5, consegue 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 confusos
• Skills: finalmente não precisar repetir seu projeto toda vez
• Plugins e connectors: o braço do ciclo que alcança 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 proxy feito à mão" por um sistema que você projeta para fazer isso. Aqui, o "ciclo" pode ser entendido como um objetivo recursivo: você define um propósito, a IA itera 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ê deve estar atento ao custo de tokens. Quero dividir essa discussão: o que é, e o que 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, o ciclo decide o que fazer."

Quase dois anos atrás, conseguir resultados de um agente de codificação dependia de você escrever um bom prompt e fornecer contexto suficiente. Você escreve uma parte, lê a resposta, escreve a próxima. O agente é uma ferramenta, e você a controla do começo ao fim, rodada após rodada. Essa fase acabou, ao menos na visão de alguns.

Agora, você constrói um pequeno sistema: ele busca tarefas, as distribui, verifica, registra o que foi feito, e decide a próxima ação, tudo por esse sistema, não por você manualmente. Antes, eu escrevi algo semelhante com "agent harness engineering", que era criar um ambiente de execução de um único agente, uma espécie de "fábrica de software".

Loop engineering é um nível acima do harness: o harness ainda existe, mas agora ele roda automaticamente, 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 um monte de scripts bash, manter tudo, era uma coisa pessoal. Agora, esses componentes já vêm embutidos no produto. A lista de Steinberger quase que totalmente 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 funcione 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: acionamentos agendados, automação de discovery e triagem.
3. Worktrees: evitar que agentes paralelos se prejudiquem.
4. Skills: codificar o conhecimento do projeto que antes só se adivinhava.
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, 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 que todo agente de longa duração depende — como falei na peça 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 já estão em dois produtos.

| Termo original | | --- | Na função do ciclo | Codex app | Claude Code | | --- | --- | --- | --- | | Automations | Disparo agendado de discovery e triagem | 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/ com TOML | Subagentes em .claude/agents/ com tarefas, equipes | | State | Rastrear o progresso | Markdown ou via connector Linear | Markdown (AGENTS.md, progresso) ou via MCP para Linear |

Os nomes variam, 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 ser ciclo, e não só "você rodou 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 triagem, as que não descobrem nada são arquivadas — bem prático.

Na OpenAI, eles usam para tarefas rotineiras: distribuir issues diárias, resumir falhas de CI, briefing de commits, identificar bugs de 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 tonelada de comandos numa agenda que ninguém atualiza.

Claude Code faz algo semelhante, mas via 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, ou até subir tudo no GitHub Actions para rodar após fechar o laptop. O conceito é o mesmo: definir uma tarefa automática, dar ritmo, descobrir e entregar automaticamente, sem precisar ficar de olho.

Outro conceito importante: /loop é para rodar com ritmo. /goal é até que uma condição escrita seja verdadeira, com uma verificação feita por um modelo menor, que decide se terminou — ou seja, "o que faz o código" não é "quem avalia".

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

Resumindo: é "mostrar o trabalho". O restante do ciclo é "fazer algo com esses trabalhos".

Worktrees: evitar que paralelos se tornem confusos

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

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 de isolamento no subagent: cada assistente tem seu checkout limpo, que é criado e descartado ao terminar. Na peça sobre orquestração, escrevi que worktree resolve o conflito mecânico, mas o limite real é sua capacidade de revisão — o quanto você consegue acompanhar, não a ferramenta.

Skills: finalmente não precisar repetir seu projeto toda hora

Skills é o que impede você de ter que recontar o projeto toda sessão. Ambos os sistemas 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 e inteligente. Claude Code faz igual, como expliquei na peça sobre agent skills.

Skills também representam "não pagar duas vezes" pela mesma intenção. Na peça sobre dívida de intenção, argumentei que agentes, toda sessão, começam do zero, e tentam preencher as lacunas com hipóteses confiantes. Skills deixam essa intenção externa, em convenções, passos de build, "não fazemos assim por causa do evento anterior" — escreve uma vez, e toda execução futura lê. Sem skills, cada rodada recomeça do zero; com skills, a acumulação é de juros compostos.

Importante: skill é formato de escrita, plugin é modo de distribuição. Para compartilhar skills entre repositórios ou agrupá-las, você empacota como plugin. Codex faz assim, Claude Code também.

Plugins e connectors: o braço do ciclo que alcança suas ferramentas reais

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

Essa é a diferença entre "o agente te diz 'isso é uma mudança na lei'" e "o ciclo faz um PR, conecta ao ticket Linear, após CI verde, manda uma mensagem no canal". Connectors fazem o 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 do quem verifica. O modelo que escreve tende a ser muito gentil consigo mesmo. Um segundo agente, diferente, pode pegar o que o primeiro produziu e questionar, validar, desafiar.

Codex só gera subagentes quando você pede, executa em paralelo, e traz o resultado de volta. Você define seus agentes em .codex/agents/ com TOML, cada um com nome, descrição, instruções, modelo, esforço de raciocínio — seu verificador pode usar um modelo forte, seu explorador pode ser rápido e de leitura única. Claude Code faz o mesmo com subagentes e equipes em .claude/agents/: trocam tarefas entre si, cada um com uma função específica: exploração, implementação, validação.

Já defendi duas vezes: uma chamada code agent orchestra, outra adversarial code review. No ciclo, isso é especialmente importante porque ele roda quando você não está olhando — um verificador confiável é sua única garantia de segurança. Subagentes consomem tokens, pois cada um roda seu modelo e ferramentas, então use-os onde realmente vale a pena: para obter uma segunda opinião valiosa. O /goal do Claude Code é assim: um modelo novo decide se o ciclo terminou, não o 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 toda manhã no repositório. Ele chama um skill de triagem, lê falhas de CI, issues abertas, commits recentes, registra tudo num markdown ou quadro Linear. Para cada descoberta relevante, esse thread cria um worktree isolado, manda um subagente redigir uma solução, e outro subagente revisa com base nas skills do projeto e nos testes existentes.

Connectors fazem PRs, atualizam tickets. Tudo que não puder fazer, vai para a triagem. O arquivo de estado é a espinha dorsal, registra o que foi tentado, o que passou, o que ainda está aberto — assim, amanhã de manhã, dá para 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 roda 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 agudos, não mais fáceis.

Verificação ainda é sua responsabilidade. Um ciclo que roda sem supervisão é um ciclo sem quem corrija erros. Separar o verificador do criador faz a "conclusão" do ciclo ter sentido; mesmo assim, "concluir" é uma afirmação, não uma prova. Como na peça sobre revisão de código na era da IA, seu trabalho é entregar código que você possa confirmar pessoalmente.

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

Postura confortável é postura perigosa. Quando o ciclo roda sozinho, você tende a parar de ter opiniões, aceitar o que ele devolve. Chamo isso de surrender cognitivo. Projetar ciclos é uma cura quando você tem julgamento, mas um acelerador quando quer evitar pensar — o mesmo movimento, resultados opostos.

Montar o ciclo, mas continuar sendo engenheiro

Acredito que essa seja a direção do nosso trabalho no futuro. Mas, se eu não revisar o código pessoalmente, ou confiar totalmente no ciclo automático, a qualidade do produto cai. Provavelmente, cairei numa espiral descendente, cada vez mais fundo.

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

O ciclo também varia muito com a "pessoa" que o opera. Dois indivíduos usando o mesmo ciclo podem obter resultados completamente opostos. Uma pessoa usa para acelerar trabalhos que ela entende profundamente, 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 a engenharia de prompt. Cherny não quer dizer que o trabalho ficou mais fácil, mas que o ponto de alavanca mudou.

Monte 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.