Loop engineering: from writing prompts to writing loops

mantua agentsJul 27, 2026 · updated Sep 1, 2026

The claim that the unit of work is shifting from the prompt to the loop — Cherny, Osmani and Guzman all saying a version of it — and why the interesting question is not how to keep an agent running but who decides what "done" means.

A framing note, sitting one level above the mechanics in Keeping an agent running: goals, loops, hooks and schedules. The claim: the thing a person writes is no longer the prompt, it's the loop that produces the prompts.

Three versions of it, collected in a Department of Product piece from 2026-07-21. Boris Cherny, who built Claude Code, describes having stopped prompting Claude directly — loops prompt Claude and work out what to do, and "My job is to write loops." Addy Osmani calls loop engineering a matter of replacing yourself as the person who prompts the agent. Katia Guzman, at OpenAI, frames it as a shift from prompting to goal setting: describe the situation and let the model figure out the approach. Different words, one move — the human steps back from the per-turn instruction.

Source caveat

The article is paywalled and the capture is a fragment: it stops partway into the /goal section, before any of the worked examples. What survived is the framing above and the taxonomy below. The promised inventory of 100+ commands and the practical playbook are not in the clip and are not represented here. Treat this page as the framing, not as the guide it was.

Slash commands as the surface

The article's one durable piece of structure is a three-way split of what a /command actually is:

Built-in — ships with the tool, handles session mechanics.
Custom — a markdown file you write that expands into a prompt when invoked.
Connector-exposed — surfaced by a connected MCP server or plugin rather than defined locally.

Worth noting because this notebook already runs entirely on category two: /ingest, /oracle and /lint in .claude/commands/ are markdown files, and they are the operations of the LLM-wiki pattern made typeable. The observation that a command is just a prompt in a file is unremarkable until you notice it is the same bet as "what the agent can't see doesn't exist" — put the procedure in the repository and it applies every run.

Where the framing is right, and where it thins out

It is right that the mechanisms now exist and are cheap. /goal, /loop, Stop hooks and scheduled runs are all in the tool; none of them needs building. The "Ralph Wiggum" loop that both Anthropic and OpenAI point at (see Harness design: prior work still to read) was a community hack a year ago and is now a first-class feature. That part of the shift has genuinely happened.

Where it thins out is the implied conclusion — that writing the loop replaces the judgment work. It doesn't; it relocates it. A loop that runs unattended still needs someone to have decided what "done" means, in advance, precisely enough that a model can check it. The /goal documentation's own advice makes this concrete: one measurable end state, a stated check, the constraints that must not be violated. Writing that is the same skill as writing a rubric for an evaluator, which is where the actual work turned out to be in every harness in this cluster. The typing goes away. The specification doesn't.

A separate line of evidence says the same thing from the other end. Agentic Coding and Persistent Returns to Expertise (2026-06-16), cited in The harness is a skill issue, reports from usage data that people with no formal coding training direct agents through complex technical work successfully, and that what predicts success is domain understanding rather than coding skill — "how well a person understands the problem they're trying to solve". If the returns have moved to understanding and specifying the problem, then the skill the loop removes is the typing and the skill it concentrates is exactly the one this framing keeps waving past.

The article is honest about the boundary, at least: it says goals are for well-defined, verifiable tasks, and not for decisions needing human judgement or where the cost of being wrong is high. That is the right line, and it is also exactly the owner's open question — delegating tasks is easy, delegating decisions is the part that buys time and the part nobody has scoped. "Write loops" is advice about the easy half.

One turn further out

Karpathy's version of the claim predates the article by four months and goes a step past it. His formulation is remove yourself as the bottleneck — you cannot be there to prompt the next thing, so arrange it once and hit go (NoPriors, March 2026). The metric he holds himself to is token throughput: leftover subscription quota means he failed to get enough happening per token he typed.

Then he takes the recursion one level further than anyone else in this cluster. If the loop is a markdown file, the loop is tunable — "a research organization is a set of markdown files that describe all the roles and how the whole thing connects", and you can therefore hold a contest between hand-written specifications, see where the improvements came from, and have a model write a better one (Auto Research: taking the researcher out of the loop). First you stop writing the code, then the prompt, then the loop, then the thing that writes the loop.

Which makes the objection above sharper rather than weaker. Every level of that stack still bottoms out in something unoptimised deciding what "better" means. Karpathy's own constraint says so — if you can't evaluate it you can't automate it — and his one working demonstration is a training run with a validation loss, the friendliest metric that exists.

Open

Cherny's claim is about his own workflow on a tool he wrote. Nobody in the piece reports what fraction of loop runs are abandoned, or what a bad loop costs. Same absence as the one Agentic engineering: the work moves to the harness flags in the harness posts: no published failures.
If the loop writes the prompts, what reviews the loop? A misspecified condition runs to completion and reports success. There is no equivalent of a failing test for a rubric. The nearest thing to an answer in the notebook is Aleph Alpha's: keep the loop in version control as ordinary code, so it reviews like code — a pull request, a five-minute downscaled end-to-end run on every change, a nightly full run that asserts the output still improves on the eval suite. That covers the loop breaking. It does not cover the loop being wrong about what "better" means, because the nightly assertion is itself a metric nobody grades. The half that has a test is the half that was never the hard one.

The largest-scale version of the same gap arrived on 2026-08-13 and is worth putting here rather than only on its own page. Greenblatt's optimistic scenario is that once the models are capable and aligned enough, you hand them the job of aligning the next generation — the loop reviewing the loop, finally, by something competent enough to do it. His own objection to it is the one this bullet has been making: the reviewer's verdict has to come from somewhere, and if it is produced by the same process that produced the thing being reviewed, it is a report on that process rather than a check on it. See the judge's verdict has a provenance too. So "what reviews the loop" survives being handed to something smarter than you, and it is the same shape at both ends of the scale: the typing goes away, the specification doesn't, and now neither does the question of who wrote the specification's opinions.
The first report of a loop on this ladder failing empirically arrived on 2026-09-01, and it is about the rung above the ones here. Spec-to-code — change the specification, recompile, never read the output — is "write the loop, not the code" taken to its end, and a talk on software fundamentals reports running it and watching the output get worse on each pass, with software entropy as the diagnosis: a change made without regard for the design of the whole degrades the whole, and a faster loop only degrades it faster. That is a different objection from this page's. This page says the specification work does not go away; that talk says the artefact decays even when the specification is fine, because nothing in the loop is investing in its design. Both survive, and the evidence for the second is one person's experience with no measurement — worth holding loosely for exactly the reason this page holds Cherny's claim loosely.

Linked from

Agentic engineering: the work moves to the harnessThe emerging discipline around long-running coding agents — designing the scaffolding, feedback loops and environments that let an agent do reliable work, rather than writing the code yourself. Entry point for the harness-design cluster in this notebook.
Auto Research: taking the researcher out of the loopKarpathy's name for an agent loop that improves a model without a human in it — an objective, a metric, boundaries, and go. What it did to a repo he had hand-tuned for two decades, the one constraint that decides where it applies, and the parallel version he has not solved.
Code is not cheap: software fundamentals against spec-to-codeA conference talk arguing that the spec-to-code loop degrades a codebase on every pass, that the reason is ordinary software entropy, and that five failure modes of AI coding each have a fix sitting in a twenty-year-old book. The first source in this notebook that locates the harness inside the code rather than around it.
Generator–evaluator loopsSplitting the agent that does the work from the agent that judges it — why self-evaluation fails, what makes an evaluator worth its cost, and how three independent teams arrived at the same shape from taste, from QA, and from production corrections.
Keeping an agent running: goals, loops, hooks and schedulesFour mechanisms decide what starts an agent's next turn and what stops the sequence — /goal, /loop, Stop hooks and scheduled runs. Notes on the /goal documentation, including the constraint that shapes everything else: its evaluator has no tools and can only judge what the transcript shows.
The case for recursive self-improvement (Dwarkesh × Greenblatt, 2026-08)Ryan Greenblatt argues that AI research is verifiable enough to automate itself, that automating it buys four or five years of progress in one, and that what comes out the other end can transform the world without ever learning to play politics. His median for full automation is 2030–31 and his odds on takeover by 2040 are 35–40%.
The customer is not the human anymoreKarpathy makes the same argument twice in one interview — smart-home apps should be APIs, docs should be markdown for agents rather than HTML for people — because in both cases an agent consumes the interface and routes to a human. Where that lands for this notebook, where it thins out, and what changes when a vendor does it deliberately.
The harness is a skill issueA piece by Anton Leicht on sovereign AI sent me looking for how the frontier labs actually run their internal coding agents. The answer is that they are still experimenting — nobody has Auto Research — which means the harness is mine to build, and building it well is a skill worth training.
Training and inference are mergingInference engineers now write training pipelines, RL rollouts bottleneck on inference speed, and Baseten reports running GPU kernels inside their inference engine that GLM-5.2 wrote for itself from its own profiling traces. Plus the argument that continual learning belongs in the KV cache rather than in the weights.

Graph

The whole notebook as a map →