Toda semana aparece uma manchete nova mandando você parar de fazer alguma coisa. Um tempo atrás era "pare de escrever código". Agora é "pare de promptar". A frase que rodou o mundo veio do Boris Cherny, o criador do Claude Code na Anthropic. Ele disse que não prompta mais o Claude. Tem loops rodando que promptam o Claude e vão descobrindo o que fazer.
Meu primeiro impulso foi torcer o nariz. Soa como buzzword de vender curso. Mas foi justamente essa fala do Cherny que me empurrou a cavar o tema dos loops e de como dá pra otimizar o desenvolvimento com IA de verdade. Fui olhar de perto, e a coisa tem osso. O mais interessante pra mim é que ela confirma quase ponto a ponto o que venho escrevendo aqui sobre pra onde o valor migra quando a execução fica barata.
A alavanca subiu de andar
Quem deu nome ao movimento foi o Addy Osmani, engenheiro do Google, num ensaio de junho. Ele juntou a fala do Cherny com uma do Peter Steinberger, que dizia a mesma coisa por outras palavras: você não deveria estar promptando agentes, deveria estar projetando os loops que promptam os seus agentes. Osmani chamou isso de loop engineering e organizou a ideia.
A definição que mais me ajudou é posicional. Prompt engineering entrega uma instrução. Harness engineering monta o ambiente em que um agente roda, os trilhos na entrada e os sensores na saída. Loop engineering fica um andar acima do harness. É o sistema que descobre o trabalho, distribui, confere o resultado, anota o que ficou pronto e decide o próximo passo. E aí solta esse sistema pra cutucar os agentes no seu lugar.
Repare no que muda de posição. Antes, você era quem digitava a instrução e ficava olhando. Agora, você é quem desenha o mecanismo que digita a instrução. Você saiu do banco do motorista e foi projetar o piloto automático. Não é uma diferença de grau. É uma diferença de papel.
O loop terceiriza a execução, não a intenção
Foi aqui que caiu a ficha. Loop engineering é o V-Bounce rodando sozinho.
Quando descrevo o loop na forma mais crua, ele tem cinco estágios, do jeito que o pessoal da KyenAI mapeou: planejar, agir, observar, verificar e então repetir ou parar. Olhe onde está o humano nessa fila. No plano, lá na frente, quando você define a tarefa, os arquivos permitidos, o comando de verificação, o orçamento e o limite de aprovação. E no critério de parada, lá no fim, quando você escreve a condição que diz "acabou". O meio, o agir e o observar, é onde a máquina brilha e você não precisa estar.
Isso é o paradigma 70/30 escancarado. Os 70% que continuam sendo trabalho humano de verdade são a intenção na entrada e a validação na saída. A execução, os 30%, é o que o loop engole. O loop não terceiriza a parte difícil. Ele terceiriza a parte que já tinha ficado barata. E deixa exposto, sem lugar pra se esconder, exatamente o que sempre foi o cerne da engenharia: saber o que você quer e saber reconhecer quando conseguiu.
Tem uma frase do Osmani que eu não tiro da cabeça. Construa o loop, mas construa como quem pretende continuar sendo o engenheiro, não como quem só aperta o play. É mais difícil que prompt engineering, não mais fácil. Porque agora você precisa codificar o seu julgamento numa condição de parada, e não mais aplicá-lo na mão a cada rodada.
O loop que rodou 48 horas e não valeu nada
Falo isso com a autoridade de quem já se queimou. Quando o Cherny começou a bater nessa tecla dos loops acima dos prompts, fui atrás. Montei um loop pra tocar um épico inteiro e deixei rodando. Quarenta e oito horas depois, voltei pra ver o que tinha saído. Era uma bosta, sem meias palavras. Um resultado eslópico, com cara de pronto, que não servia pra nada.
Fui entender o que deu errado, e não era o modelo. Era eu. Tinha soltado o loop em cima de ambiguidade pura. A visão de negócio estava vaga, as regras de negócio pela metade, e boa parte ainda era prototipação, coisa que nem eu sabia direito como deveria ficar. O loop não errou a execução. Ele executou com esmero uma intenção mal feita. Entra lixo, sai lixo, agora em escala.
Então fiz o que o loop me obrigou a fazer. Parei, verifiquei o estrago, e decidi re-representar o trabalho do zero. Dessa vez não comecei pelo loop. Comecei pela intenção. Quebrei o épico em quatro grandes filtros, cada um com um recorte claro do que entrava e do que saía. E pra cada filtro detalhei as duas intenções que importam, a funcional, o que aquilo precisa fazer pro negócio, e a técnica, como aquilo deveria ser construído. Só depois de ter isso firme é que soltei o loop de novo.
O resultado foi fantástico. Mesmo loop, mesma máquina, mesmo modelo. A única coisa que mudou foi a qualidade da intenção que entrou. E foi só isso que separou 48 horas de lixo de um trabalho que eu assinaria embaixo. Se você quer um número pra essa história, ele é o 70/30. Gastei uma fatia mínima do tempo mexendo no loop e a maior parte definindo bem a intenção, a funcional e a técnica. Não porque um framework mandou. Porque a primeira tentativa me mostrou, na marra, que é ali que o trabalho difícil mora.
A regra de ouro virou condição de parada
Quem acompanha o que escrevo sabe que eu insisto numa regra sobre as camadas de autonomia. Quanto mais crítica a tarefa e mais autônomo o agente, mais robusto precisa ser o controle antes de soltar. No mundo do loop, essa regra ganhou um nome operacional. Ela virou a stop rule.
A KyenAI lista as condições de parada de um jeito que eu assinaria embaixo. O loop para quando a verificação passa ou quando bate o teto de iterações. Para quando a mesma falha se repete duas vezes pela mesma causa raiz, porque insistir vira desperdício. Para quando o próximo passo exigiria uma permissão maior do que a combinada. Para quando o orçamento de token acabou. E para quando o agente não consegue justificar a próxima ação a partir do que observou.
Sabe o que é mais bonito nisso? Nenhuma dessas regras é sobre o modelo ser esperto. Todas são sobre o loop saber a hora de desconfiar de si mesmo. Um loop rodando sem vigia é também um loop errando sem vigia. É por isso que o padrão que mais me convenceu separa quem faz de quem confere. O sub-agente que verifica não é o mesmo que escreveu o código. Você não deixa o agente corrigir a própria prova. Esse split é o que faz o "acabou" do loop significar alguma coisa.
Um loop bom não é um truque seu
Aqui mora a parte que o hype esquece de contar. Montar um loop que funciona na sua máquina numa tarde é fácil. O difícil é fazer dele uma capacidade que a empresa herda sem prender a respiração.
O repositório do Cobus Greyling, que virou uma das referências práticas do tema, organiza isso em blocos que dão o que pensar. Automação em cadência pra achar e triar trabalho sozinho. Worktrees pra rodar coisas em paralelo sem uma pisar na outra. Skills como conhecimento durável do projeto. Sub-agentes no esquema maker e checker. E uma espinha de memória e estado que vive fora da conversa. Ele ainda cataloga sete padrões de produção, do triador diário ao babá de pull request, cada um com sua cadência e seu custo de token estimado.
Leia essa lista de novo e me diga o que você vê. Eu vejo golden paths. Vejo plataforma interna. Vejo TI como curadora de capacidades, não como fábrica de demandas. Um loop maduro tem identidade, orçamento, limite de permissão, log e um responsável. Isso não é um script pessoal esperto. É uma capacidade governada. A diferença entre as duas coisas é a mesma de sempre, e ela nunca foi o modelo. Foi a estrutura em volta.
Quem projeta o loop continua sendo o engenheiro
O Osmani cita um risco que eu chamaria de a armadilha silenciosa. Ele fala em cognitive surrender, a rendição cognitiva. É o conforto de deixar o loop rodar e ir perdendo, aos poucos, a capacidade de julgar o que ele entrega. O código sobe sem ninguém ler. A compreensão do sistema encolhe. E um dia você não sabe mais dizer se o loop está certo, só que ele não reclamou.
É esse o preço que ninguém coloca no slide. A barreira técnica caiu, eu repito sempre, mas cair a barreira não é sumir o critério. Loop engineering não tira o engenheiro do circuito. Ele muda onde o engenheiro rende mais, que passou a ser a definição do objetivo e da parada, e o desenho de quem confere quem.
No fim, é a mesma história de sempre contada com uma palavra nova. A máquina ficou boa em executar. O que continua difícil, e provavelmente vai continuar por um bom tempo, é querer a coisa certa e reconhecer quando ela chegou. Você pode automatizar o loop inteiro. Menos essa parte.
Referências
- Addy Osmani – Loop Engineering. addyosmani.com, 07/06/2026. Ensaio que nomeia a prática; cita Boris Cherny e Peter Steinberger.
- KyenAI – What Is Loop Engineering? AI Agent Loops, Examples, Stop Rules. Atualizado em 26/06/2026. Ciclo de cinco estágios e regras de parada.
- Cobus Greyling – loop-engineering (repositório). v1.5.0, 30/06/2026. Building blocks, sete padrões de produção e o split maker/checker.
- Cory Hymel – The AI-Native Software Development Lifecycle (modelo V-Bounce). arXiv 2408.03416, 2024. Base do paradigma 70/30.