{
  "video_id": "F4a8aMLb678",
  "channel_slug": "matthew_berman",
  "channel_handle": "matthew_berman",
  "title": "7 INSANE loops you need to try right now",
  "duration_seconds": 972.0,
  "url": "https://www.youtube.com/watch?v=F4a8aMLb678",
  "upload_date": "",
  "transcript": "Loops are emerging as the single biggest\nunlock for people building software with\nartificial intelligence right now. But\nmost people don't even know what loops\nare. And so today, I'm going to tell you\nwhat loops are. I'm going to show you\nwhy they're valuable. And then I'm\nactually going to give you many specific\nuse cases that you can use loops for\ntoday. So what is a loop? A loop is a\nway to allow your AI coding agent to\nwork autonomously towards a specified\ngoal. The most important thing about\nloops is that it removes humans that\nallows the agent to work much more\nquickly towards this defined goal. And\nif it sounds very theoretical, I am\ngoing to break it down. So what is a\nloop more specifically? Well, you need\ntwo things. You need a trigger and you\nneed a goal. With those two things, you\ncan complete the loop. A trigger is what\nkicks off the loop. And there are three\nways to kick off a loop. One, you can do\nso manually. You literally tell the\nagent, go do this loop. Two is schedule.\nYou can schedule a loop to happen at a\ncertain time of day or on a repeating\nschedule. And then three, you have\nactions. You can have the loop kick off\nbased on some kind of action like\nopening a PR. Now to fully remove the\nhuman, we wouldn't want to kick\neverything off manually, but sometimes\nit is required. All right? And for the\ngoal, the goal can be basically one of\ntwo things. It can be verifiable or we\ncan use LLM as a judge. So if it's\nverifiable, it is something concrete,\nsome specific number or some way to test\nit deterministically. If it is LLM as a\njudge, that means we're giving the model\nthe ability to determine when it has\nreached the goal. Let me give you two\nexamples. So for verifiable 100% test\ncoverage in our codebase as an example,\nthat is something that we know for sure\nand we have a nice way to test against\nwhen it is true. And for LLM as a judge,\none example would be refactor until\nsatisfied. And the satisfaction just\nmeans you as the LLM get to determine\nwhen we are satisfactorily\nrefactored enough. All right, enough of\nthe theoretical. Let me actually show\nyou some examples. So, a lot of people\ntalk about loops, but they don't\nactually give concrete use cases. And I\nwanted to fix this. That is why I am\nlaunching the loop library. It is a free\nlibrary. I'm basically taking all the\nloops that I use and the ones that I see\nother people use and putting them in a\nsingle place so you can see them. You\ncan be inspired by them to create your\nown loops or you can simply copy them\nstraight from here. It's free. I'm going\nto drop the link down below. So, let's\ngo over it. This is definitely my\nfavorite loop and it's going to show you\nexactly how loops work. This is the\nsub50ms page load loop. Let me click\ninto it. And here we are. So the\nobjective of this loop is to get every\nsingle page load in my app under 50\nmilliseconds. And so that is the goal.\nIt is a very concrete well-defined goal\nwhich really makes building a loop\neasier. So what I tell it is continue\noptimizing the code for speed. After\neach significant change, measure page\nload performance across every page under\nthe same repeatable test conditions.\ncontinue until that's the loop continue\nuntil every page loads in under 50\nmilliseconds. So it is literally going\nto go through my entire application,\nevery window, every page, every modal,\nload it. If it's above 50 milliseconds,\nit's going to continuously optimize it\nuntil it gets it under 50 milliseconds.\nOnce it's done with one, it moves on to\nthe next. That's the loop. That's the\ngoal. But how do I actually do that? How\ndo I actually kick it off? Well, the\ntrigger in this case is me. I am the\nhuman and I'm going to manually kick off\nthis loop. You can certainly set it on a\nschedule and you can even trigger it on,\nlet's say, a PR open. So, every time you\nopen a new PR, you also want to make\nsure that that new PR doesn't make the\npage load over 50 milliseconds. So,\nlet's kick it off. So, we're going to\nclick copy right here. All you have to\ndo is paste it in. So I have the prompt\nright there. And then at the end or at\nthe beginning, it doesn't matter. Type\nslashgoal.\nAnd this is a feature in codeex. Claude\ncode also has a /goal feature. But as\nsoon as you have this slashgoal, it's\ntelling codeex to continue working until\nthe condition is met. The condition of\nevery page loads under 50 milliseconds.\nThat's it. You just hit go. And it might\nrun for 10 minutes. It might run for 10\nhours. it will just continue to run\nuntil it meets the goal. And so you do\nhave to keep a close eye on it if you're\nunder a token budget constraint. So here\nit is in action. I sent this as a goal.\nLook for more optimizations to make sure\nevery page loads in under 50\nmilliseconds on production. It worked\nfor nearly 50 minutes. So I'm treating\nthis as a production performance goal.\nI'll first measure the real team's page\nrequest path. And it basically, as you\ncan see here, went through every single\npage and optimized it to load under 50\nmilliseconds. Loops are the frontier of\nAI workloads. And if you want to power\nthem reliably and at production scale,\nuse the sponsor of today's video,\nDigital Ocean. If you're running\nproduction inference, you're probably\nrunning into some of these problems.\nYour inference stack is too complex to\noperate. costs are unpredictable and I'm\nspending more time managing the\ninfrastructure than actually building\nthe things to be on the infrastructure.\nAnd most teams find out the hard way\nthat the hard part of building AI\napplications is not using the model.\nIt's actually everything around the\nmodel. The operational overhead, the\nfine-tuning inference complexity, the\ncosts that become harder to predict as\nyou scale. And that's why I want to tell\nyou about Digital Ocean, the partner of\nthis video. Digital Ocean is designed to\nminimize the total cost of ownership by\ngiving teams a simpler path to\nproduction AI. They provide\ninfrastructure that is optimized for\ninference and a vertically integrated\ncore cloud that provides efficiency at\nscale. Vertically integrated is the key\nword. And with transparent usage based\npricing that makes costs easy to\npredict. So, if you want to spend less\ntime managing your infrastructure and\nactually building the thing you're\nexcited about, Digital Ocean is the way\nto go. So, go check it out. They've been\na fantastic partner. I've actually been\nusing Digital Ocean for well over a\ndecade at previous companies, so I can\nvouch for them. Go check them out. Link\ndown below. Now, back to the video.\nHere's another loop that I really like.\nThis is called the overnight docs sweep.\nEach night, review the codebase in full\nand make sure all documentation reflects\nthe latest changes from the previous\nday. update the documentation as needed,\nthen open a poll request with those\nchanges. So, what I am doing is I'm\nmaking sure we have complete\ndocumentation based on any changes we\nmay have made. This is an example of LLM\nas a judge. There's no verifiable way to\nknow if we have complete documentation\ncoverage. There may be some ways that we\ncan say, okay, as long as a piece of\ndocumentation covers this section of the\ncode, but ultimately what we're doing is\nsaying, okay, LLM, you decide. So, how\ndo we actually use this? Well, once\nagain, just hit the copy button. We're\ngoing to come into codeex. We're going\nto click this automations tab. We're\ngoing to create via chat. We're going to\ndelete this portion. I don't know why\nthey put that in there, but I want to\nset up an automation. Then, we paste in\nwhat we just copied, and then each night\nreview the codebase in full. hit go and\nlet it run and hopefully it will set up\nan automation just like this. So there\nwe go. I'll set this up as a recurring\nautomation. So first I'm loading the\nautomation tool rather than writing a\none-off note. Perfect. So this is a way\nto keep your documentation always up to\ndate. It is awesome. And by the way, I\ncreated this website with here.now. So\nshout out to here.now the partner on the\nloop library. I created it and I simply\nsaid deploy to here. Now and it was\ndone. It's so easy. Next is the\narchitecture satisfaction loop. This is\none that Peter Steinberger himself says\nhe uses often. Here we go. Refactor\nuntil you are happy with the\narchitecture. Here is the trigger and\nthe goal all in one sentence. Refactor,\nwhich is what the loop is going to do,\nuntil you are happy with the\narchitecture. Happy with the\narchitecture is the goal. This is\nanother example of LLM as a judge. We\ncan even give it more guidance on what\nhappy with the architecture means. We\ncan say be very strict about simplicity\nor make sure every single line of code\nis dry. Then after each significant\nstep, live test the system, run auto\nreview and commit. Track progress in and\nthen we give it a markdown file to track\nthe progress. This is fantastic. So it's\ntracking its loop as it's actually\nlooping. Now you can kick this off\nmanually or you can run it every night.\nSo let's say during the day you're\ndeploying a bunch of code and then every\nnight you're just making sure that it's\nrefactored, it's dry, and it looks\nreally solid. So very good way to keep\nyour codebase very clean. Next, another\none of my favorites, the logging\ncoverage loop. So let's click into it.\nBasically, what this loop is going to do\nis make sure that we have thorough\nlogging throughout our app. And there's\nanother loop that builds off of this\nthat I'm going to show you in a minute,\nwhich these two loops together, you can\nstart to see how loops can become so\npowerful. So, this says, \"Review the\nsystems logging and add missing coverage\nuntil every important path produces\nuseful tested logs.\" And again, this\njust makes sure that we have logging for\neverything. And this is going to be\nmanually kicked off. And this is going\nto be LLM as a judge because it says\nevery important path and important is\nnon-deterministic. It just means the LLM\ngets to decide what's important and what\nisn't. And by the way, if you want\nhands-on help with loops and other AI\ntopics at your company, my team is\noffering free consulting sessions. I'm\ngoing to drop a link down below. We're\nonly doing a few of these, so go apply\nif you're interested. Would love to talk\nto you. All right, so now imagine this.\nYou have full logging coverage, but what\ndo you actually do with those logs?\nWell, I have another loop for you. This\nis called the production error sweep.\nEvery single night, we're going to\nreview our production logs for errors.\nIf you find an actionable issue, trace\nit to its root cause, fix it, verify the\nfix, and open a pull request. Then, ping\nme in Slack with the findings and PR\nlink. If no actionable errors are\npresent, ping me with that result\ninstead. So we are kicking off a loop\nevery night and the loop is looking for\nevery error in the logs and we'll fix\nthem one by one with the end goal being\nno more unressed errors in the logs. So\nthat is a very concrete goal for this\nloop. All right, here's another loop.\nSomething incredibly important to any\nwebsite owner, any app owner is SEO. And\nnot only SEO, now GEO. So, here's the\nSEO GEO visibility loop. Run an SEO GEO\naudit across crawlability, indexation,\npage intent, titles, internal links,\nstructured data, source citations, and\nanswer first content. Rank the gaps. I'm\nnot going to read the whole thing. Fix\nthe highest leverage issues. Rerun the\nsame crawl. And here's the loop. Repeat\nuntil no critical technical issues\nremain. Again, you might have one issue.\nyou might have 50 issues. The point is\nwe've now kicked off a loop that fixes\nall of them until no more issues are\npresent. So, this is a really cool one\nto run, let's say, once a week. All\nright, here's one of my favorite and one\nof the most handwavy loops that I have,\nbut listen to this. This is called the\nfull product evaluation loop. Create n\nrealistic scenarios covering every major\ncapability. Before testing, define clear\nsuccess criteria and choose a consistent\nevaluation method such as past fail\nchecks or a scoring rubric. Run every\nscenario under the same conditions and\nrecord evidence for each outcome. Fix\nthe underlying cause of anything that\nthat does not meet the criteria. Rerun\nthe affected scenarios and then rerun\nthe complete test. Continue until every\nscenario meets the original quality bar.\nNow, a lot of you might be thinking,\n\"Wow, that just sounds like tests,\nright? It's just like a test suite.\nWell, kind of. But this is actually\nnon-deterministic. This is allowing the\nmodel to go through every single use\ncase in your application, in your\nproduct, figure out if it's good enough,\ndetermined by the LLM, and update it if\nnecessary. This one really does work. It\ntakes like 12 hours at times or more,\nbut it really does come up with very\ngood optimizations. Now, you can also\ncustomize this for your specific app.\nSo, for example, I'm building something\nright now that requires me asking a\nquestion of an LLM and it providing a\nreally accurate response with sources.\nSo, I tell it, come up with 100\ndifferent use cases, wide ranging use\ncases for asking the LLM questions and\njudge whether the response is good\nenough. If it's not, iterate and improve\nit. So, I could keep going, but if you\nwant to find all of the loops and any\nnew ones that I discover, go check out\nthe loop library. I'm going to drop a\nlink down below. And once again, shout\nout to here. Now for hosting the loop\nlibrary. Okay, so there are two major\ncaveats with loops that I have to tell\nyou about. Number one is it's not for\nevery problem yet. Designing a loop\nisn't always easy. Specifically, coming\nup with the goal for the loop is not\neasy. If something can be verified like\nevery page loads under 50 seconds, that\nis perfect for a loop. When we have to\nhave the AI judge, LLM is a judge\nwhether a goal is met or not. That's\nwhen it becomes a little more brittle\nbecause we are leaving taste and\njudgment up to the model. This becomes\neven more difficult when we're talking\nabout building features. I have not\nreally found a way to build features\nwith loops. You cannot say loop until we\nbuild a full permissioning system. I\nmean, you technically can, but I'm not\ndoing it because I don't know which\ndirection the AI is going to go. I don't\nknow what features it's going to build.\nI don't know when or how it's going to\ndecide which features are worthwhile\nversus which are not. So, that makes it\nnot great from day zero feature\nbuilding. Now, one example of building a\nproduct from scratch using a loop is\nsomething I did where I told the model\nas a goal to clone Excel feature parody\nand it was running for days and days and\ndays until I finally stopped it. It\nactually opened up Excel on my computer,\nused computer use, and literally clicked\nthrough and made sure that it had\nfeature par. And yes, it was running for\ndays before I finally stopped it. So, I\ndo not recommend doing that. And that\nbrings me to the second big caveat.\nLoops are very expensive. They are\nchurning through tokens autonomously\nuntil they hit the goal. Some of these\nagents might run for 10 minutes. Some of\nthem can run for days. So, for you token\nmaxers out there, loops are fantastic.\nBut for those of you who don't have an\nunlimited token budget, this might not\nwork for you today. And by the way, if\nyou like coding with loops, you might\nalso like these four open- source\nprojects that I reviewed that you can\nuse right",
  "transcript_chars": 15433,
  "ingested_at": "2026-06-19T22:31:56.520336+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": null,
    "like_count": null,
    "channel_id": null,
    "categories": null,
    "tags": null
  }
}