Loop Engineering: Stop Writing Prompts. Design Systems That Prompt Themselves.

June 2026. Two statements lit up the AI developer community.

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

Almost simultaneously, Peter Steinberger of OpenAI (creator of PSPDFKit) tweeted:

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

That tweet hit 1.5 million views. Then Addy Osmani, Google's Engineering Director for Chrome, published a definitive essay giving the movement its name: Loop Engineering.

Jensen Huang echoed the signal: "Nobody writes prompts anymore. The new job is to write and handle loops." Andrew Ng went further, predicting prompts would be dead within three to six months.

What Just Happened?

For two years, working with coding agents looked like this:

Human proposes task → Agent executes → Human reviews → Human points out issues → Agent fixes → Human reviews again

The human served as the manual orchestrator—constantly deciding what to do next, whether the agent understood the intent, whether the result was correct, what context was missing, and when to stop.

The problem is obvious: human attention is a finite resource. You can write only so many prompts in a day. But a scheduled loop can run indefinitely.

The core insight of Loop Engineering: the leverage point shifts from "write a better prompt" to "design a better prompt-generation system."

The Five Building Blocks of Loop Engineering

Addy Osmani decomposed Loop Engineering into five primitives, plus persistent memory:

1. Automations — The Heartbeat

Without scheduling, it's just a one-off run. Claude Code's /loop command and cron-based scheduled tasks, Codex's Automations panel, GitHub Actions cron—you define the cadence, the system triggers discovery, triage, and execution on its own.

2. Worktrees — Parallelism Without Collision

Two agents editing the same file is a guaranteed merge disaster. Git worktrees give each agent its own checkout on its own branch. Codex builds this in; Claude Code provides --worktree and isolation: worktree on sub-agents.

3. Skills — Stop Explaining Your Project Every Time

A SKILL.md file encodes project conventions, build commands, coding standards, and domain knowledge. Without skills, the loop re-derives your entire project from scratch every cycle. With skills, knowledge compounds—write it once, the loop accumulates it.

4. Plugins & Connectors (MCP) — Let the Loop Actually Do Things

Read-only filesystem access isn't enough. MCP connectors let the loop read and write Linear tickets, post Slack notifications, query databases, create GitHub PRs. Both Codex and Claude Code speak MCP, so a connector written for one works in the other.

5. Sub-agents — Separate the Maker from the Checker

This is the most important structural pattern. The agent that wrote the code cannot grade its own homework. A second agent—different prompt, sometimes a stronger model—handles verification. This separation is the only reason you can walk away from an unattended loop.

+ Persistent State

Models have no cross-session memory. The loop must read and write something that persists: a STATE.md file, a Linear board. A good state file answers three questions: What is currently being worked on? What was tried last time and what happened? What is waiting for a human?

Seven Production-Ready Loop Patterns

Cobus Greyling launched the GitHub repository cobusgreyling/loop-engineering, documenting seven battle-tested loop patterns with failure stories and cost estimates:

Pattern	Cadence	Cost	Purpose
Daily Triage	Daily	Low (~50k tokens)	Morning report: what needs your attention today
PR Babysitter	5-15 min	High (~250k tokens)	Watch for new review comments, auto-respond with minimal diffs
CI Sweeper	5-15 min	Very high (~500k tokens)	Detect CI failures → identify root cause → generate fix
Dependency Sweeper	6h-1d	Medium	Detect outdated dependencies, generate security patch PRs
Changelog Drafter	Daily	Low	Summarize commits and PRs into a changelog draft
Post-Merge Cleanup	6h-1d	Low	Delete feature branches, check for leftover TODOs
Issue Triage	2h-1d	Low	Auto-classify new issues, tag, assign reviewer

Real-World Failure Stories

The repository's failure logs are more valuable than the success stories:

CI Sweeper — Killed on day 4. They skipped the L1 reporting phase, went straight to auto-fix, had no branch allowlist, no budget cap—and burned ~8 million tokens in 48 hours. Lesson: always start with reporting only, then gradually open permissions.

PR Babysitter — Infinite fix loop. A flaky e2e test triggered four consecutive code-change attempts to "fix" an environment problem. Solution: hard cap of 3 attempts + flake classification and isolation.

Verifier Theater — "Approved" but CI was red. The verifier's prompt was too vague ("looks good"), it never ran actual tests, and it shared the same model and context as the implementer. Solution: verifier must execute tests and report output; prompt it to "find reasons to reject," not "confirm it passes."

Three Concepts to Stay Vigilant About

Loop Engineering is not a silver bullet. Addy Osmani flagged three persistent risks:

Intent Debt — Anything you haven't clearly specified, the agent fills in with a confident guess. Skills are the only way to pay this down.

Comprehension Debt — The faster the loop produces code, the faster you fall behind your own codebase. Automation shifts the cognitive burden from writing to reading.

Cognitive Surrender — The most dangerous trap. When the loop runs itself, you stop having opinions. Addy's warning: "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."

Phased Rollout: L1 → L2 → L3

Every loop pattern recommends progressive deployment:

• L1 (Reporting) — Observe and report only. No actions taken. Run for one week, calibrate accuracy.
• L2 (Assistance) — Propose fixes but don't auto-apply. Open only after trust is established.
• L3 (Autonomy) — Handle low-risk operations automatically, protected by path allowlists.

Every loop must have a documented stop condition, a budget cap, and a kill switch.

Closing

In 2023, we learned how to write good prompts. In 2024, we learned how to orchestrate multiple agents. In 2025, we learned how to configure agent harnesses. In 2026, we're learning how to design closed-loop systems that let agents work autonomously and continuously.

Addy Osmani's closing line is worth tattooing on the wall:

"Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."

The higher the degree of automation, the stronger your engineering judgment needs to be. Loop Engineering is not an invitation to coast—quite the opposite. It demands more human engagement, not less.