Loop Engineering.
Autor original: Addy Osmani
Compilado por: Peggy, BlockBeats

Editor's note: The way AI coding agents are used is shifting from “humans manually writing prompts and advancing tasks step by step” to “humans designing loops that allow the system to continuously schedule agents.” Loop Engineering, as described by Addy Osmani, centers on building a workflow that automatically discovers tasks, assigns them, checks results, tracks progress, and determines the next steps.

Este ciclo é composto aproximadamente por cinco módulos: Automations (descoberta e triagem programadas de tarefas), Worktrees (isolação de múltiplos ambientes de desenvolvimento em paralelo), Skills (acúmulo de conhecimento do projeto e práticas da equipe), Plugins/Connectors (integração com ferramentas reais como GitHub, Linear, Slack, bancos de dados), Sub-agents (separação entre executores e revisores), além de uma camada externa de memória, como arquivos Markdown ou quadros Linear, para armazenar estado e progresso.

O artigo lembra que o significado da Loop Engineering não é apenas "fazer o AI rodar mais vezes", mas sim antecipar o julgamento dos engenheiros para o design do sistema. Os loops podem amplificar significativamente a alavanca do trabalho dos desenvolvedores, mas não substituem a validação, a compreensão e o julgamento. O verdadeiro risco não está no uso de loops, mas em usá-los como desculpa para evitar compreender o código e o sistema. A habilidade-chave para colaborar com IA na programação no futuro talvez não seja mais apenas escrever um bom Prompt, mas sim projetar fluxos de trabalho de Agentes confiáveis, verificáveis e sustentáveis.

The following is the original text:

A engenharia de loop está substituindo seu papel como "pessoa que escreve prompts para agentes". Você deve projetar um sistema que faça o papel de fornecer prompts para agentes em seu lugar. Aqui, o loop pode ser entendido como um objetivo recursivo: você define um objetivo, e a IA itera continuamente até que a tarefa seja concluída. Ele é composto basicamente por cinco componentes, e o Claude Code e o Codex já possuem agora esses cinco componentes.

Acredito que esta pode ser a forma como colaboraremos com agentes de codificação no futuro. No entanto, tudo ainda está em estágio inicial, e mantenho uma postura cética. Você precisa ser extremamente cuidadoso com os custos de tokens, pois as diferenças de custo podem ser enormes dependendo do modelo de uso, especialmente se você for “token rico” ou “token apertado”. Você também precisa de algum mecanismo para garantir que a qualidade não diminua. As preocupações sobre “produção de lixo de IA” (slop) são válidas. Mesmo assim, vamos ver o que realmente está acontecendo.

@steipete disse recentemente: “Você não deve mais escrever prompts para agentes de codificação. Você deve projetar ciclos que façam os prompts para seus agentes.” Da mesma forma, @bcherny, responsável pelo Claude Code da Anthropic, também disse: “Atualmente, já não faço prompts para o Claude. Tenho um conjunto de ciclos em execução que fazem os prompts para o Claude e decidem sozinhos qual é o próximo passo. Meu trabalho é escrever os ciclos.”

Então, o que isso significa exatamente?

Nos últimos cerca de dois anos, o que você queria que um agente de codificação fizesse era basicamente escrever um bom prompt e fornecer bastante contexto. Você digitava uma frase, lia o resultado retornado e depois digitava a próxima frase. O agente era uma ferramenta, e você sempre mantinha essa ferramenta em mãos, empurrando-a rodada após rodada. Essa fase, de certa forma, já chegou ao fim — pelo menos algumas pessoas acreditam que está prestes a terminar.

Agora, você está construindo um pequeno sistema: ele descobre tarefas por conta própria, atribui tarefas, verifica resultados, registra conclusões e decide o próximo passo. Ou seja, você faz com que esse sistema impulsione os agentes, em vez de você mesmo fornecer instruções repetidamente. Anteriormente, eu escrevi sobre seu “parente próximo” — agent harness engineering (engenharia de estrutura de execução de agentes), que consiste em criar um ambiente de execução para um único agente; e factory model (modelo de fábrica), que é um sistema para construir software. O loop engineering situa-se acima do harness. Ele é como um harness, mas opera com base em um temporizador, gera pequenos assistentes e se autoalimenta.

O que me surpreendeu é que isso já não é mais apenas um problema de “ferramenta”. Há um ano, se você quisesse um loop, precisava escrever uma grande quantidade de scripts bash e manter esse conjunto de scripts para sempre. Era algo seu e apenas seu. Agora, esses componentes já estão diretamente integrados ao produto. As capacidades listadas por Steinberger podem ser quase correspondidas ponto a ponto no aplicativo Codex e também quase igualmente no Claude Code. Assim que você perceber que sua forma é a mesma, deixará de se preocupar com qual ferramenta usar e passará a projetar um loop: independentemente de em qual ferramenta você estiver sentado, ele continuará funcionando.

Cinco componentes, além de algumas observações

Um loop precisa de cinco coisas, mais um local para lembrar informações. Primeiro, vou listá-las, depois vou correspondê-las uma a uma.

Primeiro, Automations (tarefas automatizadas): acionadas conforme agendado, realizam automaticamente a descoberta e o encaminhamento.

Em segundo lugar, Worktrees (árvores de trabalho): permitem que dois agentes trabalhando em paralelo não sobrescrevam os arquivos um do outro.

Terceiro, Skills (habilidades): anote o conhecimento do projeto para evitar que o agente precise adivinhar a cada vez.

Quarto, Plugins and connectors (plug-ins e conectores): permita que o agente se conecte às ferramentas que você já está utilizando.

Quinto, sub-agentes: um responsável por propor soluções e outro por verificar as soluções.

Em seguida, o sexto item: memory (memória). Pode ser um arquivo Markdown, um quadro Linear ou qualquer outro local independente da conversa única que consiga armazenar "itens concluídos" e "próximos passos". Parece tão simples que não parece importante, mas é a mesma técnica em que todos os agentes de longa duração se baseiam. Também escrevi detalhadamente sobre isso em agentes de longa duração: o modelo esquece entre cada execução, então a memória precisa estar no disco, e não no contexto. O agente esquece, mas o repositório de código não.

Agora, ambos os produtos possuem esses cinco componentes.

Eles têm nomes diferentes em alguns aspectos, mas as capacidades são essencialmente as mesmas. Vou explicar um por um, porque, honestamente, se um loop funciona de forma estável ou vaza silenciosamente por todos os lados, a chave está nos detalhes.

Automations é o que torna o loop verdadeiramente um loop, e não apenas uma tarefa única executada manualmente uma vez. No aplicativo Codex, você pode criar uma automação na aba Automations, escolhendo o projeto, o prompt que ela deve executar, a frequência de execução e se ela deve rodar no seu checkout local ou em um worktree em segundo plano. Os resultados das execuções que identificam problemas são encaminhados para a caixa de entrada Triage, enquanto os resultados sem problemas são automaticamente arquivados — o que é ótimo. A OpenAI também usa isso internamente para tarefas chatas mas necessárias, como triagem diária de issues, resumo de causas de falhas no CI, redação de boletins de commit e rastreamento de bugs introduzidos por alguém na semana passada. As automações também podem chamar skills, permitindo que tarefas repetitivas permaneçam mantáveis: acione $skill-name em vez de colar uma parede inteira de instruções em uma tarefa agendada que ninguém mais atualizará.

Claude Code também pode alcançar o mesmo efeito, apenas com caminhos diferentes: ele realiza isso por meio de agendamento e hooks. Você pode executar um prompt ou comando em intervalos fixos usando /loop, agendar uma tarefa cron ou acionar comandos shell em determinados pontos do ciclo de vida do agente usando hooks. Se desejar que ele continue executando após fechar seu computador, também pode implantar todo o conjunto no GitHub Actions. A ideia é exatamente a mesma: você define uma tarefa autônoma, dá a ela um ritmo e permite que os resultados cheguem até você, em vez de você ter que procurá-los por toda parte.

Outro primitivo de sessão worth knowing, que se aproxima mais do núcleo verdadeiramente discutido neste artigo. /loop executa repetidamente em ritmo; /goal continua executando até que alguma condição que você especificou seja verdadeiramente atendida. Após cada rodada, um pequeno modelo separado avalia se a tarefa foi concluída, então o agente que escreve o código não é o mesmo que se autoavalia. Você pode fornecer uma condição, como “todos os testes em test/auth passaram e o lint está limpo”, e depois ir embora. O Codex também possui essa mesma capacidade, chamada igualmente de /goal. Ele continua trabalhando entre rodadas até que uma condição de parada verificável seja atendida, e suporta pausa, recuperação e limpeza. O mesmo primitivo está presente em ambas as ferramentas. Essa é basicamente a estrutura que aparece repetidamente neste artigo.

Então, as Automations são responsáveis por trazer o trabalho à tona; o restante do loop cuida de executar esse trabalho.

Quando você executa mais de um agente, conflitos de arquivos se tornam pontos de falha. Dois agentes escrevendo simultaneamente no mesmo arquivo é tão problemático quanto dois engenheiros modificando a mesma linha de código sem comunicação. O git worktree resolve esse problema. Ele é um diretório de trabalho separado em uma branch independente, mas compartilha o mesmo histórico de repositório de código, portanto, as alterações de um agente não podem fisicamente interferir no checkout de outro agente.

O Codex possui suporte integrado ao worktree, permitindo que múltiplas threads processem o mesmo repositório simultaneamente sem conflitos. O Claude Code também pode alcançar o mesmo isolamento por meio do git worktree: você pode abrir uma sessão em um checkout independente usando a flag --worktree, ou definir isolation: worktree no subagent, fazendo com que cada subagente receba um checkout totalmente novo e seja limpo automaticamente após o término. Já abordei o aspecto humano disso no the orchestration tax: os worktrees eliminam conflitos mecânicos, mas você ainda é o limite. O que realmente determina quantos agentes você pode executar simultaneamente não são as ferramentas, mas seu review bandwidth (banda de revisão).

Skill é um mecanismo que permite que você não precise reexplicar o mesmo contexto de itens a cada sessão, como um peixe dourado. Ambas as ferramentas usam o mesmo formato: uma pasta contendo um arquivo SKILL.md, que armazena instruções e metadados; além disso, podem haver scripts opcionais, referências e arquivos de recursos. O Codex executa um skill quando você o chama com $ ou /skills, e também o executa automaticamente quando sua tarefa corresponde à descrição desse skill. É por isso que uma descrição concisa e simples geralmente é melhor do que uma descrição inteligente e elaborada. O Claude Code segue o mesmo padrão, e já escrevi sobre esse modelo nos agent skills.

Skills também é o lugar onde você impede que intenções sejam consumidas repetidamente. Já mencionei na dívida de intenção que, a cada início de conversa, o agente inicia em modo frio; sempre que houver lacunas em sua intenção, ele preencherá com suposições confiantes. Skills são justamente essas intenções escritas externamente: acordos de projeto, etapas de construção, “não fazemos isso porque aconteceu aquele acidente antes”, tudo escrito uma única vez em um local que o agente lê a cada execução. Sem skills, a cada ciclo o agente precisa rederivar todo o seu projeto do zero; com skills, é como se estivesse crescendo com juros compostos.

Há uma coisa a ser clareada: skill é o formato de escrita, enquanto plugin é o método de distribuição. Quando você deseja compartilhar um skill entre vários repositórios de código ou empacotar vários skills juntos, você os encapsula como um plugin. Assim é com o Codex, e assim é com o Claude Code.

Um loop que só consegue acessar o sistema de arquivos é um loop muito pequeno. Connectors baseados em MCP permitem que agentes leiam seu rastreador de issues, consultem bancos de dados, chamem APIs de staging ou enviem mensagens no Slack. Codex e Claude Code suportam MCP, então um connector que você escrever para um geralmente também funcionará no outro. Plugins empacotam connectors e skills juntos, permitindo que seus colegas instalem toda a configuração de uma vez, em vez de tentar reconstruí-la da memória.

É essa a diferença entre “um agente te dizendo ‘esta é a solução’” e “um loop que abre automaticamente um PR, vincula um ticket do Linear e notifica o canal após a aprovação do CI”. Os Connectors são importantes porque permitem que o loop atue em seu ambiente real, e não apenas diga “se eu pudesse, eu faria isso”.

Dentro de um loop, o design estrutural mais útil é separar claramente quem escreve e quem revisa. O modelo que escreve o código tende a ser excessivamente generoso ao corrigir seu próprio trabalho. Um agente diferente, com instruções distintas e, às vezes, até usando um modelo diferente, consegue identificar problemas que o primeiro agente ignorou após se convencer a si mesmo.

O Codex gerará subagents apenas quando solicitado; eles serão executados em paralelo e os resultados serão combinados em uma única resposta. Você pode definir seus próprios agents usando arquivos TOML em .codex/agents/: cada agent possui um nome, uma descrição, instruções e, opcionalmente, um modelo e intensidade de raciocínio. Assim, seu revisor de segurança pode ser um modelo forte com alta intensidade de raciocínio, enquanto seu explorador pode ser um modelo leve, rápido e somente leitura. O Claude Code também oferece capacidades semelhantes por meio de subagents e equipes de agents em .claude/agents/, permitindo que múltiplos agents se passem o trabalho entre si. A divisão mais comum em ambos os casos é: um agent explora, um agent implementa e um agent valida conforme as especificações.

Já expus essa ideia duas vezes: uma vez no code agent orchestra e outra no adversarial code review. Ela é especialmente importante no loop, porque o loop executa-se quando você não está observando, e um verificador em que você realmente confia é a única razão pela qual você pode se permitir sair. Subagents realmente consomem mais tokens, pois cada agente realiza suas próprias chamadas de modelo e chamadas de ferramentas; portanto, você deve usá-los em situações em que uma segunda opinião vale a pena pagar. Isso é basicamente o que o /goal do Claude Code faz por baixo dos panos: um novo modelo avalia se o loop foi concluído, em vez de deixar o modelo que realizou o trabalho fazer essa avaliação. Ou seja, ele aplica a separação entre "criador" e "verificador" diretamente à condição de parada.

Como é um loop?

Junte tudo isso, e um único fio se tornará um pequeno painel de controle. Abaixo está uma estrutura que uso frequentemente.

Todos os dias de manhã, uma automação é executada no repositório de código. Seu prompt invoca uma habilidade de triagem, que lê os falhos de CI do dia anterior, as issues abertas e os commits mais recentes, registrando as descobertas em um arquivo Markdown ou em um quadro Linear. Para cada problema digno de atenção, a thread abre um worktree isolado, instancia um sub-agente para propor uma solução e, em seguida, um segundo sub-agente para revisar a proposta com base nas habilidades do projeto e nos testes existentes.

Connectors permitem que esse loop abra automaticamente um PR e atualize o ticket. Qualquer coisa que o loop não consiga tratar será encaminhada para a caixa de entrada de triagem, para que eu processe. O arquivo de estado é a espinha dorsal de todo o sistema: ele lembra o que foi tentado, o que passou e o que ainda não foi concluído. Assim, a execução da manhã seguinte continuará de onde parou hoje.

Observe o que você realmente fez. Você apenas projetou uma vez. Esses passos não foram solicitados por você individualmente. Essa é a versão real da frase de Steinberger. E o mesmo loop pode ser executado no Codex ou no Claude Code, pois os componentes são os mesmos.

Loop ainda não fará nada por você

O Loop mudou a forma de funcionar, mas não vai te remover do trabalho. Na verdade, à medida que o loop se torna mais forte, três problemas ficam mais agudos, e não mais fáceis.

A verificação ainda depende de você. Um loop executado sem supervisão também pode estar cometendo erros sem supervisão. A razão pela qual você separou o sub-agente verifier e o maker é para que a frase do loop “concluído” tenha algum significado. Mesmo assim, “concluído” ainda é uma alegação, não uma prova. Repito sempre a mesma frase em code review in the age of AI: sua responsabilidade é entregar código que você confirmou ser válido.

Se você deixar de lado, sua própria compreensão ainda se deteriorará. Quanto mais rápido o loop entregar código que você não escreveu diretamente, maior será a lacuna entre o que você realmente entende e o que realmente existe no sistema. Isso é o que chamamos de dívida de compreensão. Se você não ler o que o loop produz, um loop suave apenas acelera o crescimento dessa dívida.

E, sim, a postura mais confortável provavelmente também é a mais perigosa. Quando o loop consegue operar sozinho, é fácil parar de formar seus próprios julgamentos e simplesmente aceitar qualquer coisa que ele retorne. Chamo isso de surrender cognitivo. Se você projetar o loop com julgamento, ele é a cura; se você projetar o loop apenas para evitar pensar, ele é o acelerador. O mesmo ato pode produzir resultados completamente opostos.

Construa o loop, mas continue sendo engenheiro

Acho que isso prenuncia a evolução do nosso trabalho futuro. Dito isso, se eu não revisar o código pessoalmente ou depender totalmente de um loop automatizado para corrigir o código, a qualidade do meu produto será comprometida. Muito provavelmente entrarei em uma espiral descendente: continuamente me enterrando em buracos cada vez mais profundos.

Então, você certamente pode criar seu próprio loop, mas não se esqueça que orientar diretamente seu agente ainda é eficaz. O importante é encontrar o equilíbrio adequado.

Os resultados do Loop também variam de pessoa para pessoa. Duas pessoas podem construir exatamente o mesmo loop e obter resultados totalmente opostos. Uma o usa para acelerar seu trabalho no qual compreende profundamente; outra o usa para evitar compreender o próprio trabalho. O Loop não sabe distinguir entre esses dois casos. Você sabe.

É por isso que o loop design é mais difícil, e não mais fácil, do que o prompt engineering. O significado de Cherny não é que o trabalho ficou mais fácil, mas sim que o ponto de alavanca mudou.

Construa o loop. Mas construa-o como alguém que ainda pretende ser engenheiro, e não como alguém que só aperta o botão “iniciar”.

[Link original]

Clique para saber mais sobre as vagas em aberto na BlockBeats

Bem-vindo ao grupo oficial da BlockBeats:

Grupo de assinatura no Telegram: https://t.me/theblockbeats

Grupo de Telegram: https://t.me/BlockBeats_App

Conta oficial no Twitter: https://twitter.com/BlockBeatsAsia