Addy Osmani published a piece called Loop Engineering that puts a name on something a lot of us have been converging on independently: the leverage point in working with AI agents has moved. It used to be the prompt. Then it was the context. Now it's the loop.
His article is written for developers assembling this on their own machines. I want to add the other half: what the same ideas look like when the loop runs in production, unattended, for people who will never read a SKILL.md file. VibeKit runs a persistent coding agent for every app it hosts, which means we operate a lot of these loops at once, and the operational lessons are different from the setup lessons.
The ELI5
Prompt engineering is steering a car. You tell the AI one thing, it does it, you look at the result, you tell it the next thing. You are in the loop, and the loop runs at the speed of your attention.
Loop engineering is building the assembly line. You design a system where the agent prompts itself: it runs on a schedule, keeps notes between runs, checks its own output, and a second agent verifies the first. Work continues while you sleep. Your job moves from "give instructions" to "design the machine that gives instructions."
The skill that matters stops being wordsmithing a prompt and becomes systems design: what runs when, what remembers what, what checks what, and what happens when something fails at 3am.
The five components
Addy's breakdown holds up well against what we ended up building, so I'll use his taxonomy:
- Automations. Scheduled tasks that run without a human kicking them off: nightly triage, dependency checks, a morning pass over yesterday's errors.
- Worktrees. Isolated working copies so parallel agents don't stomp each other's changes.
- Skills. Reusable files that encode project knowledge so the agent doesn't re-derive it every session.
- Connectors. MCP integrations that give the agent real tools: the issue tracker, the database, the deploy pipeline.
- Sub-agents. Separate roles, most importantly splitting the code writer from the code verifier.
Plus the piece that makes the rest coherent: persistent memory, because models forget everything between runs. We've written before about how that memory has to be layered and what actually persists, so I won't repeat it here.
If you're a developer, you can assemble all five yourself today, and Addy's article is a good map. What follows is what the map doesn't show.
Lesson 1: the verifier is the product, not the writer
Every demo of agentic coding shows the writer: look, it built a feature. In production, the writer is the cheap half. Generation quality is high and getting higher. What separates a loop that compounds value from a loop that compounds damage is the verification half, because in an unattended loop there is no human between a mistake and the next iteration building on top of it.
We learned this the blunt way. Our loop closes with an automated QA agent that exercises the app after changes, and separately with infrastructure health checks that probe the running app. Both exist because the alternative, trusting the writer's own "done" report, produced confident wrecks. A loop without an independent verifier isn't automation, it's a mistake amplifier with a cron schedule.
Lesson 2: close the loop on production truth, not model self-assessment
This is the lesson I'd put on a poster. An agent's evaluation of its own work is a language model grading its own homework. The only signal that can anchor an unattended loop is external reality: does the app boot, does the health check pass, does the deploy actually serve traffic, did the user come back.
A concrete example from our own logs. A deploy pipeline can report "redeployed successfully" while the app it deployed never starts serving. Both statements are true: the git pull and build ran fine, and the process crashes on boot. If your loop's success signal is the pipeline's report, the loop believes everything is fine forever. Ours now distinguishes "the machinery ran" from "the outcome exists," and the number of silent failure modes that distinction caught was humbling.
This is also, I think, the real moat in this space. Anyone can wire five components together. Outcome telemetry, the ground truth about whether the loop's output actually works for real users over time, only accumulates if you operate the things the loop builds.
Lesson 3: the loop dies mid-iteration, constantly
On a laptop, you notice when a run dies: the terminal is right there. In production, loops get interrupted by deploys, instance restarts, rate limits, and upstream API failures, and nobody is watching. The design consequence is that every stage of the loop needs to be resumable or safely restartable, and "the run died silently and nothing retried" has to be treated as a first-class bug, not bad luck.
Most of our hardest operational bugs have been exactly this shape: not "the agent wrote bad code" but "the loop stopped and nothing noticed." If you build one of these, spend your paranoia budget there.
Lesson 4: a loop that can spend money needs a breaker
An unattended agent with an API key is a machine that converts time into a bill. A human in a chat session self-limits; a loop does not. Whatever your version of a budget is (tokens, dollars, iterations), the loop needs a hard breaker and a graceful degradation path, decided before the loop runs, not during the incident.
Ours is a per-call credit gate with a bounded grace window for critical work. The specific numbers matter less than the principle: the breaker has to sit outside the loop, where the loop can't reason its way past it.
Lesson 5: cognitive surrender is measurable, and it looks like churn
Addy's most important caveat is the human one: automation this smooth invites you to stop understanding your own system. He frames it as a risk to engineers. We see it as a metric, because our users are mostly not engineers.
When someone's app is built entirely by a loop they didn't watch, their comprehension of what they own is near zero. And in our retention data, comprehension is the difference between a user who comes back to iterate and one who quietly leaves. The users who stick are the ones who made a change, saw it live, and understood the causal link. The loop's job is not just to build; it's to keep the human's mental model alive while it builds. That's a product-design problem, not a model-capability problem, and it's mostly unsolved, including by us.
Should you build the loop or buy it?
Honest answer, since I sell one of these: if you're a developer and the loop is for your own codebase, build it yourself. You'll understand every failure mode, and Addy's components map cleanly onto Claude Code, Cursor, or whatever you already use. The assembly is a weekend, and the understanding is the point.
The productized version makes sense when the person who wants the outcome is not the person who'd enjoy the assembly: someone who wants an app that keeps improving, not a factory to maintain. That's the bet VibeKit makes: every app gets the loop pre-assembled (agent, schedules, worktrees, QA verifier, memory, hosting) driven from a phone, with the loop closed on production telemetry instead of self-assessment. One loop per app, running whether or not your laptop is open.
Either way, the shift Addy named is real. The prompt was never the product. The loop is.