← все видео

Loop Engineering: The New AI Skill You Need Now

Tech with Homayoun · 2026-06-25 · 9м 58с · 4 433 просмотров · YouTube ↗

Топики: ai-loop-engineering

🎧 Аудио

📝 Summary

model=deepseek-v4-flash · prompt=summary-v7 · 3 730→2 105 tokens · 2026-07-20 11:44:52

🎯 Главная суть

Традиционная работа с AI-агентами (написать промпт → получить результат → проверить → снова промпт) перестаёт быть нормой. Вместо того чтобы быть звеном в этом цикле, человек теперь проектирует автоматические петли (loops) — системы, которые сами запускают агентов, проверяют результаты, запоминают состояние и итерируют до достижения цели. Это и есть loop engineering: замена себя как человека-промптера на код, который управляет агентами.

🔁 От промптинга к проектированию петли

Раньше процесс выглядел так: ты пишешь запрос, даёшь контекст, читаешь ответ, решаешь, хорош ли он, и задаёшь следующий шаг. Все эти шаги проходят через тебя, поэтому скорость лимитирована твоим физическим присутствием. Борис Черни (глава Cloud Code в Anthropic) сказал: «Я больше не промпчу Claude. У меня работают петли, которые сами промптят и решают, что делать. Моя работа — писать эти петли». Питер Штайнбергер (разработчик OpenClass) повторил: «Ты не должен промптить агента. Ты должен проектировать петли, которые промптят твоих агентов». Теперь петля — не инструмент, а самостоятельная система с целью, правилами остановки и памятью.

🧩 Пять компонентов петли

  1. Автоматизация — сердце петли. Задаёшь промпт, проект и расписание (каждое утро, каждый час). Петля запускается сама, делает discovery и triage. То, что нашло что-то важное, приходит к тебе; пустые прогоны архивируются. В Cloud Code используется /loop (повтор по расписанию) и /goal (повтор до выполнения условия, например «все тесты в папке пройдены и линт чист»). После каждого шага отдельная маленькая модель проверяет, достигнута ли цель.
  2. Work tree — разделение рабочих директорий через git work tree. Без этого два агента, редактирующие один файл, создадут такой же хаос, как два инженера без согласования. Каждый агент работает в изолированной копии.
  3. Skills — папка с файлом, где раз и навсегда записаны соглашения проекта, шаги сборки, правила. Агент читает этот файл при каждом запуске, чтобы не стартовать с нуля и не угадывать твои намерения.
  4. Плагины и коннекторы — позволяют петле проникать в твои инструменты: читать трекер задач, делать запрос к API базы, дёргать staging API или писать в Slack. Без них агент скажет «я бы сделал, если бы имел доступ», и петля не завершит начатое.
  5. Sub-агенты — самый мощный элемент: разделить агента, который пишет код, и агента, который проверяет код. Модель-писатель слишком снисходительна к своей работе. Второй агент (иногда другая модель) получает инструкцию «считай, что работа сломана, найди проблему». Именно внутри петли это критично, потому что петля работает, пока ты не смотришь.

🧠 Память — шестой элемент

Модель забывает всё между прогонами. Файл памяти (markdown, доска и т.п.) живёт на диске, вне контекстного окна. В него записывается, что сделано, что не получилось, что ещё нужно. Завтрашний запуск читает этот файл и продолжает ровно с того места, где остановился позавчера. Агенты забывают — репозиторий помнит.

⚙️ Как это работает в сборе

Каждое утро автоматизация запускается в репозитории. Промпт вызывает skill, который читает вчерашние упавшие тесты, открытые issues, последние коммиты и записывает всё в файл памяти. Для каждой задачи петля открывает изолированный work tree, отправляет одного sub-агента писать фикс, второго — ревьюить его по правилам skills и существующим тестам. Коннекторы открывают pull request, обновляют тикеты и, если что-то не удалось, оставляют задачу в инбоксе для человека. Ты спроектировал это один раз — и ни один из шагов не потребовал твоего ручного промпта.

⚠️ Три острых риска

  1. Верификация остаётся на тебе. Петля, работающая без присмотра, — это петля, совершающая ошибки без присмотра. Кто-то должен проверять итог.
  2. Понимание кода «гниёт». Чем быстрее петля меняет код, который ты не писал, тем больше разрыв между тем, что существует, и тем, что ты реально понимаешь. Если не следить, теряешь контекст.
  3. Когнитивная капитуляция. Одна и та же петля даёт противоположные результаты: один инженер использует её, чтобы двигаться быстрее в работе, которую он понимает; другой — чтобы вообще не вникать в задачу. Петля не знает разницы, но ты знаешь. Именно поэтому loop engineering сложнее, чем промптинг: точка приложения усилий сместилась, но работа не стала легче.

🛠️ Баланс и позиция инженера

Loop engineering не отменяет прямой разговор с агентами. Иногда обычный промптинг всё ещё работает — и это нормально. Главное — строить петли, оставаясь инженером, а не просто оператором, который нажимает «запустить». Какой бы инструмент ты ни создал, делай это так, как будто собираешься остаться автором и ответственным за систему, а не передавать управление чёрному ящику.

📜 Transcript

en · 1 637 слов · 22 сегментов · clean

Показать текст транскрипта
for about two years here's how you got anything out of your coding agents you wrote a good prompt you gave it enough context you typed the thing then you read what came back and then you type the next thing the agent is a tool and you are holding it entire time one turn after another that part is kind of over or at least the people building these tools think it's going to be because if you look closely at what you are doing type read type check You're not really the user of the loop. You are the loop. And that's the thing that's going to change. Here's how Boris Cherny, the head of Cloud Code at Anthropic, put it. He said, I don't prompt Cloud anymore. I have loops running that prompt and figuring out what to do. My job is to write loops. Also, Peter Steinberger, the person who developed OpenClass, said, you shouldn't be prompting your coding agent anymore. You should be designing loops that... prompt your agents okay so what does any of that actually means think about what you really do all day with one of these tools you find the work you hand it to the agent you read what it gives back you decide if it's good then you pick the next thing and you will do this all over again every one of those steps runs through you you are the part connecting them which means the whole thing can only ever move as fast as you can sit there and run it by the hand so that means you're not using the loop you're stuck in it so here's the move loop engineering is replacing yourself as the person who prompts the agent you build a small system that does the task checks it writes down what's done and decides the next thing now think of it as a recursive goal you define a purpose for your ai ai iterates until it's actually complete and honestly it sounds too simple until you try to build one just before jumping to the main section guys don't forget to like this video if it's helpful for you and subscribe to my channel if you're new a loop needs five things and then one place to remember the stuff automation work tree skills plugins and connectors and lastly sub agents five moving parts on one memory let's talk about them one by one first is the automation this is the heartbeat automations are what make a loop an actual loop and not just one run you did once you give it a prompt a project and the cadence every morning every hour whatever and it goes off on its own and it does discovery and triage while you're not there the runs that find something come to you the runs that find nothing just archive themselves in cloud code you've got slash loop which reruns on a schedule and a slash goal which keeps going until a condition you wrote is actually true after every turn a separate small model checks whether you're done so the agent that throws the code isn't the one creating it you say something like run until all the tests in this specific folder is passed and the link is clean and then you walk away second is the work tree the moment you run more than one agents the files start colliding two agents writing the same file is the exact same headache as two engineers committing to the same lines and nobody talked to each other first so the solution here is the git work tree it separates working directory so one agents edit literally cannot touch the others won't check out it's the same as when you with your colleague are working on the same feature the third one is the skills a skill is how you stop re-explaining your project every single session it's just a folder with a file inside holding your conventions your build steps and rules a skill is something that it's written down one time where the agent reads it on every run because here's what happened we tell it an agent starts every session cold and it feel any hole in your intent with a confident guess the first one is plugins and connectors a loop that can only see the file system is a tiny loop connectors let the agent reach into the tools you already used such as read your issue tracker query a database hit a staging rpi or drop a message in slack this is the main difference between an agent that says here's the fix with a loop that opens the pr links the related tickets or message in the slack when everything is done the connectors are the actual reason that loop can work inside your environment without connectors just your agent gonna tell you that if i had these connections i would be able to do this so without them the loop cannot finish what is started the fifth one is the most useful one by far sub agents a single best structural move in a loop is a splitting the one who writes the code with the one who checks the code because the model that wrote the code is way too nice creating its own homework so you bring in a second agent with different instructions sometimes a completely different model and you tell it assume that work is broken and go and find the problem and the reason that this matter is specifically inside the loop is that the loop runs while you're not watching a verifier you actually trust is the only reason you can walk away something that is interesting is that the architecture we are seeing here is the same as a reflector agent that we used to see around two years ago In that architecture, we had an agent that was generating something and a reflector that was trying to fix the bug and improving the output of the first agent. And this was a loop around like n times. After that, the output was going to be generated to us or to user. The big gap in that architecture was that there was no specific goal and there was no specific rule. Now we know what's the goal. and we define that for the agent we have the instruction and as long as that specific of accuracy or the goal has not been reached this loop is going to be like active until the agent reach to that accuracy we are expected this is the big difference and a big improvement in the last two years and finally the sixth thing is the memory this one sounds too dumb to matters but it's the spine of the whole loop it's a markdown file or a board like anything that lives outside of the single conversation and holds what's done and what's next model forgets everything between rods so the memory has to live on the disk not in the context window tomorrow's run read the file and picks up exactly where two days stop the agents forget but the repo doesn't So let's put it together because the pieces only really click when you see them run as one thing. An automation fires every morning on your repo. Its prompts calls a skill that reads yesterday failed tests. The open issues, the recent commits, and it writes all of them into a memory file. For each thing, the loop opens an isolated work tree and sends one subagent to draft the fix. a second sub agents review that draft against your skills and your existing tests connectors open the pull requests and update the tickets and anything the loop can't handle it leaves in an inbox for you the memory file is the spine it remembers what got tried what passed what's still open so tomorrow morning it picks up where today lifts up now look at what you actually did there you designed it one time you didn't prompt a single one of those steps now the honest part because i'm not here to sell you anything the loop changes the work it does not delete you from it and three problems actually get sharper as the loop gets better the first one is that the verification is still on you a loop running an attendant is also a loop making mistakes unattended. The second one is that your understanding rots if you let it. The faster the loop shifts the code you didn't write, the bigger would be the gap between what exists and what you actually understand. And the third one, which is the most dangerous one is the cognitive surrender. A loop would be a cure when you design it with a clear judgment, and it would be a headache when you design it just to avoid thinking. So it's the same action, but it would be opposite result. And that's the strange thing about loops. Two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understandably. The other uses it to avoid understanding the work at all. The loop doesn't know the difference, but you do. And that's the reason why loop engineering is harder than prompt engineering, not easier. The work didn't get easier. The leverage point just moved. so go ahead and build your loops but don't throw away the prompting either talking to your agents directly still works it's about balance and whatever you build build it like someone who intends to stay the engineer not just the person who pressed the go build the loops and stay engineer

⚙️ Pipeline jobs

StageStatusAtt.UpdatedError
download done 1/3 2026-07-20 11:44:21
transcribe done 1/3 2026-07-20 11:44:28
summarize done 1/3 2026-07-20 11:44:52
embed done 1/3 2026-07-20 11:44:54

📄 Описание YouTube

Показать
Loop engineering is quietly replacing prompt engineering and most developers haven't noticed yet.

Instead of prompting your AI coding agent one turn at a time, you build a loop that prompts it for you. The head of Claude Code says he doesn't write prompts anymore — his job is to write loops. In this video I break down what loop engineering actually is, the five building blocks behind it, why Claude Code and Codex already ship all of them, and how to build your first self-running agent loop today. No hype — including where the whole idea falls apart if you're not careful.

Chapters :
[00:00] Intro: The End of "Type, Read, Type"
[01:59] The Six Main Parts of a Loop
[02:21] 1. Automations (The Heartbeat)
[03:14] 2. Worktrees (Parallel Without Chaos)
[03:41] 3. Skills (Stop Re-explaining)
[04:10] 4. Plugins & Connectors (Touch Your Real Tools)
[04:58] 5. Sub-agents (Maker / Checker)
[06:39] 6. Memory (The Spine)
[07:15] Putting It All Together (One Loop Looks Like...)
[08:23] The Risks: Verification, Comprehension Debt, & Cognitive Surrender


🔁 What you'll learn
- Loop engineering vs prompt engineering — what actually changed
- The five building blocks of an agent loop: automations, worktrees, skills, connectors, sub-agents
- Why memory on disk is the spine of every long-running agent
- The maker/checker pattern and why the verifier matters most
- A full morning agent loop, step by step
- The real risks: unverified output, comprehension debt, and cognitive surrender

This is a grounded, practitioner-level explainer on agentic coding, AI agents, and autonomous coding workflows with Claude Code and Codex — for developers who want the real mechanics, not the hype.


🔔 Subscribe to my channel for no-hype breakdowns of AI engineering, RAG, and agentic systems.

#LoopEngineering #AIAgents #ClaudeCode #AgenticAI #PromptEngineering #AICoding #SoftwareEngineering #LLM #Codex #DeveloperTools