---
title: "How to \"Loop\" Code: AI Agents That Ship Without You"
canonical: "https://www.rankinghacks.com/how-to-loop-code/"
pubDate: "2026-06-09T03:13:00.000Z"
updatedDate: "2026-06-09T03:13:00.000Z"
author: Andreas De Rosi
description: "How to loop code: build autonomous AI coding agents with automations, worktrees, skills, sub-agents and state — plus the honest caveats. A solo operator's guide."
tags: [automation, ai-agents, loop-engineering, systems]
categories: [systems]
---
For two years the skill everyone chased was prompting. You learned to talk to the model — frame the task, hand it context, read the diff, ask again. You were the loop. Every iteration ran through your keyboard.
That era is closing. The people getting real leverage out of coding agents in 2026 aren't better prompters. They've stopped prompting altogether. They build a *system* that prompts the agent — on a schedule, against a goal, with its own memory — and then they go do something else. Addy Osmani named this **loop engineering**, and his one-line definition is the whole idea: *"You design the system that does it instead."*
This isn't a developer-only trick. If you run a site, a portfolio, or any operation where the same code-shaped chores recur — build a tool, patch a script, refresh a data feed, fix the thing that broke overnight — looping code is how one person starts operating like a small team. This post is the working playbook: what a loop is made of, the one rule that keeps it honest, and the parts that will quietly cost you if you skip the fine print.
## What "looping code" actually means
A single agent run is a turn: you ask, it acts, you read the result. A *loop* is that turn made recursive and autonomous. You define a purpose and a stopping condition, and the agent iterates — discovering work, doing it, checking itself, recording where it got to — until the goal is met or it hits something it's told to escalate.
The mental shift Osmani points at is from "a tool you hold one turn at a time" to "a system that pokes the agents instead of you." The leverage moved up a floor: from *prompt engineering* (getting one good answer) to *loop design* (getting a hundred good answers while you sleep). The catch — and we'll get to it — is that responsibility did **not** move with it.
## The six pieces every loop is built from
Both major harnesses — Claude Code and OpenAI's Codex app — now ship the same primitives. The names differ; the jobs are identical. The flow runs left to right: discovery feeds isolated work, knowledge and tools feed the agents, a separate checker verifies, and state remembers it all for the next run.
*The six primitives of an agent loop, in the order they fire — from scheduled discovery through to the state file that hands work to tomorrow's run.*
Here's the same six, reframed for someone running their own shop rather than a platform team:
| Primitive | Its job in the loop | What it looks like in practice |
| --- | --- | --- |
| **Automations** | Discovery + triage on a schedule | The heartbeat. A cron job, a `/loop` interval, or a `/goal` run-until-done. Without this you don't have a loop, just a run you did once. |
| **Worktrees** | Isolate parallel work | A separate git working directory per task so two agents editing at once can't overwrite each other. One agent's checkout literally can't touch another's. |
| **Skills** | Codify project knowledge | A `SKILL.md` file holding your conventions, build steps, gotchas. Stops the agent re-deriving context cold every single run. |
| **Plugins / connectors** | Connect your tools | MCP servers wiring the agent to your issue tracker, database, Slack, deploy hooks. The difference between "here's the fix" and "PR opened, ticket linked, channel pinged once CI is green." |
| **Sub-agents** | Ideate *and* verify | Two roles: one writes, a different one checks. More on why this matters below — it's the single most important structural choice in the whole design. |
| **State** | Track what's done | A markdown file or a Linear board. "The agent forgets, the repo doesn't." State is what lets tomorrow's run pick up exactly where today's stopped. |
You don't need all six on day one. Automations + State get you a real loop. The rest are how you make it parallel, knowledgeable, connected, and trustworthy.
## The one rule: never let the writer grade its own homework
If you take a single thing from this, take this. The most valuable structural move in a loop is **splitting the agent that writes from the agent that checks.** Osmani puts it bluntly: *"The model that wrote the code is way too nice grading its own homework."*
A model that just produced 200 lines has, in effect, talked itself into believing they're correct — that's what generating them *was*. Ask the same model "is this right?" and it will mostly agree with itself. A second agent, with different instructions and ideally a different model, comes in cold with one job: try to break it. It catches the edge case the writer rationalized away.
This is why run-until-done goals use a *separate* small model to judge whether the stopping condition is truly met, rather than trusting the worker's "yep, done." Adversarial verification costs extra tokens. It is almost always worth it — an unattended loop with no independent checker is just a faster way to ship mistakes you won't notice until later.
## What a real loop looks like
Concrete beats abstract. Here's the shape of a daily loop, the kind you can actually stand up:
1. **A morning automation fires.** It runs a triage skill that reads what changed — yesterday's errors, open issues, recent commits — and decides what's worth doing today.
2. **Findings get written to a state file.** Markdown or a board. This is the spine of the whole thing; everything downstream reads from it.
3. **Each actionable item gets its own worktree.** A sub-agent drafts the change in isolation. A second sub-agent reviews it against the skills and the tests.
4. **Connectors close the loop.** Passing work becomes a PR, the ticket updates, a channel gets pinged. Anything ambiguous gets parked in a triage inbox for a human.
5. **The state file records where it stopped.** Tomorrow's run reads it and continues.
The punchline, in Osmani's words: *"You designed it one time. You did not prompt any of those steps."* That same pattern generalizes far past code — it's the engine behind operators like [Helena Liu running an AI + automation content pipeline](/how-helena-liu-uses-ai-and-automation-to-create-blog-posts/) and the [ChatGPT-plus-Make comment automations](/how-to-automate-facebook-comments-with-chatgpt-and-make/) we've covered. Code is just the highest-leverage thing to point a loop at, because the agent can verify its own output by running it.
## Where to run it — three rungs, start low
You don't jump straight to a server farm. There's a ladder, and most people should start on the bottom rung and only climb when they feel the ceiling:
- **In-process.** Sub-agents and agent teams inside a single session. Zero setup — just the harness you already have. Start here. Most "loops" people need never leave this rung.
- **Local orchestrators.** Tools that run several agents across worktrees on your own machine — good when you're juggling 3–10 parallel tasks and want a dashboard over them.
- **Cloud async.** Claude Code on the web, Codex web, and friends: assign the task, close the laptop, come back to a PR. This is the rung where loops genuinely run without you present — and the rung where the caveats below stop being theoretical.
A loop running on your laptop while you watch is training wheels. A loop running on a schedule while you're asleep is the actual product. Climb deliberately.
## The honest part: four ways a loop bites you
Loop engineering is sold as pure upside. It isn't. Four problems get *worse* as the loop gets better, not better — and a site named after honest tactics isn't going to pretend otherwise:
1. **The verification burden is still yours.** Unattended loops make unattended mistakes. Automating the *writing* does not automate the *responsibility* — you still have to ship code you've confirmed works. The loop scales output; it does not scale your accountability for that output.
2. **Comprehension debt compounds.** *"The faster the loop ships code you did not write, the bigger the gap between what exists and what you actually get."* You can end up the owner of a codebase you no longer understand. That's a real, mounting liability, not a vibe.
3. **Token cost runs wild if you're not watching.** Adversarial verification, parallel sub-agents, and run-until-done goals all multiply usage. Costs can swing enormously between a tight loop and a sloppy one. Put a ceiling on it before you let it run overnight, not after the bill.
4. **Cognitive surrender is the quiet one.** The comfortable posture — let the loop think so you don't have to — is the dangerous one. The exact same loop design produces opposite outcomes depending on whether you use it to *move faster on work you understand* or to *avoid understanding the work at all*.
None of these are reasons not to build loops. They're reasons to build them like an engineer instead of a spectator.
## Why this is a solo operator's unfair advantage
Here's the part that matters if you're a team of one. A loop collapses the gap between "I have an idea for a tool" and "the tool exists and maintains itself." The internal scraper, the price-checker, the content-refresh script, the broken-link sweeper — the stuff you'd never hire for and never quite get to — becomes a scheduled automation with a checker and a state file. You stop being the bottleneck on your own infrastructure.
That's the same leverage thesis running through everything in the [Systems channel](/systems/) and the [AI-for-affiliate-growth playbook](/harnessing-ai-for-affiliate-seo-growth/): one person, AI-shaped leverage, output that used to need a team. And it dovetails with where the whole web is heading — pages becoming things agents *operate*, covered in [Chrome's WebMCP](/chrome-webmcp-agent-tools/) and graded by [Lighthouse's new agentic browsing score](/lighthouse-agentic-browsing-score/). The operators who learn to *run* loops, not just be inside them, are the ones who'll compound.
## Build the loop — but stay the engineer
The leverage point moved from prompting to loop design. The responsibility didn't move at all. A loop is the most powerful thing a solo builder can stand up this year, and it's also the easiest way to wake up owning code you don't understand, run up a bill you didn't expect, and stop thinking about the work that pays you.
So build it. Just build it the way Osmani signs off: *"like someone who intends to stay the engineer, not just the person who presses go."*
---
*This piece builds on Addy Osmani's writing on loop engineering and agent orchestration. Sources and further reading: Loop Engineering, Agent Harness Engineering, and The Code Agent Orchestra (addyosmani.com); plus the Claude Code docs on the agentic loop. More on AI-era leverage in the RankingHacks Systems channel.*