The loop is not the magic. The feedback inside it is. And the skill library is what feedback leaves behind.
I. Three Generations of Human-AI Work
The story compresses into a ladder with three rungs.
Rung one: prompting. You type. The model responds. You read. You type again. The human is the loop — the one who decides whether the output is good, what to ask next, when to stop. The model is a tool. You are the craftsman holding it.
Rung two: loops. You write a program that prompts the model, reads the output, decides whether the task is done, and if not, prompts again. You are no longer inside the loop. You wrote it. The model became a subroutine. Your job moved up one altitude — from doing the work to designing the system that does the work.
Rung three: skills. The loop calls named, tested, reusable units of capability instead of re-deriving behavior from scratch each iteration. The reliability compounds upward instead of downward. The system doesn’t just run — it learns, in the structural sense that each hard problem solved once is never paid for again.
Most of the noise in the discourse is people on rung one being told to move to rung two, while the people already on rung two are quietly building rung three. The Twitter brawl happened because a six-word sentence — you should be designing loops — crossed altitude levels without a translation layer.
II. What a Prompt Actually Is
A prompt is a single synchronous request. You specify intent, the model executes, you evaluate. The human supplies all three: the goal, the trigger, and the judgment. Nothing persists. Nothing compounds. Each session starts from zero.
Prompting is not obsolete — it is the right tool for tasks that are genuinely one-shot: draft this paragraph, explain this concept, translate this function. The error is treating prompting as the general case when it is actually the degenerate case of a loop with one iteration and a human as the evaluator.
Concrete example. You need a short description of what a piece of code does — the kind of plain-English note that sits at the top of a function so other developers know what it does without reading the whole thing. You paste the code, ask for the description, read it, maybe ask for a revision. Two iterations, human-evaluated, done. Prompting is correct here. There is no loop worth writing for a two-iteration task.
The failure mode of pure prompting at scale is not that the outputs are bad — they’re often fine. It’s that the human becomes a bottleneck. Every task requires attention. Nothing runs without you. You are the rate-limiting step in your own system.
III. What a Loop Actually Is
A loop is a program whose body contains a model call. The model is not the program — it is a step inside the program. The program controls when the model is called, what it receives, what happens with what it returns, and when the whole thing stops.
The minimum viable loop has five parts:
State — what does the loop know at the start of each iteration?
Prompt generation — how does current state become a model call?
Execution — the model call itself.
Evaluation — did the output satisfy the task, partially satisfy it, or fail?
Routing — based on evaluation: continue, retry with richer context, escalate, or halt.
What makes this different from a script is that the routing decision in step five is not a hardcoded branch. The model — or a separate judge-model — makes a semantic judgment each iteration. That judgment is the “agent” part. Everything else is ordinary software engineering.
A complete loop also needs five structural components beyond the control flow itself. Think of these as the load-bearing walls:
Automations — the heartbeat. A loop that runs once is not a loop; it’s a script you fired manually. Automations are scheduled triggers: every morning at 9am, every time a test fails, every time a colleague leaves a comment. They are what turn a one-shot agent into an ongoing operation.
Isolated working copies — the collision prevention. The moment two agents work on the same project simultaneously, they start overwriting each other’s changes — exactly like two people editing the same document without knowing it. Each agent needs its own isolated copy of the project, so their edits stay separate until deliberately merged.
Skills — the project memory. Without skills, the loop re-explains your entire project from scratch every run, like a contractor who forgets everything between visits. Skills are the written-down conventions, constraints, and hard-won decisions that the agent reads at the start of every session.
Connectors — the reach into real tools. A loop that can only read and write files is a small loop. Connectors let it open a proposed change, update a project board, post a message when a task completes. This is the difference between an agent that tells you what it would do and a loop that actually does it.
Sub-agents — the maker/checker split. The most important structural decision in any loop is separating the agent that does the work from the agent that evaluates it. A model is far too generous grading its own output. A second agent with different instructions — and sometimes a different underlying model — catches what the first one talked itself into. This split applies not just to tasks but to the stopping condition itself: the /goal primitive in both Claude Code and Codex uses a separate small model to decide whether the loop is done, so the agent that wrote the code is not the one declaring victory.
There is a sharper way to see why loops matter that the hype misses: a prompt handles bounded edits, but a loop handles changing state. A proposed code change changes after a reviewer leaves a comment. Test results change after a dependency is updated. User feedback changes every hour. These are not single-shot problems. They are state-monitoring problems — and state-monitoring is exactly what a prompt, fired once, cannot do.
Concrete example: the overnight code-review loop.
Imagine you have twenty proposed changes to a software project sitting in a queue — each one needs to be checked for errors, tested to make sure it doesn’t break anything else, and cleared for merging into the main codebase. Doing this by hand means a developer sitting in front of a screen, running tests, reading error messages, fixing problems, running tests again. It is repetitive, interruptible, and doesn’t require judgment on most iterations — just patience.
Boris Cherny’s canonical loop handles this overnight:
/loop babysit all my PRs. Auto-fix build issues,
and when comments come in, use a worktree agent
to fix them.In plain terms: the loop watches the queue of proposed changes. When one fails its automated tests, it reads the error message, asks Claude to fix the problem, runs the tests again, and repeats until the tests pass or it hits its retry limit. When a colleague leaves a review comment — “this function name is confusing” — the loop reads the comment and asks Claude to address it. The developer set the intent and the stopping behavior before going to bed. The loop ran overnight. In the morning, the queue is cleared or the remaining problems are flagged for human judgment. The developer’s attention went to the exceptions, not the routine.
Concrete example: the continuous research loop.
Matt Van Horn runs a research tool nightly across roughly thirty open-source software projects. The loop takes a topic query, sweeps for new activity since the last run, and sends the results to a judge that checks whether anything novel turned up. If the signal is new, it surfaces a draft or digest. If it’s redundant, it discards it. The human wakes up to either a curated summary or nothing. The loop ran while he slept, and the only thing it asked of him was to set the topic and the threshold.
The halting problem is not metaphorical. You cannot in general prove from outside that a loop terminates. Which means the three hard stops are not optional:
Maximum iteration count (the blunt instrument — always fires eventually)
No-progress detection (the semantic instrument — requires a judge that understands the domain)
Token or dollar budget ceiling (the financial instrument — the only one externally verifiable)
No-progress detection is the hardest of the three. “Progress” is a domain-relative judgment. A loop exploring a genuinely novel solution space looks identical from outside to a loop spinning on a wrong assumption. You need a judge that can distinguish exploration from drift, and that judge needs enough domain knowledge to be worth trusting. This is where most production loops underinvest.
IV. What a Skill Actually Is
A skill is a named, tested, reusable unit of capability with a known reliability profile.
The word “skill” is doing more work than it appears. It is not a prompt template. It is not a system prompt. It is an artifact with:
A signature (what inputs it expects, what outputs it produces)
Known failure modes (what makes it break, documented from experience)
A test suite (conditions under which it reliably succeeds or fails)
A track record (runs, success rate, cost per invocation)
A loop that calls a skill is calling something with a reliability profile. The math is brutal in both directions: if each step in a ten-step chain has 95% reliability, the chain succeeds about 60% of the time. At 70% reliability per step, the same chain succeeds 3% of the time. Skills are what move step reliability from 70% toward 95%.
Concrete example: the automated code-reviewer skill.
Dan Kornas built a tool that does one thing: it reads every change committed to a codebase and produces a structured review — flagging potential bugs, noting style violations, rating severity. It has been run on thousands of commits. Its output always arrives in the same format. Its rate of false alarms is known and calibrated.
When a loop calls this tool, it is calling something predictable. The loop knows what it will get back: a structured list of issues, each with a severity rating. It can route on that output — “if high-severity issues found, halt and alert the developer; if only style issues, log and continue.” The skill has a known interface.
Compare that to a loop that asks Claude each iteration: “look at this change and tell me if it looks okay.” The output format drifts. Sometimes Claude returns a paragraph, sometimes a list, sometimes a single sentence. The evaluation criteria shift based on how the question was phrased. The loop has no stable surface to route on. It’s not calling a skill — it’s asking a stranger the same question every night and hoping for consistent answers.
Concrete example: the memory-reset skill.
Geoffrey Huntley noticed a failure mode in long-running loops: the longer the conversation with the AI ran, the more the AI’s memory window filled up with its own prior attempts, wrong turns, and superseded instructions. Eventually the model started steering toward its own history rather than toward the goal. It was, in a sense, getting lost in its own notes.
His solution was a discipline: at the start of every iteration, throw away the conversation history and reset to a fixed set of anchor documents — the project brief, the current state of the code, the definition of done. Nothing else. The model starts each iteration fresh, oriented to the goal rather than to what it tried last time.
This sounds like losing information. It is, deliberately. The skill is knowing what to forget. The durable state — what actually got built — lives in the codebase, not in the conversation. Steve Yegge’s multi-agent architecture, Gas Town, formalizes this: the AI’s memory is the version-controlled repository, not the chat history. Twenty to thirty agents can work in parallel without stepping on each other because their shared memory is the code, not a conversation thread.
The tacit knowledge connection. The philosopher Michael Polanyi observed that experts carry knowledge they cannot fully articulate — a surgeon’s feel for tissue, a chess master’s pattern recognition, a senior engineer’s instinct for where bugs hide. This knowledge is real and consequential, but it resists being written down. You can describe the steps of a surgery without conveying what makes a great surgeon.
The skill-building discipline in agent engineering is Polanyi’s problem run in reverse. The first time you solve a hard problem in a loop, you do it by instinct, iteration, and judgment you couldn’t fully explain beforehand. The skill is what you extract afterward — the documented inputs and outputs, the known failure modes, the test that confirms it worked. You are making tacit knowledge explicit, converting hard-won experience into a reusable artifact. A loop that calls a library of such skills is not just more efficient than one that re-derives everything from scratch — it is accumulating crystallized expertise. The skill library is the organization’s memory made callable.
One clarification worth making: skills and plugins are not the same thing. A skill is the authoring format — a folder containing instructions, metadata, and the specific capability. A plugin is how you ship a skill, or a bundle of skills, to teammates and across projects. When you want the same capability available in every repository your team touches, you package it as a plugin and install it once. The skill is what you build; the plugin is how it travels. Conflating them is like confusing a recipe with a cookbook.
The document that sits above all skills: VISION.md.
Skills encode how a project works. They capture conventions, build steps, known constraints. But none of that answers the more fundamental question every loop implicitly needs answered: what is this project actually for?
Peter Steinberger’s practice of maintaining a VISION.md in every project addresses this directly. It is a short document — usually one page — that states the core problem the project solves, the intended solution, the key goals, the technical principles, and what success looks like. Not a specification. Not a task list. A statement of intent that remains stable while everything else changes around it.
The reason it matters for loops specifically is that loops run without you. A loop reading only skills knows how to work. A loop reading VISION.md knows what it is working toward. Without it, the loop can be technically impeccable and directionally wrong — shipping code that passes every test but drifts steadily away from what the product is supposed to be. With it, every agent, every sub-agent, every run has access to the same north star.
This also completes the Polanyi inversion. Skills make technical tacit knowledge explicit — the how. VISION.md makes intentional tacit knowledge explicit — the why and the toward what. That second kind is harder to articulate and more expensive to lose. A codebase without skills re-derives its conventions. A codebase without a VISION.md re-derives its purpose, one confident agent at a time, until nobody can quite remember what the product was supposed to do.
The practical setup is simple: keep VISION.md at the root of the repository, make it one of the anchor documents every loop resets to at the start of each iteration, and treat editing it as a significant decision — not a casual update. It is the document where the human’s judgment lives in permanent, readable form. The loop reads it. The agent respects it. The tests enforce it. That triangle is what makes a loop trustworthy enough to run while you sleep.
V. The Engineering Setup That Actually Matters
The production setup that serious practitioners converge on in 2026 has eight layers. None of them are optional.
0. Write VISION.md before you write any loop. Every loop needs an anchor — a document that tells it not just how the project works but what it is for. Keep this at the root of the repository, one page, stable. It states the problem, the intended solution, the key goals, and what success looks like. Every loop, every agent, every sub-agent reads it at the start of every run. It is the human’s intent made permanent and accessible. Without it, a fleet of technically correct agents will drift toward their own interpretation of the project’s purpose. With it, they share yours.
1. Version control as the memory substrate. Every meaningful state transition gets saved to a version control system — a tool like git that tracks every change to a codebase, who made it, and when, so any prior version can be restored. This gives you crash recovery: if the loop fails mid-run, it restarts from the last saved state rather than from scratch. Gas Town runs twenty to thirty Claude instances coordinated by a single orchestrating agent; all of them write to git. The shared codebase is the shared memory. This is not clever — it is the minimum viable durability requirement for any loop that runs longer than a single session.
2. Write a loop contract before you run anything. Every useful loop should fit on one page. At minimum, it specifies: what triggers it (a schedule, an event, or both), what it is allowed to touch, how many attempts it can make, when it must stop regardless of outcome, and where it sends its report. Here is a plain example for the overnight code-review loop:
name: pr-overnight
trigger: every night at 11pm
scope: only proposed changes tagged "review-ready"
budget: max 3 fix attempts per change, max 20 minutes total
stop if: same failure appears twice / change touches files outside scope
report: leave a summary comment on each change reviewedWithout a contract, a loop is background chaos. With one, it is a junior teammate that handles the boring parts and escalates the judgment calls. The contract also makes costs predictable: you know before you run roughly how many model calls the loop will make, and roughly what that costs.
3. One loop, one owner — no shared write access. If multiple loops can modify the same resource simultaneously, you don’t have automation — you have a race condition. Two loops both trying to fix the same failing test will produce conflicting changes that are harder to untangle than the original problem. Assign ownership: one loop handles test failures, one handles review comments, one handles dependency updates. Shared read access is fine. Shared write access should be rare and explicit.
4. A judge-agent layer. Every loop needs at least one model call whose job is not to produce output but to evaluate output. The judge reads the agent’s work against the task specification and returns a verdict: done, retry with this additional context, or escalate to a human. The judge should operate with a different orientation than the worker — ideally a different system prompt, sometimes a different model. A worker optimized for output generation makes a poor self-evaluator for the same reason a writer makes a poor editor of their own fresh draft. The judge is what separates a trustworthy loop from a confident mistake machine.
5. Refresh state at the start of every iteration. A loop can silently drift if it acts on yesterday’s picture of the world. The proposed change it’s reviewing may have been updated since the last iteration. The test failure it’s trying to fix may already be resolved. Every iteration should begin by fetching the current state of whatever it’s acting on — not relying on what was cached in the prior pass. Stale assumptions are a distinct failure mode from runaway loops, and they’re harder to detect because the loop appears to be working.
6. Connect the loop to your real tools. A loop that can only see the filesystem is a loop with one hand tied behind its back. The full value of the architecture comes when the loop can reach into the tools your team already uses — the project tracker, the messaging channel, the deployment pipeline. When a loop finishes reviewing a proposed change, it should be able to open it for merging, update the ticket, and notify the team — not just write a text file saying it’s done. Modern agent frameworks support this through a standard called MCP (Model Context Protocol), which means a connector you build once typically works across tools. The practical test: if your loop’s final output is a report for a human to act on manually, ask whether a connector could make it act directly.
7. Skill library, version-controlled, and observable. Keep your skills in the repository alongside the code. Name them. Test them. Track their success rate. When a skill improves, version it rather than overwriting — the loop was written against a specific version of the skill, and silently changing it changes the loop’s behavior in ways that may not be obvious.
Log every iteration: what state went in, what prompt was generated, what the model returned, what the judge said, what routing decision was made. Not for debugging only — for calibration. The log is how you improve your skills and sharpen your no-progress detection over time. A loop you cannot observe is a black box with a billing API attached.
VI. What Compounds — and What Erodes
The loop discourse is mostly about efficiency — running more tasks, faster, while you sleep. That framing is correct as far as it goes. But the deeper point is about what accumulates, and what silently disappears.
A prompt leaves nothing behind. A loop leaves a log and a result. A skill leaves a tested, reusable capability that every future loop can call. The skill library is the organization’s crystallized experience — not just tasks completed, but hard problems solved and their solutions made portable.
This is the Steinberger principle at its clearest: if you do something hard, turn it into a skill afterward so next time is free. The first time, you paid full price in attention, iteration, and judgment. The skill is the receipt you keep. Every subsequent loop that calls it pays a fraction of the original cost.
But there is a cost on the other side of the ledger that compounds just as reliably. The faster a loop ships code you didn’t write, the wider the gap between what exists in the codebase and what you actually understand. Call this comprehension debt. A slow loop creates a little. A smooth, fast, reliable loop creates a lot. The loop doesn’t know the difference — it shipped the code either way. You do, or you don’t, depending on whether you read what it made.
This is the sharpest observation in the practitioner literature, and it deserves to sit next to the efficiency argument rather than be footnoted: two people can build the exact same loop and get completely opposite results. One uses it to move faster on work they understand deeply. The other uses it to avoid understanding the work at all. The loop is identical. The outcomes diverge. Designing the loop is the cure when you do it with judgment and the accelerant when you do it to avoid thinking — same action, opposite result.
The romantic version of this trajectory is that you write the loops and a thousand agents build your company overnight. The production version is that you write VISION.md first, then write the loops carefully, give them a contract, cap them so they halt, assign them clear ownership, give them skills worth calling, stay connected to the tools that matter, and come back in the morning to evaluate exceptions — and to read what ran. The job did not disappear. It moved — from doing the work to designing the system that does the work, and from solving problems to encoding solutions so they stay solved.
That is the real meaning of the ladder. Not that engineers become obsolete. That their judgment, once exercised, can be made permanent. But only if they keep exercising it.
References:
I Now Just Write Loops To Prompt Claude Code: Claude Code Creator Boris Cherny https://officechai.com/ai/i-now-just-write-loops-to-prompt-claude-code-claude-code-creator-boris-cherny/
Codex Loops: What Boris Cherny Gets Right About Managing Agent Work https://www.developersdigest.tech/blog/codex-loops-boris-cherny-agent-routines
Welcome to Gas City https://steve-yegge.medium.com/welcome-to-gas-city-57f564bb3607
Loop Engineering.
Hmm. I think it is prompt -> skill -> loop
Great post. I am learning a lot from your feed. Thanks!