The person who built Claude Code doesn't write prompts anymore. He writes loops. That sounded like hype at first, so I went and tested it myself.
Boris Cherny is the creator and head of Claude Code at Anthropic, the very person who built the tool I use every day. In early June he sat down for Acquired Unplugged (hosted by WorkOS, June 2, 2026) and said one line that has been bouncing around every other dev feed since:
"I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops."
Put plainly: he no longer prompts Claude. He has loops running, and it's the loops that prompt Claude and decide what to do. His job is to write the loops. In the same conversation he mentioned that he had uninstalled his IDE back in November, because he hadn't opened it for a month. This isn't an anecdote pulled from a hype thread: the statement is verified across more than half a dozen outlets, and Fortune confirms the substance.
My first reaction was skepticism. "I just write loops now" reads exactly like the kind of stage-line that lands online and falls apart in practice. So I didn't take it on faith. I built it. This piece is both things: what Cherny actually means, and the autonomous loop I genuinely put into one of my projects.
What Cherny actually means (and what's paraphrase)
A bit of honesty first: the core quote above is verbatim. But "Loop Author" and the "four-component checklist" that spread afterwards? Cherny never actually said those; that's other people's framing, not his quote.
The real lesson sits underneath the quote, and it's robust. The bottleneck when working with a strong model is shifting. Typing the perfect prompt is no longer the scarce resource; building the system around the model is: the goal, the check, the guardrails, the review. Once you've got that, you don't need the buzzwords at all.
/loop vs /goal: the practical part
The nice thing is you don't have to argue about "loops" in the abstract, because Anthropic has already shipped two of them as real commands in Claude Code. Both are documented exactly as below in the official docs.
| Command | What drives it | What it's for |
|---|---|---|
| /loop | Interval-based: a fixed cadence (e.g. every 5 min) or an interval Claude picks itself, from 1 min to 1 hour. | Watching and tending. Has a built-in maintenance mode. From version 2.1.72. |
| /goal | Condition-driven: you set a completion condition; after each round a small fast model (Haiku) judges yes/no plus a reason for whether it holds. | Getting done. Ends automatically once the goal is met. From version 2.1.139. |
The one-liner that stuck with me: /loop is for watching. /goal is for finishing. /goal is the more interesting of the two, because it's essentially a built-in self-check (an automated check, or "eval"): Claude works, a second model acts as the referee and decides whether the goal is met, then it's done or it keeps going.
The single most important rule for good /goal conditions
The Haiku judge runs no commands and reads no files itself. It only judges what's in the conversation so far (the transcript). So your completion condition has to name three things: a measurable end state, the check command that proves it, and a boundary clause (a scope fence) that forbids shortcuts.
Why that matters shows up in the classic failure case. Set "all tests pass" as your goal, and the cheapest way to make it true is to delete the tests, and a judge that only sees the transcript waves it through. With a scope fence, the same condition looks very different:
What I built
Enough theory. In one of my research projects, an autonomous multi-agent system searches scientific studies on dietary supplements, scores their evidence, and writes audited articles from them. Systems like that run regularly here in automated passes, and some fail. That's exactly where I built a classic loop: error logs → issue → fix → pull request. It comes in two halves. Loop A, the producer, turns failures into issues. Loop B, the consumer, turns those issues into fixes and pull requests. The first half is harmless, the second is the real test of nerve, so let's start with the harmless one.
A Python script reads failed pipeline runs (status failed, crashed, abandoned) from the database, groups them by a normalized error signature, and collapses identical errors into one (this is called deduplication, "dedup" for short), so exactly one GitHub issue is created per signature. "Normalized" means changing details like IDs, numbers and timestamps are stripped out, so the same error type always gets the same stable fingerprint. The script uses no language model for this; it's pure, rule-based logic (the same input always yields the same result), so it's free.
The decisive test was the deduplication. I checked it against three failures, two of them with the same error: a timeout while loading studies from PubMed, differing only in their study IDs. That's exactly the kind of error that shows up constantly in real operation whenever an external API acts up, and it spawns a fresh run every time. Naively that's three separate issues, the start of an issue storm that floods your board with the same problem over and over. With the normalized signature the two identical errors were correctly merged into one: one issue, not three. That's exactly the difference between a useful loop and one that floods your issue board.
The whole thing goes live through a scheduled GitHub Action that creates the issues, with a second safeguard against duplicates (does an open issue for the same error already exist?) and a dry-run mode for testing it safely. That's the producer. The exciting part comes now.
Loop B is the risky half: it reacts to the auto-fix label, lets Claude fix the issue, and opens a pull request. This is exactly where the system decides whether it's a useful tool or a hazard. Four safeguards make the difference. It locks the issue (wip label) before it starts, so no second run grabs the same one. It verifies every fix against the same signal as CI (ruff, mypy, pytest), and a PR is created only when everything is green. It may not touch critical files (cost limits, model configuration, DB migrations are off-limits). And the PR is always a draft: I merge, not the agent.
The non-obvious point lives in that verification step, and it's the reason a loop like this works at all. Remember how the judge in /goal only sees the conversation (the transcript)? That's the Achilles' heel: a working agent can simply claim "all tests green" without ever running them, and a judge that only reads the text believes it. The fix isn't magic, it's discipline: the condition demands that the real command output be in the transcript. Not "the tests pass," but "pytest was run and its output shows 0 failures." The agent can only fool its own referee if you leave it the gap, so you don't.
I tested it for real
Theory is cheap, so I tested Loop B against a real, controlled bug. I deliberately slipped a small fault into the code, an off-by-one in the circuit breaker, opened an issue for it, and set the auto-fix label. From there I did nothing but watch.
What the agent did autonomously
It locked the issue, found the faulty line, and changed exactly that one, without touching any off-limits file. It ran the tests and waited until they were green. Then it pushed its own branch and opened a draft PR that closes the issue. From the moment I set the label to the finished pull request, not a single keystroke came from me.
What mattered wasn't that the fix worked, but how much discipline sits in the safeguards. The agent touched only the one allowed file. It cleared the eval gate only once the real pytest output was in the transcript, not on a bare claim. And the result was a draft, not a finished merge. The last step was mine, by design.
That's not a glossy result, it's an honest one: an agent that does the boring, verifiable work autonomously, and a human who keeps the last call. And a loop isn't good when it impresses you, but when you can trust it in failure as much as in success. When a run fails, this one releases its lock again, leaves an honest comment, and touches no code. That cleanup discipline is exactly the difference between a useful tool and a hazard.
What's proven, and what's still aspiration
This is where serious framing parts ways with hype. More is proven than you'd think: Cherny's quotes are verified, /loop and /goal are real products, GitHub's Copilot Coding Agent really does turn an issue into a pull request, and "ralph" (a well-known loop method) works for new, from-scratch projects (greenfield). But the limits are just as real.
- Agents detect well and prioritize badly. A widely-cited test run by the software firm EPAM made this plain: 15 AI agents had to find one real, deliberately-hidden security vulnerability in roughly 350,000 lines of production code. They often found it, but one agent buried it under 46 more inflated "Critical" false alarms. The flaw was found, just unfindable in the noise. Detecting is the strength, ranking by importance the weakness.
- Mature codebases are not loop terrain. Geoffrey Huntley, the creator of the ralph method, puts it bluntly himself: "There's no way in heck would I use Ralph in an existing code base." Loops shine on new projects and well-checkable routine work, not in a grown production system.
- There are no reliable cost numbers. No verified figures exist for how many tokens (and therefore how much money) loops like these burn through. So: set caps, watch spend, and never let one run unattended against a metered (pay-per-use) API.
The five guardrails that made the difference in my producer/consumer case
These five aren't a universal law, they're what made my specific logs-to-PR loop safe. A different loop needs different guardrails. What stays is the principle behind them: before you arm a loop, think about where it could do damage, and build a brake for each of those spots.
The five guardrails that made the difference in my producer/consumer case
- Collapse duplicates (dedup) in the producer, so no issue storm builds up.
- Lock a task the moment it's picked up, so two helpers (workers) don't work the same task at once.
- A check gate via
/goalwith a scope fence, so the agent can't game the goal (e.g. deleting tests instead of making them pass). - Agent may only read; it writes only through an allowlist (a list of explicitly permitted actions), so the worst-case damage stays small.
- A human decides the merge (the merge gate), always.
Takeaway
Cherny is right, directionally. But the lesson isn't "stop thinking." It's that the leverage now lives in the system around the model: the goal, the automatic check (eval), the guardrails, the review. That's exactly what I felt building this loop in supplement. The hard part wasn't telling Claude something. The work was in the error signature that doesn't spam the board, the verification gate the agent can't game, and the cleanup behavior that rolls back cleanly on every failure.
My advice if you want to start: begin small, with a /goal on a convergent, zero-risk task. Climb the ladder only as far as you've cleanly built the guardrails. And keep the merge gate in human hands forever.
Tools used:
Building a system like this (goal, eval, guardrails, review) is exactly the kind of work I do as an AI consultant. Wondering how an autonomous loop could take real, recurring work off your team's plate without becoming a liability? Get in touch.