Loop Engineering: Stop Prompting Your Agents (Real Examples)
Elie Steinbock · 2026-06-09 · 17м 22с · 17 906 просмотров · YouTube ↗
Топики: ai-loop-engineering
🎧 Аудио
📝 Summary
model=deepseek-v4-flash · prompt=summary-v7 · 6 312→2 561 tokens · 2026-07-20 12:08:32
🎯 Главная суть
Loop Engineering — это переход от ручного написания промптов к проектированию автоматических циклов, в которых LLM-агенты сами запускают друг друга, собирают обратную связь, вносят изменения и повторяют процесс без участия человека. Вместо того чтобы каждый раз давать агенту задание, проектируется система, которая сама решает, что делать, когда и как.
Что такое Loop Engineering и почему промпты уходят в прошлое
Главная идея: твоя задача — не писать промпты для агентов, а проектировать циклы, которые их вызывают. Питер Штейнберг, создатель OpenClaw, выразил это так: «Я больше не промпчу агентов — у меня есть циклы, которые промптят агентов». Борис Черный из Anthropic вторит: «Моя работа — писать циклы». Это не означает, что промпты исчезают — они просто переходят в структуру системы. Человек настраивает оркестратор один раз, а дальше агент сам запускается по расписанию, собирает данные, принимает решения и выполняет действия. Получается замкнутый контур, который может работать автономно.
PMF Loop — автопилот для поиска product-market fit
Если представить бизнес как непрерывный процесс, то PMF loop (цикл поиска соответствия продукта рынку) выглядит так: агент строит продукт → привлекает пользователей → анализирует логи, аналитику, ошибки → по обратной связи вносит улучшения → снова привлекает пользователей. Этот цикл может запускаться, например, раз в сутки через cron и выполнять все шаги без участия основателя. В идеале бизнес сам находит product-market fit, а человеку остаётся только платить за токены и заботиться о себе — так хоть и с иронией, но описывают будущее loop engineering.
Пять ключевых компонентов инженерной системы циклов
Эдди Османи выделил пять частей, которые делают loop engineering работоспособным:
- Автоматизация — система срабатывает по расписанию или по событию, самостоятельно проводит discovery и triage. Например, агент каждый день читает обсуждения в Discord, Slack или issues в Linear, собирает фича-реквесты и баги.
- Work trees — копии репозитория, которые позволяют нескольким агентам работать параллельно на разных ветках, не мешая друг другу. Без work trees два агента на одной ветке быстро создают хаос.
- Навыки (skills) — файлы вроде
agents.md,skills.md, в которые записано знание проекта, чтобы агент не гадал. Это снижает количество повторяющихся ошибок. - Плагины и коннекторы — MCP или CLI-инструменты, дающие агенту доступ к базе данных, логам, аналитике, Discord, Slack. Без них агент слеп.
- Суб-агенты — отдельные экземпляры LLM со свежим контекстом, которые проверяют работу основного агента. Один пишет код, другой его рецензирует. Поскольку LLM склонна считать свой код хорошим, рецензент в новом контексте замечает проблемы, которые автор пропустил. Можно запускать сотни суб-агентов в параллели.
Отдельно выделяется память: маркдаун-файл или Linear-доска, хранящие список сделанного и предстоящего. Модель забывает всё между запусками, поэтому память должна лежать на диске, а не в контексте.
Как устроены реальные loops: OpenClaw и auto-review
Питер Штейнберг тратит около $1,3 млн в месяц на токены — для него это эквивалент команды из сотни агентов. Он фактически один управляет OpenClaw (при этом недавно добавил одного человека ревьювера). В репозитории сейчас 3700 открытых pull request и 4200 issues, за всё время слито более 92 000 PR. Основной цикл: просмотреть очередной PR, проверить, можно ли его смержить, и если да — смержить. Для этого используется навык авторевью (auto-review), который проводит структурированную проверку кода. Этот навык можно скопировать в свой стек и адаптировать: например, попросить AI каждый день сканировать Reddit и GitHub на тренды и автоматически применять лучшие практики к своему репозиторию — получится самоулучшающийся проект.
Примеры циклов, которые можно собрать уже сегодня
Стандартный цикл «фича из Slack»: кто-то пишет предложение в Slack → агент создаёт PR → оправляет уведомление в Slack. Запускается ежедневно или по событию. Внутри самого PR может работать суб-цикл: ревью-боты оставляют замечания на GitHub, агент вносит правки, пушит, снова получает ревью — и так до принятия.
Цикл по ошибкам: агент каждый день смотрит Sentry или Axiom-логи, находит проблему, создаёт фикс и PR.
Eval-цикл (пример Wilson Wilson с Fern Desk): агент тестирует свои же способности — запускает eval (например, оценивает качество документации). Ставится цель: «улучшить промпты и инструменты, пока оценка не станет 90%». Команда /goal (например, в Claude Code) запускает цикл: тест → 84% → фикс → 86% → фикс → 90% → остановка. Это позволяет не только улучшать агента, но и выбирать более дешёвую модель (Kimi K2.6 за 98% проходимости против дорогой).
Ограничения: стоимость и верификация
Loop engineering не для всех: Питер Штейнберг и Борис Черный работают в крупных AI-лабораториях с неограниченным доступом к токенам. Обычная компания не может позволить себе $1,3 млн в месяц. Однако человеческий труд всё равно дороже компьютерного, так что даже при умеренных бюджетах циклы окупаются. Критический момент — верификация. Автоматический мерж возможен только для низкорисковых изменений (например, затрагивающих только определённые части репозитория) и после двойной проверки суб-агентами. Из-за комплаенса и безопасности в большинстве бизнесов агент может дойти до стадии готового PR, но решение о слиянии принимает человек.
📜 Transcript
en · 3 856 слов · 45 сегментов · clean
Показать текст транскрипта
hey so there's been a lot of talk about loop engineering a new hype buzzword what is it in today's video we're going to go deep into what loop engineering is we're going to look at a few different takes and i'm going to give you some real world examples of how you can be doing loop engineering if you're a prompt engineer i'm sorry to let you know we've moved on from there we went through context engineering harness engineering and today we have loop engineering so let's get into it we have this tweet from dimitro in 2026 you don't prompt anymore your software should be able to build itself and achieve product market fit on its own your only job should be to find money to pay for tokens and take care of yourself and if we go into the comment section we find a very important discussion and we see that he was in fact joking but in principle please share so here we're doing it I said I'm gonna quote it in a video. It's a joke but there are some key concepts behind loop engineering here. Firstly he's making fun of this transition how every month there's a new type of engineering and for some reason we like to go back to loops. We also had a loop type a few months ago when the Ralph loops came out. But this also gives us quite a good idea of what loops actually are. Your software should be able to build itself and achieve product market fit on its own. So let's just think about that for a second. What if your agents could actually go and do that? I run a business called Inbox Zero. You should definitely go try it out. It's open source on GitHub and you can also sign up for $20 a month. Now that business, I'm trying to grow it every day. I need to do marketing. I need to do product. I need to do sales. There's a whole bunch of stuff I need to handle. Every morning I need to wake up and ask myself, what can I do today to improve the product and the business? And if you were to look at me as the agent running my business, that's the loop I run continuously. Every day I wake up trying to further achieve these goals. And the idea behind loop engineering is what if we can get an LLM agent to actually do the same thing. This might be the ultimate high level loop if you wanted to run your own business. Now the first question I might ask is how do I get product market fit? So the loop would look something like this. firstly i'm going to go and build the product you don't necessarily have to start here you could just start with talking to people but let's say we can set flawed code running and get it to build a product for us great that's step one done but that doesn't mean we have product market fit so next thing we need to do is we need to get some feedback we need to get people using it so you could probably also use a loop here this would use a marketing loop loop engineering doesn't need to be just related to product but let's focus on the product side of things for now imagine we have people that are using it we look at our analytics our debug logs our error logs we give that to the llm and now it can improve the product what's working and what isn't working what do people love about the product what don't they love our next step would be to go and fix it or improve it and now the cycle continues we improve the product we see what's working and what isn't and we keep the cycle going on and on we just designed the product market fit loop agent And honestly, I would love to see you take this idea, run with it and try and build a real business around it. This really is how businesses work. There are some other loops needed, as we mentioned, a marketing loop, for example. There's a loop where you need to post on Twitter every day and post on Reddit and do YouTube videos like this to grow your business. And so you could just view your entire business as these continuous loops. Time is definitely a factor here. When starting out, it's not like you can just run this on an infinite loop and have it work. You need to wait for people to actually go and use it. This usage often takes time. It doesn't just happen in a second. And this is PMF loop engineering. Or maybe we'll make it even shorter, PMF Ellie. Ellie happens to be my name. Maybe that's why I'm doing a video on loop engineering today. Something to think about. So that's a high level idea, but let's talk about how you could actually do this with Codex, Cursor, Claudecode, whatever you're using. So this all started with Peter Steinberg's tweet. Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents. and there's also a comment by boris cherny head of claude code at anthropic he says i don't prompt claude anymore i have loops running that prompt claude and figuring out what to do my job is to write loops So these two comments on their own are actually a little bit confusing. In both cases they are actually writing some form of prompt. Over here you can see my job is to write loops. These loops are prompts or whatever the prompts build. But the point they're trying to make here, if we just go to the top of this article by Adi Osmani, loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. And so if we jump back to the PMFLE that we were talking about. this system over here you could imagine that we could encode or prompt an agent to do all these things just wake up every day at 8 a.m and go through all of this and make some minor improvement and then check again how people used it and then improve itself again we could have the business running fully autonomously and finding product market fit on its own we only had to write the prompt once or the scaffolding the orchestrator whatever you want to call it you only have to set up the system once and then it goes and does everything on its own It can run on a cron job every 24 hours, but that is the loop. So if you want to get a degree in loop engineering, what do you actually have to do? So according to Adi, there are five pieces. One is the automation. So the automation goes off on a schedule. It does discovery and triage by itself. so for example lots of ways you could put input into this loop you could add issues to linear you could have discussions on slack or on discord and all of that could be fed into the ai the ai is picking it up automatically because it's all been set up to do that from the start and every day it's just reading messages in your discord what are the feature requests what are the bugs people are complaining about and it's taking that it's fixing it and then doing the same thing over and over again until things are fully working there are some other helpful pieces i don't think these are critical to loop engineering but they are definitely helpful so work trees we've spoken about it a few times before on this channel a work tree basically makes it easier to run lots of copy of your code on one machine here you can see i have six different items in review or in progress in conductor right now and here there are two and a half thousand lines of change this one has 147 if they were all running on the same branch it would get very messy so basically work trees it copies and pastes the repo so it's as if you've cloned it twice and then each repo can be on a separate branch create its own pull request And this helps the agent perform a lot better. Here you can see I can click review and I'll have another agent spin up to review this. And this becomes very difficult if you have everything just working on the same branch because the new agent doesn't know what's changed. So work trees in my workflow at least have been critical the last half a year or so. So said more concisely, two agents working in parallel don't step on each other. Skills to write down the project knowledge the agent would otherwise just guess. again not critical but skills are obviously helpful to make an agent perform well the mistakes it keeps making put in an agents md skills md then also plugins and connectors these basically mcps or clis these can be critical for your business every single time there's an error shown in your logs you might want to pass that to the ai so you can go and fix things automatically or it can get access to your database or your postdoc analytics whatever it is or even your Discord or Slack to see what's going on there. And then sub-agents also become very important because it means you can have one main agent running and you can have another agent reviewing it. The benefit of that is that when an agent is checking itself, it's often quite kind to itself. It thinks the code it's just written is very good. But if you spin up the exact same model with... complete new context and looking over the git diff and deciding is this good or not it will often notice issues that the original agent didn't notice sub agents so one of them has the idea and a different one checks it and of course you could use many different sub agents you could have one sub agent using the browser to click around and check the change is actually working another security review sub agent you can imagine you could have hundreds of agents running in parallel checking off a task list And that's the sixth thing he actually mentions, which is the memory. A markdown file or linear board, anything that lives outside the single conversation and holds what's done and what is next. Sounds too dumb to matter, but it's the same trick every long running agent depends on. The model forgets everything between runs, so the memory has to be on disk and not in the context. The agent forgets, the repo doesn't. So one form of memory is literally just what has changed in the repo. If I can do a git diff, I have a memory of what has changed. But then another form of memory is putting it on a linear board or a markdown file that has all the tasks that need to be checked off. So we know what has been done and what hasn't been done. LLMs have a limit of around 1 million tokens today. Depending on the model, you have models with larger limits. But in short, there's always going to be some limit. And so the context is going to run out. And so this is another benefit of having multiple agents. You can start them off afresh and they can each run up to, let's say, 300,000 tokens. And you don't need to worry about context as much and so on. And obviously they can do much longer tasks than 1 million tokens. If you add up 100 agents or 300,000 tokens each, you're going to get to what, like 30 million tokens. So you can go way beyond the 1 million token limit that way. So we've spoken a lot about the different pieces. You might want to have a good looping system, but the core of it is actually just something like loop in clawed code. Or you could even have a crontask that does it. If you wanted to manage this yourself, you could do something like clawed slash plippy and sleep. and then here you put in the prompt it could also go to github in between there's lots of different things you can do but these days claude code has it built in if you do sloop one minute check over my repo if there are any issues every one minute it's going to go and check over the repo and see if there are any issues and goal does something similar to that where it also have review agents slash goal is what you do in claude code for that If you've seen Enclawed Routines or the Automations tab in Codex, then that's another form of how you get an agent to keep running on a loop or on a schedule. And going back to Peter Steinberger, he is the founder of Enclaw. And in OpenClaw, one of its key features was this cron, this heartbeat that brings your OpenClaw to life every few hours and goes and does some tasks. so when peter says here's your monthly reminder he is talking about this monthly reminder from half a year ago these loops aren't a new thing but we're not always thinking in the right ways about our business and the thing with loops is really how can we do the most leverage we're one person but peter is actually spending 1.3 million dollars in tokens per month that's like an insane amount i don't even know how i'd be able to spend that number of tokens but he's constantly thinking how can i leverage the agents as much as possible he basically has an agent team the equivalent of a hundred employees based on the amounts he's paying and as a side note Peter is in a position that basically no one else is in the same is true for Boris Both of them work for major labs. Peter works at OpenAI these days, and Boris obviously works for Anthropic. Both of them can use unlimited tokens. At your company, you cannot afford to spend that amount on tokens. This doesn't mean loop engineering isn't for you, but it does mean you can't do the same crazy experiments that they're doing where they can really decide to spin up thousands of agents and not worry about the cost. It's strange for us to worry about the cost when it comes to software. It's almost always true that human labor costs way, way more than anything you can do with your computer. But when it comes to loop engineering, you actually have to be very careful. In the case of Peter Steinberg, the sort of loops he's going to be having is there are 3,700 pull requests right now on OpenClaw. There are 4,200 issues. And he's actually gone through thousands of them, merging them in, cleaning them up, seeing what the actual issues are. This would take a monumental effort for any engineering team. And he basically runs OpenClaw himself and just now one new person they brought on. And you can see we've even got commits in the last six minutes, in the last 13 minutes. There are PRs being merged the whole time. There are over 86,000 PRs or even 92,000 as you can see over here. And these are being merged in. So someone has to look at these. How does a one-person team do that? where it's using a ton of bots that are running in a loop the whole time the basic loop there is just look at the pull request see if they're good to merge or not and if you're confident you can merge them go merge them in and peter steinberg has actually tweeted this in other places so auto review is the most impactful skill i've added to my stack next to crabbox and if you want to take a look at the skill it's over here but basically run a structured code review as a closeout check on a local pr branch before commit or ship Now I'm going to give you some real world examples of loops you can be building for yourself. We just spoke about this auto review skill. Now something I could do is copy and paste this skill into codex or conductor and I could ask my AI to look over my repo and see is there anything from this auto review skill that we could add to our repo to improve it. Now that would be a prompt on its own but what if I asked my AI to do this every single day want it to run this automation and check over all of reddit and github for the latest and greatest what is trending right now and see can we take those ideas that are trending right now and they improve our repo based on those ideas that would be a self improving AI that would be a loop that could keep going it would go every day or every week whenever we want it to run now something critical to all of this is of course verification if I just let the AI run on its own and merged by itself it would likely cause a huge mess in the project so a really huge part of it is reviewing what's happening verifying it's good how much trust you have in your agent system to be able to handle all of this automatically and frankly because of compliance i don't think you can fully let the ai just do everything on its own i think in a lot of cases for most businesses you're gonna have to get it to the pull request state and then actually decide to merge or not but theoretically if you really wanted to push things to the limit and you didn't have any compliance or security risk you could just let the ai automatically merge its prs and not even look at it and actually i think that's happening somewhat with open claw itself that there's no way that peter can look through thousands of prs so the ones that they're really high confidence on that maybe only touch certain parts of the repo or low risk areas and have been checked properly by agents there he can go and merge them in so all of this is loop engineering thinking about all of this and building the correct system to make it safe or to do as much of it as possible for you so a few ideas i promised first one an idea comes up in slack then you want the agent to create a pull request and then send a slack message to you where's the loop it goes and does this every day and even within the flow it's doing it might have a loop as well a loop i've been using for a long time myself is i implement a feature and create a pull request then what happens is i'll get review bots to look over things and the review bot will post things on github my agent will go and look at what's on github make the fixes push them then we'll get a new round of reviews the agent will push again and this loop will keep happening so loops like this have been done for a long time loops engineering is a new term that people are throwing around now and hyping up but the idea itself has been happening for a long time and if you look at my previous videos you'll see ideas of loops in all of them and so the core loop might be check slack discussions every day but then there'll be a sub loop that actually does something like this that implements the feature and then checks itself and fixes itself another idea for a loop is a github issue is put up or a pull request is opened the trigger for these can be lots of different things and honestly you don't even need it to be on a schedule event based might be better Another loop that you can do is look at your sentry errors every day or your axiom logs and have the AI look over what went wrong and fix it on its own. Or maybe a build broke, fix it on its own. Another great example is by Wilson Wilson. He's building Ferndesk and he has recently set up evals for his project. Evals basically check how good his agent is. He has a docs agent, but he wants to know how good is the agent at writing these docs. And so one very good reason to have evals is just to see how each model compares. So here you can see Kimi K 2.6 actually ranks first on his fern bench. And this is a really cheap model. So this is great to know that it gets a 98% pass rate because it means he can choose to use a much cheaper model and he's not just guessing. But you can go even further. You can set a goal, refine our prompts and tools until our agent scores 90% on this eval. This is a loop. What is happening when you do scroll? We have this goal at the end that we need to get 90%. So it's going to start off first running the tests, basically the evals, saying, oh, I only scored 84%. It's going to go and make a fix. You're going to see, oh, now it's 86%. It's going to go and make another fix and get all the way till 90%, and then it will end. That is the end of the loop. And that's what Skoll does for you. The very last idea, just to bring this video full circle, you wake up in the morning and ask yourself, how can I improve my business today? Can an AI do the same thing? What's stopping it? This applies to marketing, sales, product, whatever you're doing, maybe even your taxes or legal stuff. What are the loops that you can be creating to better improve your product and your business? So I hope you enjoyed that video. If you did, be sure to subscribe. And also let me know in the comment section, what are some great loops that you're building yourself or have built? Is there a great idea that I missed out in this video that I should be including? Let me know below. Till next time.
⚙️ Pipeline jobs
| Stage | Status | Att. | Updated | Error |
|---|---|---|---|---|
| download | done | 2/3 | 2026-07-20 12:07:51 | |
| transcribe | done | 1/3 | 2026-07-20 12:08:04 | |
| summarize | done | 1/3 | 2026-07-20 12:08:32 | |
| embed | done | 1/3 | 2026-07-20 12:08:35 |
📄 Описание YouTube
Показать
Inbox Zero: https://getinboxzero.com (discount code LE20) Inbox Zero GitHub: https://github.com/elie222/inbox-zero ⭐ Everyone's talking about "loop engineering," but what is it actually? In this video I break down the buzzword, why Boris Cherny and Peter Steinberger say they don't prompt agents anymore, and how you can build real loops today with Claude Code, Codex, or Cursor. 0:00 - What is loop engineering? 1:40 - The product market fit loop 3:30 - Stop prompting, design loops 5:00 - The pieces of a loop system 9:00 - Running loops in Claude Code and Codex 10:10 - Peter Steinberger's token spend and OpenClaw 12:30 - Real loop ideas you can build today 16:40 - The ultimate business loop If you want the skills and patterns I use, they're in the Inbox Zero repo: https://github.com/elie222/inbox-zero ⭐ =================== My open source product, Inbox Zero: Inbox Zero organizes your inbox, drafts replies in your voice, and helps you reach inbox zero fast. Never miss an important email again. https://getinboxzero.com GitHub: https://github.com/elie222/inbox-zero ⭐ =================== Follow me on X: https://x.com/elie2222 Join the Newsletter: https://aiopensource.substack.com/ #loopengineering #claudecode #codex #cursor #aicoding #agenticcoding #openclaw #devtools #promptengineering