Every Level Of Claude Code Loop Engineering

AAI LABS
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00Loop engineering has basically become essential to how we use AI agents now and that's because
00:00:04agents can actually run on their own for way longer and just keep going. So we're going to
00:00:09show you three different loops and we've organized them into levels for your ease.
00:00:13Level one shows you the basic unit and how to use it efficiently. Level two shows you how to build
00:00:18that unit into a factory and level three finally frees up most of your time and makes it truly
00:00:23agentic. Since this video is packed with so much information, we've got timestamps below so that
00:00:28you can jump back to any moment if you ever need to come back to this video. Also, we're going to be
00:00:33using Claude Code in this video but the systems that we're going to show you will work with Codex as
00:00:38well and as for the tools, we're using warp and VS Code. They're both easy to install and you just need
00:00:43to open a single folder in both of them and start following us. Before we actually move on to how you
00:00:48implement loop engineering inside Vibe Coding, we need to explain what a loop is. So before, when you
00:00:53were building something, you were already in a loop. You gave the agent a prompt and it started
00:00:57building. Then when it was done, it basically asked you to verify it and if it was wrong, you gave the
00:01:02agent another prompt and it started building again. You were already in a loop. Now, an agent loop is
00:01:07when you remove yourself from this process and that verification part goes to the agent as well. And
00:01:12this is naturally the way that we were headed because if you think about it, building with agents isn't
00:01:17what takes up most of the time. They do that autonomously in the background. What actually requires
00:01:21your attention is checking whether the agent was successful or not. But your agent can only do the
00:01:26verification if it knows what the correct output is. That's the core part of the loop. But there are
00:01:30other parts as well. First, there's something that needs to start the loop. Then there's the loop itself.
00:01:35And at the end of each loop, there basically needs to be a verification check, which decides whether the
00:01:41agent is done or not. And that verification check needs to be decided by you. So in an agent loop,
00:01:46the piece that you keep is the piece that was always going to be yours. That's the piece that decides
00:01:50whether you turn the agent off or you need it to work more. You can't really hand this off. Now,
00:01:55you might be thinking, why are we all of a sudden moving to loop engineering and why didn't this work
00:01:59a year ago? The answer is that models couldn't really run for this long. And now with the new
00:02:04models that are coming out, they can basically work without you for hours. So here's what we're
00:02:08running all of this on. It's an appointment app for a salon. Someone comes on the site,
00:02:13picks a stylist, and then they can see that stylists open times across different days and book an
00:02:17appointment. And then there's the staff login because every salon using this is going to have a
00:02:22receptionist operating it. They approve or deny the request coming in and they manage the calendar
00:02:27for the different stylists at the salon. Right now there's a lot missing in here. There's no landing
00:02:31page and there are other important features we still need to add in. This is the Claude Code
00:02:36session where we built it. We made this loop engineering folder and inside it we asked Claude
00:02:41Code to set the project up. The app itself sits in this loop salon folder and it's just a Next.js app.
00:02:46If this is your first time hearing that, don't worry about it. You just tell the model you want
00:02:51to create a Next.js app and start building from there and it handles that for you. It's one
00:02:55of the most popular ways to build actual websites like the one we're building here. Now there are
00:03:00some things you need to have in your folder. First we have our Claude.md and all it says is to go
00:03:04look at the Agents.md. That's because we might need to run more than one agent in this repo,
00:03:09not only Claude Code. We use this file because nearly every other agent uses the instructions in
00:03:14the Agent.md as rules for what to do whenever a new session opens up. Only Claude Code uses Claude.md.
00:03:21And inside the Agents.md, we didn't really have to write anything ourselves. Then we have this file
00:03:27called design.functional.md that covers all the clickable parts of the app that the user actually
00:03:33has to work with. And the design for those comes from this file. And if you noticed,
00:03:36the app looks like Duolingo. That's because we copied Duolingo's design into it.
00:03:41Then there are some skills you should know about. The first one is Grill Me, which we used while we
00:03:45were building this first version. It keeps asking you questions until the agent is actually clear on
00:03:50what you want. There are other skills in here too, and we'll get to those later on. And you'll notice
00:03:55that this project is already built. We've done that on purpose. When you start something new,
00:03:59the first thing you make is an MVP, which is basically the roughest working version of your
00:04:04product that only does the main thing and nothing else. And you don't want to build that with a loop.
00:04:08An MVP is quick to build anyway. But to put a loop on it, you'd have to decide what done looks like
00:04:13before the agent even starts. And at that point, you don't really know where the product is going
00:04:18yet. So working that out ends up taking you longer than just building the first version yourself.
00:04:23But before we start with the level one, it would be great if you subscribe to the channel and hit
00:04:27the hype button. This small gesture of support goes a long way for us. So that brings us to level one of
00:04:33loop engineering. Here we are working with one loop which has one goal and the checking
00:04:37basically moves off you and onto the agent. And the place that we're doing this is the landing page,
00:04:42which actually sounds like the wrong place for it because a landing page is just one screen.
00:04:47The agent can basically build it one run and if anything is wrong, it can be fixed with a single
00:04:51prompt and not multiple ones. Putting a loop around a landing page would be more work than the page itself.
00:04:57But here we want a motion heavy landing page using the GSAP skill. Everything animates in,
00:05:02and if you think about it, that's the part you can't really check by looking at it once. With animations,
00:05:07there are so many places that the agent can mess up and it requires a lot of back and forth. This is
00:05:12actually a really good way to check if something needs to be looped is if it requires a lot of back
00:05:16and forth with the agent. Now, before we set one up, there's a naming thing that confuses people and
00:05:21you're going to hit it the moment you open the slash menu in Claude code. There's a command called
00:05:25loop and there's a command called goal and loop engineering is basically the goal one. The loop command
00:05:30runs a prompt on a timer, so every five minutes or every hour it fires again whether anything changed
00:05:35or not. But the goal command is the one that keeps working until the thing you asked for is actually
00:05:40done. So when we say loop engineering, we are using the goal command. The loop command is also used in
00:05:45some forms or loop engineering workflows, but we won't be using it here. The goal command itself is pretty
00:05:51simple. You type slash goal and then you write the goal that you want achieved and you also tell the
00:05:56model how to verify if it achieved it or not. Then at the end of every turn, a smaller model reads
00:06:00through the conversation and decides whether the agent needs to work on this again or if the condition
00:06:05is met or not. So to start the landing page, we use the grill me skill again and we told it we needed a
00:06:11spec file for this feature. Now, before we get into what we told it, you need to see the features
00:06:16folder inside the project. Every folder in there is one feature that the agent has to complete and
00:06:21each of those folders holds two things. There's a spec file, which is where everything about that
00:06:25feature gets written down and there's a verification folder that starts off empty and fills up while the
00:06:31agent is running the loop for that feature. Then we told it which skills to use. The first one is
00:06:35the GSAP skill and that's the one that gives you these beautifully animated landing pages, but animation
00:06:41that heavy slows the page right down. So we told it to use the optimize skill as well, which goes
00:06:45back over the page and gets the speed back without taking the animation out. We also gave it an image
00:06:50reference to follow, which was this landing page with the illustrations on it. And the last thing we
00:06:55told it was about the checking. Normally, this is the part where you and the agent go back and forth,
00:06:59where you look at the page, you tell it what's wrong and it goes and fixes it. So we told it that to
00:07:04actually check the design, it had to use the specific tool named in our global Claude.MD, which is the
00:07:11one that applies to every project on the machine instead of just this one. So what it wrote was
00:07:15both things at once. It's the spec for building the page and it's the verification checklist that gets
00:07:20run against that page. And that's why the screenshot tool from the global file ended up in there,
00:07:25because that tool takes the screenshots way faster than opening a full browser every single time.
00:07:30You can pause here and read the whole prompt if you want. It makes all of this a lot clearer.
00:07:34After that, Grill.me went into its questions and asked us a whole set of them about the landing page.
00:07:39Then we told it one more thing and this is the thing that turned the spec into a goal. We told it to write the spec
00:07:45file as a goal so we could run it with the goal command and it made a few other changes off the back
00:07:50of that, which meant that from then on, all we had to do was run the goal command and give it the landing
00:07:55pages spec file. And doing all of that again for every feature is the work you don't want to repeat.
00:08:00So we made the goal writer skill. It's got everything we just went through inside it, including that one line.
00:08:06And what it does is create the folders inside the features folder with the spec files already written as goals.
00:08:11Then it started working and it went through its first pass and then a second one where it had the
00:08:16checklist again and it was scoring itself against it over and over. After that it stopped and by then
00:08:21it had run for 38 minutes and come back with one error, which was the blinking on one of the mascots.
00:08:26So this is what it came up with. After giving it one more correction prompt, the mascots are blinking the
00:08:31way we wanted and that one mistake is the one thing the verification was never going to catch because a
00:08:36screenshot only ever catches a single moment and the gap between one blink and the next is too short for
00:08:42two screenshots to catch. Other than that, the illustrations came out really good and they're
00:08:46on brand with the Duolingo style we were going for, which is the same style that's already in the
00:08:50main app. It followed the reference closely as well and clicking book now takes you straight into the
00:08:55app so you can go and start using it. Now there's some setup that everything from here on runs on.
00:09:00There are three things this app needs that your own computer can't do on its own and you're not going to be
00:09:05operating any of them yourself, so don't worry about that part. So right now everything you've built is
00:09:10sitting in one folder on your computer and that's the only copy of it anywhere. Your computer dies or
00:09:15you delete the wrong thing and the whole project goes with it. That's the first thing that has to
00:09:20change and GitHub is what fixes it. Claude writes the project's code in your folder and GitHub takes that
00:09:25code online and keeps it in a repo, which is basically that same folder living on their site instead of
00:09:31only on your machine. The second thing is that the app doesn't remember anything yet. Real people are
00:09:36going to be using this so those bookings have to be saved somewhere otherwise somebody books an
00:09:41appointment, they refresh the page and all of it is just gone. So you need a database and the one we're
00:09:45using is Superbase. And the last thing is that nobody else can actually get to your app because it only
00:09:50runs on your own computer. So it has to be deployed, which just means it gets put somewhere on the internet
00:09:55where other people can open it and Versal is what does that. Now all you actually do on those three
00:09:59platforms is make an account and that's going on to each website and clicking login with Google.
00:10:04There's nothing to configure and nothing to set up. Everything after that goes through the agent and
00:10:08the reason that works is that all three of them have a CLI. Your agent can't click around on a website
00:10:14the way you do. So the CLI is an app for the agent to use the platform. So normally you would need to
00:10:20create a repo in GitHub and a project in Superbase and Versal but Claude can just do that using the CLIs.
00:10:26So after you've created your accounts on all three you come back to the agent and you tell it that you
00:10:31want the agent to use all three using the CLI. It's going to give you a command for each and you need
00:10:37to run those in another terminal. Your agent is already sitting in your terminal so you open up a
00:10:41second one and you paste that command in there. It's going to install the CLI for you and then to
00:10:46log in to your account. It opens a page in your browser. Then you approve it and that's the
00:10:51authentication done. From then on your agent can do everything on that platform and you never have
00:10:56to open those sites again. And you don't really have to remember any of this because we've put a
00:11:00free setup file down in the description. You just hand that file to the agent and it basically sets the
00:11:05next.js app up for you and then walks you through everything else you need to get all three of these
00:11:10connected. Also since the rules on these platforms always keep changing, these platforms have released
00:11:16skills for the agent. GitHub doesn't really need a skill. It hasn't really changed much and it still
00:11:21isn't changing so we don't have one for that. But we have this deploy to versal skill which basically
00:11:26tells the agent how to use the versal CLI to deploy your project automatically. And then we have the
00:11:31super base one and the super base best practices one. And again these auto invoke so whenever your agent
00:11:37needs to use either of these two platforms it's just going to use them on its own and you don't really
00:11:42have to do anything. And this super base database is going to get filled with data and your project is
00:11:47going to get live on versal. We'll leave the links to these skills in the description below. But before
00:11:52we move on to the next level let's have a word by our sponsor, Hedra. And it's easy to lump it in with
00:11:57agents like Manus that research something and plan out a project. Hedra does that too. The difference is
00:12:02what happens after it hands you a finished video, not a doc, not a slide deck. Think Claude meets Canva.
00:12:08You talk to it and it builds alongside you. We tried it inside a space and asked for a short promo
00:12:13video for an app. The interesting part wasn't the video, it was watching how the agent got there.
00:12:18First came a few clarifying questions, then a proposed plan. Instead of guessing, Hedra researched
00:12:23the topic itself and brought back real findings. From there, the full script landed on the canvas,
00:12:28the agent walked us through it and out came the finished promo. This one's really for anyone doing
00:12:33their marketing solo with no editor and no writer behind them. Hedra basically lets one person do
00:12:38what used to take a whole team. You can try it free at Hedra.com and use our code for 50% off
00:12:43your first month. The link and code are in the description below. So that brings us to the next
00:12:48level. Level two is called the software factory loop. In this level, you collectively plan multiple
00:12:53features and set those on a loop so that your agent can keep working overnight on a list of features and
00:12:59not stop after one feature is done. Since these loops can get very long, it needs a tracker to tell
00:13:04it if the list of features that it's given is completed or not. Its goal loop completes once
00:13:09all the features on the list have been ticked off. Now when you're planning new features,
00:13:13you shouldn't only write out what to make, you should actually make the UI. This is called a
00:13:18prototype and it's a fully clickable version of the app that doesn't actually work. There are two huge
00:13:23reasons to build a UI prototype before you start building. The first reason is that with a
00:13:28prototype, you can find out if the thing that you were imagining to build was actually the thing
00:13:33that you wanted to build. And the second reason is that this prototype becomes a way for the agent
00:13:37which is working in a loop to verify if the thing that it built is correct or not. Now in the factory,
00:13:42you have the list and the agent is running the list in a loop working on each item one by one. But how
00:13:48does it work on each individual item? When the main agent picks an item, it doesn't do the building
00:13:53itself. It hands the task to a sub-agent and the sub-agent completes the feature. But what if the
00:13:58sub-agent messes up the building and your app gets ruined? This is why the main agent makes a copy of
00:14:03the folder called a branch and the agent works on that. When the agent is finished, it doesn't verify
00:14:07itself. This brings us to another very important rule in loop engineering. The agent that does the work
00:14:13should never verify it. The verification should always go to another agent with a fresh context window.
00:14:18Since this is exactly how sub-agents work, the main agent hands the branch to an adversarial review
00:14:24agent. This means that the agent always needs to believe that there is some error in the work done.
00:14:29This is how it's useful in capturing bugs. So if there is some problem from the adversarial review
00:14:34agent, the main agent has to start the build agent again and this goes on in a loop until the feature
00:14:39has been ticked off in the list. After it completes that feature, it has to put that branch's work
00:14:44on the deployed app so that users can start using the new feature. So if you don't know,
00:14:48the main version of the code on GitHub is what's actually shown on the deployed app in Versal.
00:14:53So if the branch is merged with the main version, the feature in that branch will go to the deployed
00:14:58app. This is where your final approval comes in. When a feature is done, a pull request is made.
00:15:03A pull request is a request to merge the feature branch with the main branch. In that pull request,
00:15:08the agent will also attach screenshots. But if you want to be extra sure, you can test if the feature
00:15:13actually works on your computer in the folder by asking Claude to switch to that branch and then
00:15:18testing it. If it's correct, you can merge the pull request. So if we take a look at our skills again,
00:15:22you can see that now we have this new feature skill. When you invoke this skill, it's basically going to
00:15:27tell the agent that a folder needs to be made inside here and each folder needs to have a spec.md
00:15:33and other stuff for its verification. So as you can see, we basically defined two features here.
00:15:38One feature in which there should now be a services page with each person in the salon. And then the
00:15:43second one is that whenever a person has a session with a salon stylist, they can basically add a
00:15:48review through the receptionist, which is the admin. Now, instead of using the new feature skill here,
00:15:53we directly just use the goal writer skill. Now, all of these skills are interconnected. So if we
00:15:58don't want a feature to become a goal, if we just want to work on the feature without a loop,
00:16:03we don't use goal writer. But if we use goal writer, it's going to trigger this new feature skill and
00:16:08it's going to add the rules to make a spec file into a runnable goal as well. Now, as we already
00:16:13discussed, you should make the UI of the feature before you start implementing it. So this is why
00:16:18the new feature skill calls on the functional UI skill, which basically tells it that a folder
00:16:23called mocks should be present inside the app and that the HTML file inside that mocks folder will be
00:16:29a fully functional prototype of the whole app. And it's going to have the views for
00:16:33both the receptionist and the customer as well. Now there's only supposed to be one of these in each
00:16:37folder and the functional UI skill will only create this if it hasn't already been created. And
00:16:42obviously, since it's triggered whenever a new feature is created, inside each feature folder,
00:16:47it's going to add an HTML file as well. Now it's going to take the already cloned app and only take
00:16:53the part which the feature is changing and only show that. So for example, we have this services feature
00:16:58here. And if we open up its mock, you can see that we're going to add a full services page to the app,
00:17:04and it's going to be accessible through this button. And if you click on book now and choose a stylist,
00:17:08it's going to first ask you which service you want to take with the stylist. Now this hasn't actually been
00:17:13implemented in the app, and it wasn't implemented inside the clone, but it's implemented in this feature
00:17:19prototype. So it helps you visualize whether whatever you're making is actually what you wanted. And this also
00:17:24becomes a way that the loop can actually verify if what it's building is correct or not. So after that,
00:17:29we told it to write the two features, and it basically wrote the folders for session reviews
00:17:33and services. So this is the UI for the session reviews. And again, you can view it as both the
00:17:38customer and the receptionist. The receptionist is going to add the reviews on behalf of the customer,
00:17:43because this is how we're imagining the site works right now. This wouldn't happen on an actual site,
00:17:47but since this is a demo site, we're just coming up with features. Since we have multiple features to
00:17:52work with now, we basically need to have a list to keep track of them. This is why we have this feature
00:17:57batch skill, which basically just uses this Q markdown file, which is just a single table in
00:18:02which the features are listed. For example, right now, the loop is still going on and it's building
00:18:06the first one and the second one is still in to do, and it's just going to mark them one by one. So you
00:18:11just have to invoke the skill and tell it to add the features that you want. And then as you can see,
00:18:16it said that it was writing both of the files and it added those features in. Then once it adds them,
00:18:21it basically gives you the goal command to actually run. We changed it a little bit and we ran the queue
00:18:26file inside a goal and it was only going to stop when no row was in to do or building, meaning that
00:18:31they'd all been completed and gone to done. And basically it started working. It's still going on
00:18:36on the first feature and as we already told you, it would first use a sub-agent to actually build the
00:18:41stuff and then to check and verify its work, it would launch an adversary agent. It's still going on,
00:18:46it's been around three hours and we're going to show you the end result once it's complete. So as you can
00:18:51see, we've opened up GitHub and we have our loop salon project right here. If you can't find it,
00:18:55you can just tell the agent to give you this link and you'll be able to open it up. So right here,
00:19:00you'll see this pull request tab and after opening it, you're going to see the pull request that the
00:19:04agent has made for your review. So if you look at this, it's given us the whole summary and then it's
00:19:09actually given us the screenshots of the pages, giving us proof that the work that needed to be
00:19:13done has actually been done. Once we review all of this, we can just merge the pull request. And as
00:19:18you can see, we have the live hosted version right here. It doesn't have a domain, which is why it ends
00:19:23on Versal. But as you can see, we wanted this services feature to be added. And now if we go
00:19:27into the services feature, we get all the services that the salon offers. And if we go into the book now
00:19:33option, we can actually see that each stylist gets their own services. And before you can book them,
00:19:37you basically need to select the service. And the same thing is going to happen when we merge this
00:19:42second pull request as well. And everything that we've gone through here, we've basically explained
00:19:47it in a way that you can go and build it yourself. A skill is really just written instructions sitting
00:19:51in a file. So there isn't anything in here that you can't actually make on your own. But if you don't
00:19:56want to go through all of that, the whole repo is in AI labs pro, which is our community.
00:20:01That's basically the whole system, the way you've just seen it with every skill already sitting in
00:20:05there. So if you found value in what we do, and you want to support the channel, then that's the
00:20:10right way to do it. The link's going to be in the description. So there's only two things left for
00:20:14you to do in this whole process. Now you just need to plan the feature and you need to give the final
00:20:19permission before the feature or change is sent to your users. Neither of those things really need
00:20:24you to be at your laptop, especially the planning part. You describe what you want, it asks you
00:20:28questions until it understands and it builds you the prototype and all of that can be done from your
00:20:33phone. If it's a small change, then you can also give the final permission from your phone as well.
00:20:37This is where level three comes in and its main goal is to remove your dependency on your laptop.
00:20:43For this purpose, we found a really good app called Paseo. It runs your agent on your own laptop and
00:20:48gives you a window into it from your phone. So your agent is still sitting on your machine with all
00:20:52your files, all your skills and all your CLIs already logged in. And everything you built in
00:20:57this video just keeps working. Clawed code can also do this using the built-in remote control feature,
00:21:03but a lot of things in that are broken. Such as skills, you don't really get a menu to run the
00:21:07skills in the remote control clawed feature. So this is the free app and we're going to link it down
00:21:12below. We're not going to go deep into everything it does, just the essentials so you can get started
00:21:17with it. The app has a workspace system where each workspace is basically a folder and you open up
00:21:22different chats inside that and it runs clawed code itself so you don't need another separate
00:21:26subscription for it. Then there's another really interesting part which is that it doesn't only
00:21:31run on your laptop, it can run on a Mac mini you've connected as well. So from your laptop you can
00:21:35control your Mac mini and from your phone you can control that Mac mini too. And instead of the
00:21:40whole terminal interface it's a lot more polished. It looks like cursor but all the features are still
00:21:45here. The goal command works and so do all the other slash commands we've made. So we've opened
00:21:49up the loop engineering folder here and made a session in it and we're defining a new feature in it.
00:21:54There's one new skill in here as well which is the mobile preview skill and we'll get to that in a
00:21:59second. Now to show you how this looks on mobile we've got the phone mirrored right here and this is
00:22:03the exact same interface you get on your computer. You get all the clawed code features and your slash
00:22:09commands ready to use as well so to start a new feature you just run the new feature slash command
00:22:14right there on your mobile. We implemented the login flow for the customer side which wasn't
00:22:18implemented before. Then there's a really interesting part. It's obviously going to write
00:22:22out the whole feature file but to show you how the mocks look it can give us images straight in
00:22:27the interface and those images show up on your mobile as well so you can verify the ui right there on
00:22:32your phone. But the reason we ran that mobile preview skill is that it deploys the html mocks on links and
00:22:37those are free deployments on versal and what that gets you is that when you click the link it takes
00:22:42you to the actual mock-up and you can click around and use the app properly instead of only looking
00:22:47at images and that's really what you want when you're running this factory from your phone.
00:22:51That brings us to the end of this video. If you'd like to support the channel and help us keep making
00:22:56videos like this you can do so by using the super thanks button below. As always thank you for watching
00:23:01and I'll see you in the next one.

핵심 요약

Loop engineering structures AI coding workflows into three autonomous levels using goal commands, verification checklists, and CLI integrations to build applications overnight without continuous human supervision.

하이라이트

  • Agent loop engineering replaces human verification with agent-side verification to automate multi-hour autonomous coding tasks.

  • Level one loop engineering uses the Claude Code goal command paired with spec and verification files to build motion-heavy landing pages using GSAP.

  • GitHub, Supabase, and Vercel CLIs allow AI agents to independently manage code repositories, databases, and deployments without manual browser interactions.

  • Level two software factory loops handle multiple features sequentially by combining task queues, functional UI prototypes, and adversarial code reviews.

  • Level three loop engineering utilizes Paseo to run agent loops locally while enabling remote monitoring and feature triggering directly from a mobile device.

타임라인

Introduction to Loop Engineering and Core Concepts

  • Agent loop engineering shifts verification checks from humans to the AI agent by defining clear completion criteria.
  • Modern LLMs run autonomously for hours without human intervention, unlike models from previous years.
  • Initial MVP development requires manual setup, while loop engineering applies to subsequent feature expansion.

Loop engineering removes the human bottleneck in AI-assisted programming by automating the verification step. Traditional coding loops require developers to review every output manually. In contrast, agent loops empower models to run continuously for hours until a predefined success condition is met. The process relies on a starting trigger, an execution loop, and an agent-operated verification check. The demonstration uses a Next.js salon appointment application built with Claude Code, Warp, and VS Code, utilizing configuration files such as Claude.md, Agents.md, and design.functional.md.

Level One Loop Engineering and Landing Page Animation

  • The goal command executes tasks continuously until the target condition is met, unlike the timer-based loop command.
  • Motion-heavy landing pages built with GSAP require rigorous automated verification due to complex animation states.
  • Autonomous landing page generation runs for 38 minutes and successfully produces animated mascots matching Duolingo design aesthetics.

Level one focuses on executing a single loop with a specific goal and automated verification. The landing page implementation incorporates GSAP animations and optimization skills to handle complex visual effects that are difficult to verify in a single glance. Using the goal command rather than the periodic loop command ensures the agent works until completion. Specification files and verification checklists guide the agent's iterative building and scoring process, resulting in minor visual errors corrected through a single refinement prompt.

Platform Integration via CLIs for Database and Deployment

  • GitHub repositories store project code online, Supabase manages application databases, and Vercel handles cloud deployment.
  • Command-line interfaces enable AI agents to execute platform operations without manual browser navigation.
  • Setup files guide agents through configuring version control, database connections, and hosting environments automatically.

Application persistence and deployment require external platforms that operate independently of local machine environments. GitHub secures code versions, Supabase maintains appointment and user data, and Vercel hosts the live application. Because agents cannot interact with graphical browser interfaces, platform CLIs provide programmatic access. Authenticating these CLIs once allows the agent to create repositories, provision databases, and deploy updates autonomously across subsequent development cycles.

Level Two Software Factory Loops and Feature Management

  • The software factory loop coordinates multiple feature specifications and runs them consecutively overnight using task queues.
  • Functional UI prototypes built as clickable HTML mocks serve as behavioral blueprints for both users and verifying agents.
  • Adversarial review sub-agents with fresh context windows analyze code branches to catch bugs before pull request creation.

Level two scales development into a multi-feature software factory. Developers plan features and construct clickable HTML prototypes within mock folders to establish clear visual and functional targets. The main agent delegates feature implementation to sub-agents working on isolated git branches. To maintain code quality, an adversarial review sub-agent inspects the work with a fresh context window, actively hunting for errors. Completed branches generate pull requests containing automated screenshot proofs for final human review and merging into the main deployment.

Level Three Mobile Integration and Remote Agent Execution

  • Paseo allows developers to run Claude Code agents locally while monitoring and controlling sessions from mobile devices.
  • Mobile preview skills deploy HTML mocks directly to Vercel, enabling fully interactive mobile testing of feature prototypes.
  • Remote management frees developers from physical workstation dependency for feature planning and final approval workflows.

Level three removes laptop dependency entirely by introducing mobile-controlled agent execution. Using the Paseo application, developers interface with local agent workspaces directly from smartphones or connected Mac minis. The mobile preview skill deploys interactive HTML mockups to Vercel instantly, allowing users to test app features and review visual changes on actual mobile screens. This setup enables full oversight of software factory loops from anywhere, leaving only feature planning and final deployment permissions to human operators.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기