Loop Engineering: Why Writing Prompts No Longer Matters—Designing Loops Does

Three Sentences That Shook the Developer Community

In June 2026, three statements from industry leaders simultaneously detonated across the dev community.

Peter Steinberger, founder of PSPDFKit (now at OpenAI), posted a tweet that racked up over 8 million views: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

Boris Cherny, head of Claude Code at Anthropic, said in an interview: "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."

Days later, Addy Osmani, Director of Google Cloud AI and former Chrome DevRel lead, published a blog post and gave it a formal name—Loop Engineering.

The community wasted no time. By July 2026, the cobusgreyling/loop-engineering GitHub repo had 210+ stars, containing 7 production patterns, 3 CLI tools, security guides, and real failure cases. A forum discussion had turned into a full-fledged engineering practice in under two months.

Four Paradigm Shifts: Handing Over Control

To understand why Loop Engineering erupted right now, trace the evolution of how developers interact with AI over the past two years:

Phase	Timeframe	Core Skill	Developer Role
Prompt Engineering	2023-2024	Write precise prompts	Instruction giver
Context Engineering	2024-2025	Design the model's information environment	Context architect
Harness Engineering	2025-2026	Configure the agent's runtime environment	Environment builder
Loop Engineering	2026	Design self-running closed-loop systems	System designer

Each shift moves the developer one layer up. From writing every instruction to designing the system that writes instructions. You step off the operating console and behind the design desk.

What Is a Loop, Really?

Addy Osmani's definition is refreshingly direct:

Loop Engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

The "loop" is a recursive goal: you define a purpose once, and the AI iterates until the task is genuinely complete. It is not you reading output and typing the next command. It is an automated system that discovers work, dispatches tasks, verifies results, records progress, and decides what comes next.

Osmani distills it into a formula:

Loop = Trigger + Task Policy + Execution + Verification + Persistent State + Stop/Retry/Escalation

Verification and Persistent State are the two that matter most. A loop without reliable verification is just spinning. A loop without persistent state starts from scratch every cycle.

Five Components + One Memory Layer

Osmani breaks a complete loop into six elements—all of which are now built into both Claude Code and OpenAI Codex:

1. Automations

The system actively seeks work instead of waiting for instructions. Analyze yesterday's CI failures every morning. Scan for dependency vulnerabilities nightly. Periodically triage open issues. The agent shifts from "waiting for commands" to "proactively discovering work."

2. Worktrees

When multiple agents run in parallel, Git Worktree creates isolated working directories for each task. One agent's changes never pollute another's checkout. Conflicts only surface at merge time, where they belong.

3. Skills

Encode project knowledge, team conventions, and best practices into SKILL.md files. The agent reads them automatically on every run. Write once, apply forever. Without Skills, every loop cycle re-derives the entire project from scratch.

4. Plugins & Connectors

Built on the MCP standard, connectors let agents interact with GitHub, Linear, Slack, databases, and monitoring systems. A loop limited to the filesystem can do very little. Connected to real systems, it can create PRs, update tickets, and send notifications automatically.

5. Sub-agents

Separate the executor from the reviewer. The model that writes code is overly lenient when grading its own work. A second agent with different instructions catches what the first one rationalized away. This is the mechanism that makes unattended loops trustworthy.

+1: Persistent State

Models forget. Code repositories don't. The loop must write progress, attempted approaches, and unresolved issues into external storage—a Markdown file, a Linear board, a database. This is what lets the afternoon loop pick up where the morning loop left off.

/loop and /goal: Two Primitives Worth Knowing

Both Claude Code and Codex ship two critical commands:

• /loop: Runs on a schedule. Check CI status every 10 minutes. Driven by time—"how often should I run again?"
• /goal: Runs until a verifiable condition is met. "Keep fixing the auth module until all tests pass and lint is clean." After each round, a separate smaller model evaluates whether the goal is achieved.

/goal is closer to a true closed loop. It inherently contains a persistent goal, multi-round execution, an independent evaluator, a completion condition, and automatic stopping. From a Loop Engineering perspective, /goal is more "Loop" than /loop.

A Real Morning Loop

Addy Osmani shared his own daily loop setup:

Every morning, an automation kicks off on the repo. It invokes a triage skill that reads yesterday's CI failures, open issues, and recent commits, writing findings into a Markdown file. For every actionable item, the loop creates an isolated worktree, dispatches one sub-agent to draft a fix, sends a second sub-agent to review that draft against project skills and existing tests. Connectors create PRs and update tickets. Anything the loop can't handle lands in a triage inbox for him to process.

Through this entire workflow, he typed zero prompts by hand. The loop wrote them all.

Stripe's 1300+ PR/Week Pipeline

Stripe engineer Steve Kaliski dropped a staggering number on the How I AI podcast: their pipeline called Minions merges over 1300 pull requests per week—not a single line typed by a human.

This goes far beyond vibe coding. 1300 PRs via turn-by-turn prompting would require someone to type prompts and verify results for every single one—physically impossible. Minions works at this scale because the pipeline was designed once. Every PR is auto-triggered and auto-verified. Humans only do one thing at the end: review.

Six Costs You Cannot Ignore

A loop is not a free lunch. Osmani systematically laid out six costs:

Cost	Description
Intent Debt	Every agent cycle starts cold and confidently guesses project conventions. The fix: encode them as Skills
Verification Debt	A loop that runs unattended can fail unattended. "Done" is a claim, not proof
Comprehension Debt	The faster the loop ships code, the faster you accumulate code you didn't write and haven't read
Cognitive Surrender	When the loop runs smoothly, the temptation is to stop questioning. You accept whatever it returns
Orchestration Tax	A loop can run many parallel threads, but your review bandwidth is the real ceiling
Token Costs	The same task can burn 20x more tokens in loop mode than prompt mode. Budget accordingly

Loop Is Overrated, Topology Is Underrated

At a closed-door seminar hosted by 5Y Capital in late June 2026, one insight cut through the hype:

"Loop is overrated. Topology is underrated."

Truly valuable work is not simply "make the tests pass." It is a spiral of self-iteration combined with deeply coupled topologies. Real human work—parallel, asynchronous, interruptible—resists being mirrored into a single agent's task.

This is a sobering reminder: Loop Engineering solves "how to keep running," but "where to run"—that initial directional judgment—still requires human taste and discernment.

Final Thoughts

Loop Engineering won't be the last "-Engineering" we coin. But it marks a genuine inflection point: the leverage point has shifted from "how to write a good prompt" to "how to design a system that runs itself."

Boris Cherny writes loops. Peter Steinberger runs five or six Codex loops simultaneously. Addy Osmani systematized it all.

And now the question turns to you: what will your first loop do?