Loop Engineering: 500 mil linhas migradas por IA. Deu certo?

O Ban acabou de ser migrado para Rust, mais de 500 mil linhas de código, usando Loop Engineering. E está toda a indústria falando de Loop Engineering como se fosse a próxima grande coisa da IA. Bom, a internet explodiu nas últimas semanas com o criador do OpenClaw, o Peter, falando que não dá mais prompt, só trabalha em loops. O Boris, criador do Cloud Code, falou algo bem similar, que ele trabalha em loops. que decidem o que fazer. E a internet explodiu falando de loops e loops como se fosse a próxima grande coisa que vai resolver tudo na IA. E nesse vídeo eu não só vou te mostrar como criar loops, os patterns principais de loops, como também te dar um codebase completo desse jogo que eu fiz em um final de semana usando patterns avançados de loop engineering. todas as minhas skills, todas as minhas técnicas para você conseguir fazer os seus projetos. A primeira coisa que a gente tem que entender é o dev loop antes do boom de loop engineering. Até então, com o IA, a gente vinha trabalhando de uma forma onde a gente tem o loop de nível 1, que eu chamo aqui, que é o React. Para quem não sabe, o React foi o primeiro loop que foi criado, que veio a público, que é a gente saiu ali, pensem no dia a dia de vocês com o IA. Quem está desde o início de 2023, a gente saiu do chat, onde a gente dava um prompt, esperava a resposta e dava mais um prompt, para o módulo agêntico, onde tu dá um prompt e o agente fica num loop trabalhando até resolver aquele prompt que deu para ele. Então, basicamente, esse foi o primeiro prompt que foi criado. Em cima desse prompt, a gente começou a automatizar coisas e um clássico é Spec Driven. Basicamente, Spec Driven é o quê? A gente tem uma lista de coisas, de passos. que dão gatilhos em vários loops de agentes por baixo. Ou seja, o loop React do agente, a gente não tem controle. A gente tem controle em cima dele. Então, com o Spec Driven, a gente consegue dar uma receita que vai executar vários loops. Então, a gente executa um loop para planejar, a gente executa um loop para criar um design, a gente executa vários loops, cada um para implementar uma task, por exemplo. Dessa maneira, a gente criou essa segunda camada. Pense aqui o seguinte. No primeiro nível, a gente dava um prompt para a gente, ele ficava loopando até fechar aquilo ali. Isso aí já permitia fazer uma tarefa de alguns minutos. Com o Spec Driven, a gente consegue dar um prompt em uma estrutura muito maior, porque ele consegue executar vários loops e isso nos permite implementar coisas que levam a horas. Só quando essas coisas terminam, a gente tem que entrar no loop, é a hora que o humano entra. Então pensa nessa parte aqui, que é o terceiro nível, que é... Onde o humano entra? Então o humano entra para abrir um pull request, por exemplo. O humano entra para decidir o próximo passo. Eu terminei essa minha spec aqui de implementar toda ela. Eu tenho que planejar a próxima, por exemplo. Entra para consultar métricas, entra para fazer triagem, por exemplo, um bug. Faz triagem do bug, investiga o bug, cria uma task do bug, aí sim faz um plano para implementar o bug. Então... O humano estava nessa parte aqui. A ideia de Loop Engineering que eles estão falando, principalmente o criador do Cloud Code, o Peter, do OpenClaw, ele é mais VibeCoder. Ele fez todo o OpenClaw com VibeCode, então tem que pensar que às vezes ele não encaixa muito bem as coisas dele para o nosso meio de desenvolvimento de software e enterprise mais complexo. Mas o criador do Cloud Code é uma boa referência. A ideia deles é qual? Você ter mais uma camada. Então se a gente já tinha a camada que eu chamo de Mini Loop do Spec Driven, A gente vai botar mais uma camada que vai automatizar mais a nossa vida e vai nos permitir sair de horas numa spec, por exemplo, implementando, para dias implementando vários planos ou vários passos. Não precisa necessariamente ser uma spec do spec-driven. Pode ser, por exemplo... bater num datadog e pegar informações de um incidente, dessas informações de um incidente, criar uma task, planejar uma task, ver a severidade daquela task, notificar as pessoas, implementar ela, abrir um pull request. Pensa que isso é um loop que tu pode automatizar todo ele e tirar o humano o máximo possível. Então essa que é a ideia. A ideia é tu botar mais uma camada acima que tu consiga fazer coisas sem ficar dando prompt toda hora que... fecham um ciclo completo ou vários ciclos. E para a gente até comparar isso com o Chrome Job, que é a primeira coisa que as pessoas pensam, mas isso não é só um loop rodando automático? A grande diferença fundamental é que o Chrome Job ou um while, você vai ter um if que decide se continua ou não. Num loop agêntico, você tem o próprio modelo decidindo se vai continuar ou não. Não é um if, é um modelo que interpreta e decide se segue ou não. aquele passo. Então, ele lê um estado, por exemplo, no meu caso, o exemplo que eu vou mostrar pra vocês, ele lê um roadmap e vê se tem mais itens no roadmap, eu devo planejar o próximo item e continuar. Então, essa que é a grande diferença, tem uma coisa que pensa se decide ou não ir pro próximo loop. E pensando em exemplos práticos aqui, pense o seguinte, primeiro a gente tem spec-driven, que é o humano por fora, um exemplo de humano por fora, ou seja, o humano dá um prompt e ali tem dois casos que podem acontecer. Tem o caso que não é um loop, que é onde tu diz pra gente, cria spec, ele cria spec, agora cria o design, ele cria o design, agora cria as tasks, ele cria as tasks, agora implementa as tasks. Isso não é um loop. Mas tu pode dizer para um framework de Spec Driven, tipo o TLC Spec Driven, que é o nosso, que eu vou deixar o link para vocês, tu pode dizer para ele, olha, pega esse contexto, planeja tudo, aí vai ter um planejamento, depois tu pega as tasks e tu diz, implementa essas tasks. Quando tu diz implementa essas tasks, ele começa... um loop de implementação. Ele implementa uma, valida aquela task, se não deu certo, ele corrige aquela task. Então eu chamo isso de um mini loop autônomo. Ainda preciso de um humano ali. Mas os exemplos que eu vou mostrar para vocês são dois loops realmente autônomos que... tomam decisões sem o Manutali, que permite que eles rodem por horas ou até dias. O primeiro que eu vou mostrar é o que eu chamo de loop fixo. Aqui a indústria ainda não tem um nome para esses loops. Eu chamo de loop fixo um loop que é o seguinte, é um loop que não tem side effect. Qual é esse loop que eu vou mostrar para vocês? É a avaliação de frameworks de Spec Driven que eu fiz. É um loop multi-agente que eu vou mostrar para vocês. E o outro que eu vou mostrar é um jogo completo que eu fiz. para testar fluxos de longo prazo que tem side effects, que eu chamo de loop criador. Qual que é a diferença de um loop criador? É quando tu gera um roadmap, tu faz uma coisa, a partir daquela coisa que foi feita, tu gera outro roadmap e tu segue inteirando até construir uma aplicação inteira. Esse é extremamente complexo porque tem vários side effects. O primeiro side effect que eu vou falar sobre ele é quando tu gera algo e aquele algo vai com bug e aí tu gera coisas em cima. com um bug que vai perpetuando um bug no final fica com um grande problema então esse loop aqui é extremamente avançado e complexo eu vou explicar quando usar mas é esse aqui que foi usado na migração do buh e eles passaram pela mesma coisa que eu passei no meu experimento que eu vou mostrar pra vocês bom então no primeiro exemplo como eu falei eu tenho um loop que avalia frameworks de Spec Driven. Eu digo assim, bench run, que é de benchmark, rode duas avaliações do framework TLC Spec Driven. Ou seja, lembra a coisa de parar de dar prompt? Aqui eu estou dando um prompt mínimo que vai começar um loop que vai rodar duas avaliações do TLC Spec Driven e vai me dar um resultado. O bench run é uma skill que eu fiz que orquestra framework de Spec Driven para implementar. Então, basicamente, lembra o terceiro nível ali? ele está em cima dos frameworks de Spec Driven. Então, o que ele faz é, sempre que eu dou um framework de Spec Driven, ele sabe que tem que planejar, implementar e depois verificar. Então, eu fiz vários agentes aqui. Eu tenho um Evaluator, um Implementer e um Planner, que cada um deles faz um desses passos. Se a gente pegar esse exemplo aqui, que eu avaliei a TLC Spec Driven, vocês vão ver que ele me dá o resultado completo. E aqui, ele roda os passos. Primeiro, ele roda um Plan. Depois ele vai lá e roda o implement. E depois ele roda o evaluator aqui, que são outros agentes. Então ele sozinho controla todo o loop. Então eu automatizei uma coisa que seria eu dando vários prompts para uma skill que orquestra todo esse fluxo e roda quantas vezes eu pedi. Eu chamo isso de loop fixo porque ele não tem side effect. Ele não vai criar mais código. A segunda execução... Não vai ficar pior por causa do resultado da primeira. Então esses não são normalmente seguros. Quando vocês vão usar isso? Automações, por exemplo, é bem comum usar. Eu uso muito para automações. E agora a gente entra no loop criador, que é o que eu digo que cria side effects. Esse é mais complexo porque a gente vai precisar de o quê? De um... roadmap que ele se baseia e também passos para ele saber fazer tudo. Então pensei o seguinte, eu criei esse jogo aqui completo em um final de semana usando o Loop Engineering, deixei ele rodando, eu usei uma engine aberta de um MMO famoso que tem código open source e deixei ele copiando muito similar ao que o Ban fez. para migrar para Rust, tá? O mesmo pattern, só que eu já estava fazendo antes de sair com o blog post. E o jogo está totalmente funcional, tem mobs aqui numa aula da comunidade da TechLeadsClub, entraram 200 pessoas no jogo, então ficou muito bacana. Eu vou deixar o código desse jogo todo disponível para vocês, aqui no final do vídeo eu explico, mas o que é interessante dessa parte aqui. Nesse aqui eu precisava de ter um roadmap, ou seja, algo que eu pudesse lupar para poder construir o jogo. Esse roadmap veio de eu fazer uma primeira exploração e decidir como seria feita a fundação do jogo. Quando eu decidi, eu criei um roadmap com 18 fases. Fases são épicos, para vocês entenderem. E vocês veem que a fase aqui não tem muitos detalhes, ela tem só o alto nível. Por quê? Porque como eu estou criando algo, eu não tenho como planejar todas as fases. sendo que a anterior tem que estar pronta. Então o máximo que eu consigo é criar a visão do que aquela fase vai ser, mas eu só consigo planejar ela depois que a anterior está implementada. Então eu planejei 18 fases que era a fundação do jogo. Nessa fase de fundação do jogo, eu ainda não tinha, por exemplo, como seriam os personagens, os assets que eu ia usar, as animações. Aqui era só fazer a fundação do jogo e fazer funcionar. Além do roadmap, tem outra coisa que é fundamental. em loops criadores, que é as lições aprendidas, aqui a gente tem o Lessons.md, isso aqui é criado pelo próprio TLCSpecDriver, ou seja, cada vez que ele passa por algo, toma uma decisão e aprende, ele coloca isso daqui. Isso é muito comum quando ele fica no loop tentando resolver um problema e ele consegue resolver, ele atualiza isso, assim os próximos agentes, os próximos passos não vão passar por esse problema. Um state também que diz o que foi feito numa fase, por exemplo, se teve algum blocker que ele passou e também um handoff. Quando ele termina grandes fases, ele deixa um handoff dizendo... O que o próximo precisa saber para fazer? Isso também a TLC Spec Driven faz e ajuda bastante quando está trabalhando no loop. Porque o loop autônomo tem que ter o contexto do que aconteceu e o contexto para onde as coisas estão indo e as decisões que foram tomadas. Tudo isso está aqui. A única coisa que o TLC Spec Driven não faz é criar o roadmap porque é essa camada acima que faz vários loops de specs. E esse jogo está extremamente completo e funcional. Tem o client do jogo aqui, tem o server do jogo, as mecânicas do jogo. está tudo implementado de forma correta e eu usei bastante testes para me guiar para implementar o jogo então com o roadmap eu comecei a lupar então o primeiro loop que eu criei foi usar o barra loop do curso então a maioria das ferramentas tem maneira de dar um loop que ele fica rodando e eu disse avance no roadmap até que acabe o roadmap tinha 18 tarefas e aí ele foi lupando como que ele lupou aqui? usou a TLC SpecDriven. Então, é um loop em cima de um fluxo de SpecDriven. Para cada item do roadmap, ele pegava o item e vinha que fazia o quê? Gerava uma Spec, está aqui, fase 1, foundation. Gerava uma Spec, gerava as tasks e também, no final, ele me dava uma validation. Então, eu fiz um fluxo que planejava, seguindo o SpecDriven, porque assim ele tem um harness que manda ele ir no caminho certo. E quando ele terminava essa parte... E ele validava que a própria TLC Spec Driven força uma validação. Por exemplo, aqui é uma validação da fase 3. É um sub-agent que valida se foi feito. Aqui diz que falhou, então ele mesmo vai se corrigir até ficar correto. Aí ele foi corrigindo, diz que a fase 3 passou aqui e iniciou a fase 4 de novo. Planejar a fase 4, implementar a fase 4, revisar a fase 4. Isso ficou rodando por um final de semana. Mas como que eu fiz para fazer um jogo funcional e como que o ban fez para mover para Rust 500 mil linhas de código? Seguindo essa mesma lógica de loop criador. Primeiro, pega uma tarefa, planeja a tarefa, implementa, verifica essa tarefa. Aqui, usou verify. No meu caso, era até três vezes. Atualiza o roadmap e pega o próximo item. Mas tem uma coisa muito fundamental. Esses loops funcionam bem porque eles têm uma referência sólida. No meu caso, eu tinha uma engine do jogo que já existe e eu estava copiando ela e refazendo em JavaScript. Muito similar ao Ban. Ou seja, o Ban já tinha um codebase que eles tinham 1 milhão e 300 asserções, se eu não me engano, de testes. Ou seja, eles conseguiam migrar e validar. E outra coisa que é interessante quando a gente para para pensar nessa parte de Loop Engineering é que tu tem fases. Eu fiz 18 fases, depois eu parei para pesquisar porque eu cheguei no limite. Ou seja, o loop, galera, quem fala que o loop roda para sempre, não roda. O loop, ele roda até que tenha uma próxima coisa para fazer. Chega um momento que ele esgota, ele não sabe o que fazer. Aí o humano entra... Ou seja, o loop é maior, talvez um dia, eu deixei um dia rodando, depois eu entrei e vi, agora eu tenho que decidir como que eu vou fazer as animações, os personagens, eu pesquisei. Depois daí eu gerei mais roadmap para ele trabalhar com mais uns 10, 15 épicos. E aí eu vim aqui e nesse momento eu criei uma skill, Spec Driven Execution, que basicamente sabe fazer o quê? Sabe orquestrar a TLC Spec Driven em loops. Então eu... fiz uma composição de duas skills. A TLCSpecDriven sabe fazer o quê? Planejar, implementar e validar. Só que ela não sabe trabalhar no loop. Então em cima dela eu criei outra que faz a TLCSpecDriven trabalhar bem em loops. Então basicamente o que eu disse de novo foi loopa no roadmap, usa a SpecDriven Execution, vai até o final. Outra coisa que acontece muito também é quando a gente está trabalhando com SpecDriven em um loop menor... a gente dá muitos prompts. Quando tu deixa o agente rodando por muito tempo, tem que ter muito harness. O que eu fiz? Toda pesquisa que eu fiz sobre os personagens, antes de começar a implementar, eu criei uma skill Game Designer. Essa skill tem tudo... que é necessário para criar, por exemplo, criar monstros, criar personagens, criar efeitos. Dessa maneira, o loop pode seguir sem eu ter que estar respondendo coisas para eles. Porque eu fiz uma pesquisa e essa pesquisa vale para o roadmap dos 15 itens necessários. E agora, seguindo nas coisas extremamente importantes. Eu já falei que o loop criador funciona muito bem quando tem uma coisa sólida que você pode usar para validar. E aqui tem um grande exemplo. Por que o ban migrou para Rust? Porque Rust... ele é seguro. O próprio compilador não deixa você compilar algo se você tiver problemas de memória. Comparado a Zig que eles estavam usando, Zig deixa você compilar e depois quebra em produção. Ou seja, não tem harness melhor, não tem sensor melhor. Eu vou deixar um vídeo sobre harness para vocês entenderem, mas a gente tem guidelines. que são, por exemplo, skills, as specs e sensores que são a coisa que valida, rodar teste, rodar lint ou até mesmo o próprio compilador. O que eles mostram aqui é que eles estavam movendo para uma linguagem que tem um sensor muito melhor, ou seja, a IA não precisa interpretar que será que isso aqui é memory safe? Não, ela vai rodar o compilador, se o compilador quebrar ela tem um problema que ela tem que resolver. Então isso é muito bom, a própria linguagem é o harness. Tipagem é harness, arquitetura é harness, compilador é harness e esse é um grande exemplo. Para trabalhar em loops, quanto melhor o harness, melhor. E o que foi fundamental para conseguir fazer todo o meu jogo e onde que eu quase estraguei tudo que eu falei? Eu usava testes end-to-end com PlayWrite, mas começou a ficar lento, porque eu guardava os testes. E aí eu resolvi remover os testes e usar só testes de integração e testes de unidade. Só que jogo tem muitas variáveis. E aí começou a acumular erros porque ele não testava de ponta a ponta. Aí o que eu fiz foi botar os testes end-to-end de volta, mas não deixar eles salvos. Ou seja, para ele entregar uma fase, ele tinha que iniciar um playwright, jogar e provar que estava funcionando. Assim, ele parou de acumular erros de novo. Então, se vocês forem fazer loops, vocês têm que ter uma boa suite de testes, uma boa maneira de garantir que vocês não perpetuem erros entre loops. Então, por que eu falei que loop engineering tem que tomar muito cuidado? Porque loop engineering não resolve uma suite fraca de testes. Ele não resolve a intenção, ou seja, ele não consegue criar novos roadmaps. Esse é o momento que o humano tem que entrar. Lembra que eu falei? Fiz 18 tasks, entrei e decidi sobre os personagens, criei skills de como criar personagens, deixei ele loopar, criou personagem, mapa, criou um monte de coisa. Foi até 20 e poucos, eu tive que entrar de novo para criar a parte final do jogo, que era polir algumas coisas, botar multiplayer, esse tipo de coisa. Então, em vez de eu fazer ali, se eu não me engano, são 30 fases, ou seja, eu faria... 30 loops de spec driven, eu mesmo dando prompt, eu fiz 3 grandes loops de loop engineering para fazer o jogo. Isso levou um final de semana que ele ficou trabalhando sozinho. Outra coisa é o custo do hardness. Galera, tem um custo de fazer toda essa estrutura. Na maioria dos casos, porque a gente está trabalhando com software enterprise, com features, não vai ser necessário ter esse tipo de loop. Vai ser necessário quando? migrações, automações, saber usar loop fixo e loop criador vai ajudar muito vocês quando a hora certa chegar. Bom, e como eu falei, as quatro perguntas que eu faço para decidir se eu preciso de um loop ou não. Para fazer features principalmente, primeiro, tem um bom harness que tem que estar em um nível no teu repositório que praticamente tu não revisa mais para um request. Porque se... todo pull request tem que corrigir coisas, quer dizer que teu harness ainda não tá bom e quer dizer que cada loop vai perpetuar erros e vai criar um grande problema. Então, basicamente, se tu tem problemas, usa o Spec Driven até que teu harness fique bom. O feedback é rápido, ou seja, tu consegue rodar testes rápido e tal pra ele entender, porque se for lento, tu vai gastar um monte de token nos loops e ele vai ficar muito demorado. Terceiro, tem uma stop condition confiável, não confiável, algo que ele bata e diga tem que parar e chamar o humano. E quatro, tem backlog o suficiente para valer a pena deixar lupando comparado a tu mesmo planejar e fazer? Então essas são as quatro principais coisas que tem que responder se tu vai ou não querer usar um loop. Bom, e como eu prometi, eu falei que eu ia deixar para vocês o jogo que eu fiz e eu vou usar esse repositório como base para muitas outras coisas que eu vou fazer. É o NJMMO. É baseado no L2, eu não vou falando todo o nome de jogo por direitos autorais. Mas aqui são todos, é tudo código free, tudo código que pode ser open source. E está todo o projeto aqui. Aqui dentro vocês têm acesso a specs, vocês têm acesso às skills que eu criei. E vocês vão ver que está tudo aqui. Bom, eu espero que esse vídeo tenha ajudado. Bom, eu espero que esse vídeo tenha te ajudado a entender Loop Engineering, quando usar, quando não usar e também... e também que o exemplo que eu te deixei te ajude a testar nos seus projetos. Beleza? Se tiver dúvida, comenta aqui. E também, se você já está usando o Dupe Engineering, comenta aqui que eu gosto muito de saber.

Loop Engineering tomou conta da comunidade de IA nas últimas semanas: os criadores do OpenClaw e do Claude Code dizem que não trabalham mais com prompts, e sim com loops. 

💎 Participe do maior workshop de IA para devs do Brasil https://tinyurl.com/nbex5mds

A migração do Bun para Rust, com 1 milhão de linhas geradas por IA, é a prova mais visível disso. Nesse vídeo eu explico a diferença entre loop fixo e loop criador, por que loops sem um bom harness só perpetuam bugs, e mostro o jogo completo que construí em um fim de semana deixando a IA rodar sozinha.

👉🏼 Venha para a maior comunidade de devs sênior do Brasil https://tinyurl.com/57y7meea

Capitulos
00:00 O Bun, a IA e o tal do Loop Engineering
00:44 Como chegamos aqui: a evolução do dev loop
04:05 Loop agêntico x cron job: a diferença real
05:42 Os 2 tipos de loop: fixo e criador
06:48 Loop fixo na prática (benchmark multiagente)
08:20 O jogo que a IA construiu num fim de semana
09:19 O roadmap de 18 fases
12:22 Como o Bun migrou 500 mil linhas pra Rust
13:19 O loop NÃO roda pra sempre
14:58 Por que o harness é tudo (e por que Rust)
15:55 O erro que quase estragou o jogo
16:35 Loop Engineering não é bala de prata
17:39 As 4 perguntas antes de usar um loop

Vídeos importantes
https://www.youtube.com/watch?v=gK1atE0ssfg
https://www.youtube.com/watch?v=dLs-Pbn8stU
https://youtu.be/YFDp-smGYqQ

Links do vídeo
https://agent-skills.techleads.club/tlc-spec-driven/
https://bun.com/blog/bun-in-rust
https://github.com/tech-leads-club/nj-mmo
https://link.excalidraw.com/l/7V6DWtFSy3p/9uZyGFkKjpP