Loop Engineering não é Vibe Coding: é Agente com verificação
Ronnald Hawk · 2026-06-11 · 16м 12с · 9 174 просмотров · YouTube ↗
Топики: ai-loop-engineering
🎧 Аудио
📝 Summary
model=deepseek-v4-flash · prompt=summary-v7 · 6 188→1 781 tokens · 2026-07-20 11:46:35
🎯 Главная суть
Loop Engineering — это не просто «Vibe Coding», а следующий уровень абстракции: инженер создаёт структуру (граф с узлами и условными переходами), в которой LLM генерирует промпты для подзадач и критерии их проверки (рубрики), а отдельные модели выполняют задание и верифицируют результат. Вместо ручного промптинга каждого шага строится автоматический цикл, который сам решает, что делать и когда результат удовлетворителен.
Что такое Loop Engineering и почему о нём говорят
Создатели инструментов из OpenAI и Anthropic (OpenCloud и Cloud Code) утверждают: «Вы должны проектировать циклы, которые делают промпты в вашем агенте», «Моя работа — создавать циклы, а не писать промпты». За этим стоит идея: вместо того чтобы вручную генерировать запросы для каждой новой задачи, инженер строит автоматическую систему, которая сама определяет, какие подзадачи нужны, создаёт промпты для каждой из них, выполняет их и проверяет качество. Это шаг от «я пишу код для одной конкретной проблемы» к «я пишу код для целого класса проблем».
Harness Engineering — фундамент для Loop Engineering
Автор вводит понятие «Harness Engineering» (создание обвязки/инфраструктуры для агента). Harness — это окружение, в котором работают LLM: настройка контекста, инструментов, вызовов, лимитов и т.д. Ключевое отличие: Vibe Coding — лишь одно из применений Harness Engineering, но сама по себе Harness гораздо шире. Тот, кто умеет строить свою собственную обвязку, понимает паттерны работы моделей (как модель вызывает инструменты, как работает сжатие контекста, что такое скиллы) и может эффективно использовать чужие гарнитуры. Loop Engineering — это следующий уровень: улучшение цикла от первого вызова до финального ответа внутри уже созданной гарнитуры.
Как устроен loop: Planner, подзадачи, рубрики и верификатор
В примере автора loop выглядит так:
- Планировщик (Planner) получает задачу. Для этой роли используется более мощная модель (GPT 5.5). Planner разбивает задачу на до 160 подзадач.
- Для каждой подзадачи Planner генерирует динамический промпт, содержащий цель, роль, ожидаемый результат и предложенные источники.
- Критически важно: Planner также создаёт рубрику — набор критериев, которым должен удовлетворять ответ подзадачи. Рубрика передаётся следующему элементу.
- Каждая подзадача выполняется субагентом — отдельным, более слабым или специализированным LLM.
- После получения ответа субагента вступает в дело верификатор — другая LLM (обязательно другая, чтобы избежать смещения). Верификатор проверяет ответ по рубрике.
- Если ответ не проходит, верификатор формирует follow-up — указание исправить (например, «добавь таблицу Markdown с колонками»). Субагент переделывает, верификатор снова проверяет.
- Автор настроил правило: максимум три попытки. Если после трёх попыток ответ не одобрен, процесс завершается без аппрува (условие выхода задаётся разработчиком).
- Если ответ проходит рубрику (confidence высокая), цикл завершается положительно.
Такой подход позволяет автоматизировать проверку качества без участия человека на каждом шаге.
Где это применимо и где нет
Автор прямо предостерегает: для генерации production-кода такой loop не годится. Уже существовали аналоги (Ralph Loops) и не взлетели, потому что код требует строгой логики и ручной верификации инженером. Loop Engineering расцветает в корпоративных задачах, связанных с обработкой знаний: исследовательские отчёты, анализ клиентов, создание аналитики. Там, где результат — текст или структура, а не исполняемый код, автоматическая верификация по критериям работает хорошо.
Граф — новая абстракция
Автор утверждает, что граф (graph) — это основной уровень абстракции для Loop Engineering. Граф состоит из узлов (вершины) — мест, где происходит вычисление (часто с участием LLM), и рёбер с условиями перехода — которые легко сделать детерминированными. Разработчику не обязательно использовать LangGraph (хотя автор использует его), можно нарисовать граф на бумаге или реализовать иначе. Суть в том, что вы контролируете структуру (рёбра), а LLM работает только в узлах, где её гибкость нужна. Это даёт наилучшее сочетание: предсказуемость маршрута и адаптивность моделей.
Важность понимания проблемы
Без понимания задачи (какие шаги нужно выполнить, какие решения принимать) невозможно построить ни правильную гарнитуру, ни граф, ни loop. Даже для Vibe Coding нужно знать логику предметной области. Loop Engineering — это не магия, а продуманная инженерия, где человек задаёт условия перехода и критерии качества, а LLM заполняет контент.
📜 Transcript
pt · 2 865 слов · 35 сегментов · clean
Показать текст транскрипта
O criador do OpenCloud falou o seguinte, você deveria estar desenhando loops que fazem prompts no seu agente. E o criador do Cloud Code também falou o seguinte, eu não faço mais prompts no Cloud, eu tenho loops que descobrem o que tem que ser feito e o meu trabalho é criar loops. Mas o que eles estão falando aqui? É exatamente do que se trata esse vídeo. Nesse vídeo eu vou abrir a caixa do loop, você vai entender o que é hype e o que de fato é útil. e vai conseguir tirar proveito disso a partir de hoje. Eu sou o Hulk, eu ajudo indivíduos e empresas a colocarem soluções de AI em produção e lucrarem com isso. Comunidade e Hulk Empresas, ambos os links estão na descrição. Bora pro trabalho. Vamos lá, o que tá acontecendo? Se você não conhece esses dois caras, como eu disse na introdução, um trabalha hoje na OpenAI e outro trabalha na Antropik. Ambos trabalham em empresas que vendem tokens. E o que eles têm que você não tem, provavelmente? Você não tem tokens infinitos. Guarda essa mensagem aí, tá? E a segunda coisa. Ambos aqui estão falando sobre criar soluções. O que seria? Não importa o que você está criando de software, de size, etc, etc. Eles estão falando nesse perfil aqui, tá? Então guarda essa informação pra gente prosseguir aqui. No vídeo passado, eu falei como eu recriei o padrão de Dynamic Workflows usando o LangGraph, tá? E é basicamente... Esses padrões aqui, a gente viu no vídeo lá, se você tem interesse vai no vídeo, se você não viu ainda. É um vídeo que provavelmente está à frente do tempo. E o padrão que eu percebi ao longo do caminho é, quem cria a própria Harness é um VibeCoder superior a quem não cria Harness. E o que seria criar Harness? Seria criar soluções de IA. Eu já mostrei diversas aqui, por exemplo, aquela Harness do WhatsApp é algo público que eu botei aqui. Eu expliquei o método, expliquei tudo o que está feito. E por que você fica melhor quando você aprende a fazer harness, você fica melhor no VibeCode? Porque você entende intrinsecamente esses padrões e você resolve problemas. Então, você cria em cima desses padrões e usa esses padrões implementados por outras pessoas, muitas vezes o Cloud, muitas vezes o Codex, para resolver o teu problema de gerar o código. Então, é um ganha-ganha. Então, se você aprende a fazer harness, você, obviamente, aprende a fazer VibeCode. E pensando nisso, muita gente me perguntou... A gente lançou um curso de VibeCoding para os membros da comunidade, baseado exatamente nessas ideias. O curso não é voltado para Cloud Code nem Codex. A gente, na verdade, lá usa Open Code, mas você pode usar qualquer ferramenta. E a ideia é mostrar um workflow. E por que eu estou mostrando isso? Tudo que eu vou mostrar a partir de agora sobre Loop, na verdade, ele é uma espécie de workflow, só que de maneira automática. E o nosso curso lá, ele percorre exatamente esse caminho do workflow. e você vai poder eventualmente automatizá-lo. E essa é a ideia do loop, tá? Então você tem um workflow de desenvolvimento que você pode automatizar e é isso que eles falam sobre o loop. Eu vou mostrar exemplos práticos pra você a partir de agora. Muito bem. Vamos quebrar o termo em pequenos pedacinhos aqui, tá? Prompt Engineering. Vamos pegar o histórico, né? Pra gente não se perder. Melhora uma chamada, então você já sabe, tá? Engineering de contexto, né? Você já sabe que melhora o contexto. Isso é muito importante. Isso a gente continua fazendo. Isso é importante. Assim como Prompt Engineering. é importante ainda, você precisa fazer um prompt aqui e ali, tá? Harness Engineering, você melhora o ambiente como um todo, tem muitos vídeos meus aqui sobre como fazer e todos esses subtópicos relacionados, esse por si só já é uma indústria enorme e aqui na internet, pelo que eu noto, é diferente do mundo real, as pessoas associam apenas Harness Engineering a Vibe Coding, mas Harness Engineering é muito maior do que Vibe Coding, se você aprende a criar uma Harness, como eu disse, você de fato consegue fazer um bom vibe coding porque você entende os padrões, então você consegue usar a harness dos outros sem precisar reinventar a roda, você sabe como o modelo funciona, como ele chama as ferramentas, qual o limite de contexto, para que a compactação serve, o que é uma skill, etc, etc, isso é um conhecimento que vira parte da sua natureza, tá? E aí os caras vieram com essa ideia do Loop Engineering, que é basicamente melhorar o ciclo todo da harness, digamos assim. Todo ciclo que acontece desde a primeira chamada até a resposta final que você recebe. E essa ideia de você não faz o prompt no agente, você desenha o sistema que faz, é exatamente o que eu mostrei semana passada. Talvez vocês não entenderam, talvez vocês não tiveram a oportunidade de ver o vídeo e não viram a fundo. E eu quero mostrar exatamente ele para vocês. Esse aqui é um loop. Como que é um loop? O que está acontecendo aqui? uma estrutura, o loop não acontece milagrosamente, você tem uma estrutura e dentro dessa estrutura você vai ter um ou mais loops. E o que eu faço aqui? O que acontece? Eu dou uma pergunta para ele, para o meu agente, e é exatamente isso que esses caras estão falando. Eles estão falando o seguinte, o meu agente descobre o que tem que ser feito, cria os prompts, só que tem um detalhe ali que eles não falaram. Não adianta você, por exemplo, usar um agente para criar um código ou para fazer uma tarefa e não verificar se essa tarefa foi bem executada, correto? Então, se você está fazendo o VibeCode, se você fizer o curso lá, por exemplo, você vai ver que a gente tem uma fase de verificação do código gerado. Show de bola. Só que o que a gente faz nesse loop é a gente cria um prompt dinamicamente. Então, eu não vou mais criar o prompt para todas as tarefas. Eu vou criar uma estrutura capaz de gerar prompts infinitos para diferentes agentes, subagentes, infinitamente. Só que ele também vai gerar uma rúbrica. E esse é um tópico muito importante. O que seria a rúbrica? Você vai ver já já. Vem comigo aqui. Então, o que eu fiz? Eu fiz uma pergunta. O meu agente vai descobrir o que é. Ele está fazendo um racional aqui, o plano. Você está vendo tudo exatamente como o meu loop pensa. É exatamente isso aqui. É uma harness que tem um loop. E essa harness aqui, e esse aqui é o curioso, tá? Ela está sendo acionada à medida que eu mando uma pergunta. Mas nada impede de eu fazer essa harness aqui, rodar a cada uma hora, verificar alguma coisa automaticamente e fazer alguma coisa por mim. É isso que está acontecendo na indústria lá fora e é isso que a gente tem o poder de fazer hoje. O futuro já é agora. Só que a distância, né? entre a informação útil de fato e o mercado é lento, muito porque vários desses conteúdos são de origem inglesa, da língua, requer conhecimento técnico alto e existe um gap entre uma coisa e outra, obviamente aqui no Brasil, você sabe disso. Então, beleza, ele entende a entrada e o que ele vai fazer? Ele vai criar subtarefas. No meu caso aqui, eu mostrei lá que o meu agente poderia fazer até 160 subtarefas ao mesmo tempo, tá? E aí, mais uma vez que eu te digo, não precisaria ser eu prontando ali a entrada já, tá? Ele poderia ler dados, por exemplo, do meu banco de dados, todo dia lá, à meia-noite, ir lá e verificar se a venda diminuiu, por exemplo, tá? Ele verificou que a venda diminuiu. Ele aciona, ele vai mandar esses dados aqui pro meu workflow. O meu workflow vai olhar aquele dado e falar assim, ah, tá, de repente eu tenho que fazer X coisa. E ele vai montar... a própria Harness dinamicamente para resolver aquele problema. Nós estamos saindo da ideia de eu crio código para resolver um problema para eu crio código para resolver uma série de problemas nesta categoria. Você consegue entender? Esse é o nível de abstração. Nós estamos mudando de abstração. Nós estamos resolvendo o problema em outro nível. Ok? É isso que a engenharia está se ocupando agora. Show de bola! Então, o que meu Planner faz? E se você lembra lá no meu vídeo anterior, eu usei o GPT 5.5 para fazer o Planner. Por quê? Porque essa é uma atividade que requer um modelo melhor. Correto? Então, beleza. E o que esse Planner faz? Ele vai gerar o meu Prompt, tá? Para este subagente. Então, ele vai gerar o Prompt para todas as subtarefas que ele acredita que sejam necessárias. Tudo isso aqui que você está vendo, objetivo, papel, resultado esperado... e fontes sugeridas vai entrar no prompt do meu subagente. Então, ao invés de eu fazer essa requisição ao subagente, existe uma LLM entendendo o problema e mandando essa tarefa para um subagente. E aí, o que tem aqui de interessante também é que ele cria uma rúbrica. E o que seria essa rúbrica? Ele vai dizer, tá, agente, faça isso, mas vai dizer, essa tarefa só está cumprida se você cumprir essa, essa, essa, essa exigência. Show de bola? Show de bola. Ok. Então você já viu como é que o Planner funciona, o que ele fez. Agora a gente vai ver o subagente. Como que isso funciona na prática? O que o subagente faz? O subagente vai fazer o que ele tem que fazer lá, vai achar a resposta. E a parte interessante aqui é exatamente essa dinâmica do subagente e o verificador do subagente. O que seria isso? É uma outra LLM. E quando eu digo outra, é literalmente outra, é um outro modelo. Por que você tem que fazer isso com um outro modelo? Porque você não pode ter um bias, né? O mesmo viés. Então, você usa um modelo para gerar resposta e um outro modelo para verificar a resposta gerada. Esse segundo modelo aqui recebe exatamente aquela rúbrica. Ele sabe qual é a rúbrica. E ele vai olhar a saída desse agente anterior, correto? E vai falar, ah, tá bom, a saída está legal. Pode passar. Não, a saída está ruim. E quando a saída estiver ruim, olha o que ele vai fazer. Ele vai fazer um follow-up, que seria reescreva o relatório incluindo uma tabela markdown com colunas. Você entende o que a gente está fazendo? A gente cria uma estrutura que vai delegar as subtarefas e vai definir qual é o critério de aprovação. Obviamente... Isso é excelente para fazer código? Eu acredito que não. Já existe o Ralph Loops há um tempo e não foi para frente exatamente porque tinha esse problema de você criar um monstrinho, você deixava lá rodando. Isso aqui é muito mais sofisticado que o Ralph Loops, obviamente. Só que se você não tem token infinito e você preza pela qualidade do seu codebase, você vai querer um engenheiro por perto sempre no momento de decisão. Mas para trabalhos corporativos isso aqui é maravilhoso. para pesquisas internas, para entendimento do cliente, isso aqui é fantástico. Então você pode criar estruturas assim, hoje, sem dependência de Antropics, sem dependência de OpenAI, sem dependência de ninguém, desde que você tenha conhecimento. Beleza? Fechamos de bola. E você vê aqui que ele fez o follow-up e ele fez três tentativas. O que aconteceu? Ele veio aqui uma vez, pediu de novo, pediu de novo, pediu de novo, e ele não aprovou. O que ele fez foi não aprovar. Roland, que condição de saída é essa? Essa condição foi eu que criei, mais uma vez. A Ranez é minha. E eu defino qual é o critério de decisão. Eu poderia fazer aqui, por exemplo, se ele manda um follow-up que o primeiro modelo não gerou direito, eu poderia, se eu quisesse, já que a solução é minha, falar assim, troca o modelo e gera essa resposta com outro modelo e vamos ver a resposta. Tudo isso é possível, desde que você saiba o que você está fazendo. Show de bola? Show de bola. Vamos ver um outro exemplo aqui de um resultado do subagente. que não aconteceu isso. Então, ele fez o que ele tinha que fazer, deu a resposta dele lá, e você vê que a verificação rodou, a confiança está alta, e nesse caso não teve follow-up. Então, o meu agente gerou a resposta, fez a trefa que ele tinha que fazer, o meu verificador olhou e falou assim, não, isso aqui passou na rubrica, está tudo certo, e ele aprovou. E é basicamente isso. Então, você vê o nível de detalhe que a gente tem. Você vê aqui que o meu subagente verificador... Verifica o problema e diz qual o problema e cria o follow up. Nós estamos criando máquinas automatizadoras. É essa a beleza da coisa. É esse o novo nível de abstração. E só para você fixar essa ideia, qual é o espírito dessa abstração? Estrutura com aqueles padrões que eu falei no vídeo anterior e que eu acabei de demonstrar aqui no meu gráfico. Tem vários daqueles padrões implementados ali. Você vai ter um prompt gerado automaticamente, um ou mais, né? Então eu tenho quatro prompts sendo gerados automaticamente ali, para os meus subagentes, e eu tenho rubricas geradas dinamicamente, e eu criei uma máquina de estado, que verifica o estado de todas essas coisas e roda automaticamente, principalmente trabalhos que são de conhecimento, né? Os Knowledge Workers, o trabalho de colarinho branco, vários deles, a gente pode fazer isso, desde que a gente entenda o problema. E é importante a gente entender o problema, senão você nem vibecode vai conseguir fazer. Correto? Correto. Show de bola. Então, a minha defesa é que o grafo é o novo nível de abstração. Se você fez computação, você já viu o grafo, já viu esse G, é igual a V e E, tá? Então o grafo é igual a vértices, vírgula, arestas ali, né? O E, tá? Então você pode pensar no seguinte, os nós, né? O nosso bonequinho aqui, vamos lá, esse carinha aqui, são a computação? É onde algo acontece computacionalmente. Tem um custo computacional aqui. E aqui são as arestas de condição de fluxo. E você é quem define essas condições de fluxo. Então, quando o cara fala, o meu trabalho é construir loops, ele está construindo ou um nó de computação ou uma camada de abstração de condição de fluxo. Por quê? Você não quer deixar que a LLM decida tudo. Existem decisões que são determinísticas. E você precisa entender do problema para você fazer essas condições. Então, você muitas das vezes vai usar a computação QLM para resolver um problema num nó e o controle das arestas é feito de maneira determinística e assim a gente tem o melhor dos dois mundos usando essas abstrações com grafo. E aí você vai falar assim, Ronald, mas esses caras não usam o Lang Graph e você usa. Obviamente, você pode fazer grafo do jeito que você quiser, você pode fazer num papel. escrever um grafo. Você pode fazer uma conta matemática. Inclusive, quando a gente aprende grafo, a gente só aprende com assim. O grafo não depende de um framework. O grafo é uma ideia, é uma abstração. Então, se você quer se dar bem nesse novo mundo da tecnologia, sempre foi assim, na verdade, mas agora é a hora de entender o novo nível de abstração. O grafo é um nível de abstração. Quando eu decidi começar a usar LangGraph, eu tinha entendido essa abstração. Eu já tinha muita familiaridade com o grafo. E é por isso que eu adotei a ferramenta e parece que eu acertei na direção do mercado quando eu decidi isso, porque é um nível de abstração que a gente precisa ter o controle da estrutura e deixar a LLM trabalhar onde ela trabalha muito bem. Então, se você pretende, de fato, construir soluções para o novo mundo, para o novo mercado, e quer se juntar aos construtores, comunidade, você precisa de ajuda na tua empresa. Para entender esse processo, ou quer treinamento corporativo também, Rockport Empresas, nós temos ajudado diferentes pessoas, tem sido um prazer trabalhar com a galera que de fato tem feito, tem se movido além do hype e tem buscado construir. Quem consegue entender boa parte do que eu falei aqui, entende que a gente está saindo de uma fase da computação e de uma fase da tecnologia computacional em geral para a outra. Obviamente, LLMs têm seus riscos, têm seus problemas. As empresas que fornecem tokens têm suas próprias agendas, mas a tecnologia está aí e ela não vai embora. Adapte-se ou saia do jogo. Então, espero que você tenha curtido. Abraço e até a próxima.
⚙️ Pipeline jobs
| Stage | Status | Att. | Updated | Error |
|---|---|---|---|---|
| download | done | 1/3 | 2026-07-20 11:46:00 | |
| transcribe | done | 1/3 | 2026-07-20 11:46:11 | |
| summarize | done | 1/3 | 2026-07-20 11:46:35 | |
| embed | done | 1/3 | 2026-07-20 11:46:38 |
📄 Описание YouTube
Показать
––– Recursos & Educação ––– Comunidade (Engenharia de IA de verdade) https://www.rhawk.pro/comunidade ––– Serviços ––– https://www.rhawk.pro/empresas ––– Descrição ––– Loop Engineering virou o novo termo do momento entre pessoas construindo agentes com Claude Code, Codex e outras ferramentas de IA. Mas Loop Engineering não é simplesmente vibe coding, nem é deixar um agente rodando solto até “resolver”. Neste vídeo, eu abro a caixa do loop e mostro o que realmente importa: como construir uma estrutura onde agentes recebem prompts gerados dinamicamente, executam tarefas específicas, passam por verificação, recebem follow-up quando falham e só avançam quando cumprem uma rubrica. A ideia central é simples: o próximo nível não é trocar de modelo toda semana. É desenhar grafos, harnesses e loops que controlam como os modelos trabalham. Você vai entender por que prompt, contexto e harness continuam importantes, mas por que o ponto de alavancagem está mudando para estruturas que conseguem gerar tarefas, criar rubricas, verificar resultados e decidir quando parar. Neste vídeo, você vai ver: - O que é Loop Engineering na prática - Por que Loop Engineering não é vibe coding - A diferença entre prompt, contexto, harness e loop - Por que criar harness melhora seu uso de Codex, Claude Code e outras ferramentas - Como um planner pode gerar prompts dinamicamente - Como subagentes recebem papel, objetivo, fontes e resultado esperado - O que é uma rubrica e por que ela muda a qualidade do agente - Como um verifier avalia a resposta de outro agente - Como funciona retry, follow-up e critério de saída - Por que o grafo é um novo nível de abstração para IA aplicada - Quando faz sentido usar loops e quando você ainda precisa de um engenheiro no controle - Como isso se conecta com sistemas reais, empresas, pesquisa interna e trabalho de conhecimento Se você quer construir agentes de IA, automações inteligentes, sistemas com LLMs, harnesses, workflows com verificação e soluções reais de IA aplicada, este vídeo mostra uma mudança importante: sair do prompt manual e começar a desenhar estruturas que fazem o trabalho com mais controle. ––– Playlist ––– Playlist IA: https://www.youtube.com/playlist?list=PLk6saMUFiINn0Y0CnynRthzCCC6e-juJY Playlist Negócios: https://www.youtube.com/playlist?list=PLk6saMUFiINl-TQpZjq6isCdhw8eZ7c9P ––– Capítulos ––– 00:00 Loop Engineering não é vibe coding 01:16 Harness, vibe coding e Dynamic Workflows 03:00 De prompt e contexto para loop engineering 04:36 Abrindo a caixa do loop 08:08 Planner, prompts dinâmicos e rubricas 09:15 Subagente, verifier e critério de saída 13:22 O grafo como novo nível de abstração ––– Social ––– Instagram: / rhawk.pro Linkedin: https://www.linkedin.com/in/ronnald-hawk/ #LoopEngineering #AgentesDeIA #VibeCoding #ClaudeCode #Codex #LangGraph #AIEngineering #Harness #LLM #ContextEngineering