I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.
- Boris Cherny, creator and head of Claude Code at Anthropic.
For roughly two years, the skill everyone chased was prompt engineering. Write a good prompt, share enough context, read the output, write the next prompt. You held the agent like a tool, one turn at a time.
That era is quietly ending.
In mid-2026, three voices converged on the same idea within days of each other. Boris Cherny (Claude Code) said his job is now writing loops. Peter Steinberger (creator of OpenClaw) told millions of developers: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." And Addy Osmani (Google) gave the pattern its name in a widely-shared post: Loop Engineering. This article breaks down what loop engineering actually is, the problems it solves, how it solves them, a working code demo you can run today, and the honest trade-offs nobody puts in the hype threads.
What Is Loop Engineering?
Loop engineering is replacing yourself as the person who prompts the agent. You design a system that does the prompting instead.
A loop is a recursive goal: you define a purpose and a verifiable stopping condition, and the AI iterates, discovering work, implementing it, verifying it, recording progress until the condition is true. You are no longer in the loop. You are above it.
Think of the hierarchy like this:
- Prompt engineering : you write one good instruction.
- Context engineering : you assemble the right information around the instruction.
- Agent harness engineering : you build the environment one agent runs inside.
- Loop engineering : you build the system that runs the harness on a timer, spawns helpers, checks its
The old workflow: write prompt → read output → write next prompt (you are the loop).
The new workflow: design loop once → loop discovers work → loop assigns agents → loop verifies → loop records state → repeat (you review and steer).
The Problems Loop Engineering Solves
Problem 1: You are the bottleneck
In manual prompting, nothing happens unless you type. Every turn waits on a human. Agents in 2026 can run for hours autonomously, Claude Opus-class models have run unattended for nearly five hours on hard tasks but a human-driven chat caps them at your typing speed and attention span. The agent is idle 95% of the time, waiting for you.
Problem 2: Agents forget everything between sessions
Every session starts cold. The model re-derives your project's conventions, build steps, and hard-won lessons from zero or worse, fills the gaps with confident guesses. That's what "Osmani" calls intent debt: unstated intent that gets re-paid (or re-guessed) every single run.
Problem 3: The agent grades its own homework
An agent that wrote the code is far too generous when reviewing it. "It's done" is a claim, not a proof. Without independent verification, autonomous runs compound errors instead of fixing them.
Problem 4: Parallel agents collide
The moment you run more than one agent on a repo, they start overwriting each other's files the same disaster as two engineers committing to the same lines without talking.
Problem 5: Recurring work never gets automated
CI failure triage, dependency bumps, flaky test hunts, issue labeling, daily bug sweeps this work is boring, endless, and perfectly suited to agents. But nobody prompts an agent to do it every morning, because you'd have to show up every morning to do the prompting.
How Loop Engineering Solves Them: The Six Building Blocks
A loop that actually runs unattended is not one long prompt. It's a small system with five capabilities plus one memory. Remarkably, both Claude Code and OpenAI's Codex now ship all six natively the loop shape has become tool-agnostic.
- Automations : the heartbeat
Scheduled runs that do discovery and triage by themselves. This solves Problem 5.
- Claude Code: /loop re-runs a prompt on a cadence (from one-minute intervals to multi-day windows), cron-scheduled tasks, Routines for cloud-scheduled automations, lifecycle hooks, or GitHub Actions for runs that survive your laptop closing.
- Codex: the Automations tab pick a project, a prompt, a cadence; findings land in a Triage inbox, empty runs archive themselves.
The killer in-session primitive is /goal: keep working across turns until a condition you wrote is verifiably true "all tests in test/auth pass and lint is clean" and walk away.
- Worktrees : isolation for parallelism
Git worktrees give each agent its own working directory on its own branch, sharing repo history. Edits literally cannot collide. This solves Problem 4.
- Claude Code: git worktree, the --worktree flag, or isolation: worktree on a subagent so each helper gets a fresh, self-cleaning checkout.
- Codex: built-in worktree per thread.
Power users report running 10–15 parallel agents this way.
- Skills : codified project knowledge
A skill is a folder with a SKILL.md your conventions, build steps, and "we don't do it like this because of that one incident" written once, read by the agent every run. This solves Problem 2. Without skills, the loop re-derives your project from zero every cycle. With them, it compounds.
- Plugins & Connectors (MCP) : hands on real tools
A loop that only sees the filesystem is a tiny loop. MCP connectors let it read your issue tracker, query a database, open the PR, update the Linear ticket, and ping Slack when CI goes green. This is the difference between an agent that says "here's the fix" and a loop that ships the fix.
- Sub-agents : separate the maker from the checker
The most important structural idea in the whole pattern. One agent (or model) writes; a different agent with different instructions verifies. This solves Problem 3. Claude Code's /goal bakes this in: a separate model grades whether the stopping condition is met, so the worker never grades its own homework.
- Claude Code: subagents in .claude/agents/, agent teams.
- Codex: subagents as TOML in .codex/agents/ e.g., a strong model on high reasoning effort as your security reviewer, a fast read-only model as your explorer.
- State : the memory spine
A markdown file, a progress log, or a Linear board anything that lives outside the conversation and records what's done and what's next. Sounds too dumb to matter. It's the single trick every long-running agent depends on: the model forgets between runs; the repo doesn't. This also solves Problem 2 at the task level, and it's what lets tomorrow's run pick up exactly where today's stopped. Together with automations, it dissolves Problem 1 the loop works while you sleep.
What One Real Loop Looks Like
Here's the reference shape (adapted from Osmani's own daily loop):
- An automation fires on the repo. Its prompt calls a triage skill that reads yesterday's CI failures, open issues, and recent commits, and writes findings into STATE.md.
- For each finding worth doing, the loop opens an isolated worktree and dispatches a maker sub-agent to draft the fix.
- A checker sub-agent reviews the draft against the project skills and existing tests.
- Connectors open the PR, link the ticket, and post to Slack.
- Anything the loop can't handle lands in a triage inbox for you.
- STATE.md records what was tried, what passed, what's still open. Tomorrow's run resumes from there.
Sources & further reading: Addy Osmani, "Loop Engineering" (addyosmani.com); The New Stack's coverage of loop engineering; Boris Cherny's fireside chat at Meta's Scale conference and CNBC interview; Claude Code docs on Routines (code.claude.com/docs/en/routines); OpenAI Codex Automations docs.
If you build a loop from this article, I'd love to see it !! reply with what you automated first.
