Every Level of Claude Code Loop Engineering, Explained

Loop engineering has become essential to how we use agents, because new models can run on their own for hours. Here's every level of it, from one task to a factory you run from your phone.

Loop engineering is now essential to how we use agents, because new models can run on their own for hours. We've organized it into three levels: level one is the basic unit and how to use it well, level two builds that unit into a factory that works overnight, and level three frees you from your laptop entirely.

We build software, and loop engineering has become central to how we ship. The reason it works now and didn't a year ago is simple: models couldn't run this long before, and now they can work without you for hours. Everything below runs on one real app, a salon appointment system where customers pick a stylist, see open times, and book, with a staff login where a receptionist approves requests and manages calendars. We use Claude Code here, but the same systems work in Codex.

First, what a loop actually is

When you build with an agent, you're already in a loop. You prompt it, it builds, it asks you to verify, and if it's wrong you prompt again. An agent loop is when you remove yourself and hand the verification to the agent too.

That's the natural direction, because building isn't what takes your time. Agents do that in the background. What takes your attention is checking whether the agent succeeded. But the agent can only verify if it knows what the correct output is, and that's the core of the loop.

A loop has a few parts: something that starts it, the loop itself, and a verification check at the end of each pass that decides whether the agent is done. That check has to be defined by you. It's the one piece you keep, because it's the piece that was always yours: deciding whether to turn the agent off or make it work more. You can't hand that off.

One thing not to loop: your MVP, the roughest working version that does the main thing and nothing else. An MVP is quick to build anyway, and to put a loop on it you'd have to define "done" before starting, when you don't yet know where the product is going. Build the first version yourself.

Level 1: One goal, one loop

At level one you run a single loop with one goal, and the checking moves off you onto the agent. We did this on the landing page, which sounds wrong, because a landing page is one screen the agent can build in a single run. Putting a loop around it would be more work than the page.

The reason it fits here is that we wanted a motion-heavy landing page using the GSAP skill, where everything animates in. That's the part you can't check with one look, because there are so many places animation can go wrong, and it takes a lot of back and forth. That's a good test for whether something should be looped: if it needs a lot of back and forth, loop it.

The naming trap. In Claude Code's slash menu there's a loop command and a goal command. Loop engineering is the goal one. The loop command runs a prompt on a timer, firing every few minutes whether anything changed or not. The goal command keeps working until the thing you asked for is actually done. You type /goal, write the goal, and tell it how to verify success. At the end of every turn, a smaller model reads the conversation and decides whether the agent needs to keep going.

How we set it up. Inside the project, a features folder holds one folder per feature, and each has a spec file (everything about the feature) and a verification folder that starts empty and fills as the loop runs. We used the Grill Me skill to write the landing page spec, told it which skills to use (GSAP for animation, plus an optimize skill to win the speed back without removing the animation), gave it an image reference, and pointed the checking at a screenshot tool named in our global claude.md (the file that applies to every project), because screenshots are far faster than opening a full browser each time. So the spec it wrote was both the build plan and the verification checklist.

The last move turned the spec into a goal: we told it to write the spec file as a goal, so from then on we just ran the goal command against it. To avoid repeating all that per feature, we built a goal-writer skill that creates the feature folders with spec files already written as goals.

It ran for 38 minutes and came back with one error: the mascot blinking. That's the one thing verification was never going to catch, because a screenshot captures a single moment and the gap between blinks is too short for two screenshots to see. One correction prompt fixed it, and the rest came out on brand with the Duolingo style already in the app.

Takeaway: Loop the work that needs back and forth, not the quick one-shot stuff. Use the goal command, define the check yourself, and let a screenshot tool do the verifying.

The setup everything else runs on

Three things this app needs that your computer can't do alone, none of which you operate yourself.

• GitHub takes your code online and keeps it in a repo, so the project isn't only on your machine where one mistake wipes it.
• Supabase is the database, so bookings are saved instead of vanishing on refresh.
• Vercel deploys the app, putting it on the internet so other people can open it.

On all three you just make an account and click "login with Google." Nothing to configure. Everything else goes through the agent, because all three have a CLI, which is an app the agent can use since it can't click around a website like you do. You tell the agent to use all three via their CLIs, it gives you a command for each, you paste those into a second terminal, approve the browser login, and from then on the agent handles everything without you opening those sites. (We link a free setup file that hands all of this to the agent for you.) GitHub doesn't need a skill, but there's a deploy-to-Vercel skill and the Supabase plus Supabase best-practices skills, which auto-invoke whenever the agent needs them.

Level 2: The software factory

Level two is the software factory loop. Instead of one feature, you plan several and set them on a loop so the agent works overnight through a list and doesn't stop after one. Because these loops get long, it needs a tracker to know if the list is done. The loop finishes once every feature is ticked off.

Prototype before you build. When planning features, don't just write what to make, build the UI as a prototype, a fully clickable version that doesn't actually work. Two reasons: it shows you whether the thing you imagined is the thing you actually wanted, and it becomes the way the looping agent verifies whether what it built is correct.

How the factory runs each item. The main agent picks an item off the list but doesn't build it. It hands the task to a sub-agent, and to protect your app, it first makes a copy of the folder called a branch and the sub-agent works there. When the sub-agent finishes, it does not verify itself. This is a core rule: the agent that does the work should never verify it. Verification always goes to another agent with a fresh context window. So the main agent hands the branch to an adversarial review agent, one that always assumes there's an error, which is what makes it good at catching bugs. If it finds a problem, the build agent starts again, looping until the feature is ticked off.

Your approval, then it ships. Once a feature passes, its branch is merged into the main branch, and the main version on GitHub is what shows on the deployed Vercel app. The agent opens a pull request (a request to merge the feature branch into main) with a summary and screenshots attached. If you want to be sure, ask Claude to switch to that branch and test it on your computer, then merge.

The skills that run it. A new-feature skill makes a folder per feature with a spec and verification files. It calls the functional-UI skill, which keeps a mocks folder with an HTML prototype of the app (customer and receptionist views), taking the cloned app and showing only the part the feature changes, so you can see whether it's what you wanted and the loop has something to verify against. A feature-batch skill keeps a queue markdown file, a single table listing features as to-do, building, or done. You run that queue file inside a goal that only stops when no row is left in to-do or building. The skills are interconnected: goal-writer triggers new-feature, which triggers functional-UI, so one invocation sets the whole thing up as a runnable loop.

We defined two features (a services page per stylist, and session reviews added by the receptionist), ran the loop, and about three hours later had pull requests waiting with summaries and screenshots. We reviewed, merged, and the live Vercel app had the new services flow working, each stylist with their own services and a required service selection before booking.

Takeaway: The factory is a list on a loop. Build on branches, let an adversarial agent review each one, gate the merge behind your approval, and prototype every feature first so the loop has a target.

Level 3: Run the factory from your phone

By now only two things are left for you: planning the feature and giving final approval before it reaches users. Neither needs your laptop. You describe what you want, it asks questions until it understands and builds the prototype, and small approvals can happen from your phone too. Level three removes your dependency on the laptop.

We use an app called PO. It runs your agent on your own machine, with all your files, skills, and logged-in CLIs, and gives you a window into it from your phone, so everything you built keeps working. (Claude Code has a built-in remote feature, but parts are broken, like skills, which have no menu to run.) PO uses a workspace system where each workspace is a folder with chats inside, and it runs Claude Code itself, so no separate subscription. It can also run on a connected Mac Mini, so you control that machine from your laptop or phone, in a polished interface that looks like Cursor with all the features intact. The goal command and all the custom commands still work.

There's one new skill here, the mobile-preview skill. When you define a feature on your phone, it writes the feature file and shows the mock images right in the interface, and it deploys those HTML mocks as free Vercel links. So instead of only looking at images, you tap the link and click around the actual mockup on your phone, which is exactly what you want when running the factory on the go.

Takeaway: Once building and verifying are fully looped, planning and approval are all that's left, and both fit on a phone. That's when loop engineering becomes truly agentic.

FAQ

Goal command or loop command? Goal. The loop command runs a prompt on a timer whether anything changed or not. The goal command keeps working until the thing you asked for is actually done, which is what loop engineering means.

What should I not loop? Your MVP. It's quick to build, and looping it means defining "done" before you know where the product is going. Build the first version yourself.

Why can't the building agent verify its own work? Because it judges its output off the same context it built from. Verification always goes to a separate agent with a fresh context window, ideally an adversarial one that assumes there's a bug.

Why prototype a feature before building it? It confirms the thing you imagined is the thing you wanted, and it gives the looping agent something concrete to verify the build against.

How do GitHub, Supabase, and Vercel get set up without me configuring them? You make accounts and log in with Google, then the agent uses each platform's CLI to create and manage everything. A free setup file hands the whole process to the agent.

The takeaway

Loop engineering climbs in three steps. Level one moves checking off you for a single hard task. Level two turns that into a factory that builds a whole feature list overnight, on branches, reviewed by an adversarial agent, gated by your approval. Level three lifts the whole thing onto your phone, so all that's left is planning and a final yes. Build it in that order and the agent does the work while you decide what the work should be.

The full repo, with every skill shown here already set up, lives inside AI Labs Pro.