Overview
Matthew Berman breaks down loop engineering — the emerging coding meta where instead of manually prompting your AI agent step by step, you design loops with triggers and verifiable goals that let agents run autonomously until the work is done. He explains why Peter Steinberger (OpenAI) and Boris Cherny (Anthropic) went viral talking about loops simultaneously, demonstrates real loop setups in Cursor and Claude Code, tackles the cost and complexity criticisms head-on, and connects loop engineering to the broader trajectory toward recursive self-improvement and autonomous software factories.
1 The Viral Moment
The video opens with the catalyst: over a single weekend, "loops" became the hottest topic in AI coding. Two key figures drove the conversation:
- Boris Cherny (Anthropic) — his interview went absolutely viral: "I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and kind of figuring out what to do. My job is to write loops."
- Peter Steinberger (OpenAI) — his tweet hit 5 million views in under 24 hours: "Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
Berman frames this as a paradigm shift: only a handful of people in the world truly know how to use loops, but this is the future of software engineering.
2 What Is a Loop?
Berman contrasts the traditional agentic workflow with the loop paradigm:
- Traditional workflow — you prompt your agent → agent writes code → you wait → you prompt again. The human is the bottleneck in every iteration cycle.
- Loop workflow — you specify an end state (a goal), and the agent not only starts itself but continues iterating until that goal is met. The human designs the loop and then steps away.
A loop requires only two things:
- A trigger — what kicks off the loop (event, schedule, or human initiation)
- A goal — a verifiable end state. The goal must be checkable: either deterministically (tests pass, no errors) or via LLM judgment (an AI evaluates whether the goal has been reached).
3 Triggers & Goals — The Two Primitives
Every loop boils down to two primitives:
Goals: Deterministic vs. Non-Deterministic
- Deterministic goals — all tests pass, a function executes without errors, CI is green. Clear, machine-checkable success criteria.
- Non-deterministic goals — an LLM or agent decides whether the goal has been completed. More powerful but also more fragile and token-expensive.
Three Types of Triggers
- Event-based — an action happens (e.g., a PR is opened, a commit is pushed)
- Schedule-based — a cron job fires on a recurring interval (every 30 minutes, hourly, daily)
- Human-initiated — a person types out the end state and says "go"
4 Loops in Practice — Cursor Automations
Berman demonstrates a real loop setup using Cursor's Automations tab:
- Trigger — every time a PR is opened in his project "Astro Hub"
- Instructions — review the PR, look for potential issues, fix them automatically, commit back to the same PR, make sure all tests pass (and fix them if they don't), ensure all CI is green
- Outcome — the entire code review, fix, and CI verification cycle runs without human intervention
He emphasizes that this is truly a "set it and forget it" automation — once the PR is opened, the loop handles everything until the goals are met.
5 Deterministic vs. Amorphous Goals
Loops get complicated when goals become amorphous. "All tests pass" is clean and deterministic. But "build this feature in my product" is a fundamentally different kind of goal.
- You have to define the full spec upfront — the loop can't iterate toward a goal it can't verify
- Feature building is inherently exploratory — figuring out what parts you need, iterating, discarding approaches. Berman acknowledges he is "extremely involved" in this process
- Loop engineering for features means removing yourself — you give the loop the end goal of a completed feature and walk away. This requires extraordinary discipline in specification
6 Types of Triggers Deep Dive
Berman expands on trigger types with concrete examples:
- Schedule triggers — cron jobs that fire on a recurring interval. "Every 30 minutes, every hour, every day, every week" — the loop starts on that schedule
- Action triggers — tied to specific events in your development workflow (PR opened, branch created, issue assigned)
- Human triggers — you type out the desired end state and manually kick off the loop. The human is still the trigger, but once started, the loop is autonomous
He also notes you can add complexity: give skills to your loops, code them to get smarter as they iterate, and chain multiple loops together.
7 Loops in Claude Code — The /loop Command
Claude Code has a built-in /loop command that makes loop engineering accessible:
- Syntax —
/loop 5 minutesfollowed by the goal. The agent kicks off every 5 minutes, evaluates progress, and continues building - Humorous example —
/loop every 5 minutes "Reach feature parity with Google"— obviously impractical but illustrates the concept. As Berman quips: "I'm going to have a trillion-dollar token bill." - Practical example —
/loop every 5 minutes "Compare what we have built with our full spec (spec.md). Continue building until we complete the full spec." - Single-shot loops — you can also just say
/loopwithout a schedule to run a single continuous loop until the goal is reached
Every 5 minutes, a fresh agent kicks off, determines what's left to build from the spec, and starts building. It keeps looping until the spec is fully implemented.
8 The Cost Problem
Berman addresses the elephant in the room head-on: loop engineering is extremely expensive today.
- More abstraction = more tokens — the further you remove the human from writing actual code, the more tokens the agent consumes
- Non-deterministic goals are especially costly — when the agent can't definitively verify success, it risks burning tokens indefinitely
- Historical perspective — "What's expensive today is cheap tomorrow. That has been proven time and time again throughout the history of technology." As tech diffuses and production becomes more efficient, prices drop
He acknowledges the irony: at a time when companies are actively trying to cut their AI bills, introducing loop engineering sounds "completely crazy to most people."
9 The 1% Bifurcation
There is a huge bifurcation in engineering right now. Only the top 1% of 1% are using techniques like loop engineering, because:
- They're enabled to experiment — they work at companies that encourage frontier techniques
- They have infinite or very high token budgets — only a few companies in the world can really afford this
Berman points to the concrete numbers: Peter Steinberger showed $1.3 million in monthly token usage a few weeks prior. Both Steinberger (OpenAI) and Cherny (Anthropic) work at companies that give their employees unlimited tokens — which is precisely why they can experiment with loops at scale.
10 Automation vs. Loop — The Key Distinction
Berman draws a precise distinction:
- Automation — executes a series of prompts or lines of code in sequence. No decision-making inside the process.
- Loop — has a decision inside it. The loop actively determines whether the goal has been reached or not. It's not just executing steps — it's evaluating outcomes and deciding whether to continue.
This decision-making capacity is what separates a loop from a simple CI pipeline or cron job. The loop has agency over its own continuation.
11 The Recursive Self-Improvement Horizon
Berman closes with the philosophical endgame: will humans always be required in the loop?
- Today — humans are required because we decide the goal, the direction. "I am saying, 'Here's the direction we should go in. Go.'"
- The software factory vision — "We will continue to build the software factory that builds the software. We as engineers will gradually and then suddenly no longer even be writing prompts to our agents."
- The recursive self-improvement threshold — when AI can set its own goals, decide what features to build, what products to build, what companies to build, it's designing its own factory. That is the point of recursive self-improvement.
He references Anthropic's recent essay on recursive self-improvement as further reading on where this trajectory leads.
🎯 Key Takeaways
🔑 Key Takeaways
- Loops replace prompting — instead of manually prompting your agent step-by-step, design loops with triggers and verifiable goals that run autonomously
- Two primitives — every loop needs a trigger (event, schedule, or human) and a goal (deterministic or LLM-evaluated)
- Parallel to reinforcement learning — loops need verifiable reward signals, just like RL agents need verifiable rewards to learn
- Deterministic goals are easy; amorphous goals are hard — "all tests pass" is trivial to verify; "build this feature" requires exhaustive upfront specification
- Already available in tools — Cursor Automations and Claude Code's
/loopcommand make basic loop engineering accessible today - Extremely expensive today — Peter Steinberger's $1.3M monthly token bill illustrates the cost reality of frontier loop engineering
- The 1% bifurcation — only engineers at companies with unlimited token budgets (OpenAI, Anthropic) can fully experiment with loops right now
- Loops ≠ automations — a loop has decision-making inside it (evaluates whether the goal is met), while automations just execute a sequence
- Cost will drop — historical technology patterns show that what's expensive today becomes cheap tomorrow as production scales
- Trajectory toward recursive self-improvement — when AI can set its own goals and design its own factories, we reach the recursive self-improvement threshold
🔗 Resources & Links
- Peter Steinberger's viral tweet on loops — the 5M-view tweet that catalyzed the loop engineering conversation
- Peter Steinberger's $1.3M token usage — the concrete cost data behind frontier loop engineering
- Anthropic — Recursive Self-Improvement essay — Anthropic's analysis of where autonomous AI systems are heading