What Is Loop Engineering, Really? I Didn't Explain It Well Last Time — Let's Start Over

This is the English version of a Chinese original.

In my last piece about Loops, a lot of people said: I sort of get the reasoning, but I still couldn’t tell you what a Loop actually is.

Not your fault. Mine. That piece spent too much effort on “why Loops matter” and not enough on “what a Loop actually looks like.”

Let’s start over today. No hype, no iteration anxiety — just one question:

When people in AI say “loop engineering,” what’s actually inside?

Imagine you’re opening a hundred hotpot restaurants

Forget AI for a second. Think of something you’ve definitely experienced — hotpot. (It’s a Chinese communal meal: a simmering pot of broth at the center of the table, everyone cooks their own ingredients in it.)

Say you made a beef-tallow broth that all your friends loved. You want to open a restaurant.

For the first restaurant, you supervise everything yourself. When each table sits down, you ask whether they want spicy or half-and-half broth; you mix the base by hand; you watch the kitchen; you taste every pot before it goes out, and if it’s off, you remake it. If a customer complains, you go apologize personally.

That restaurant will do well. But there’s a problem: the moment you leave, the whole restaurant stops.

Now you want a second location. You can’t stand in two kitchens at once. What do you do?

You sit down and write an operations manual.

The manual covers three things:

First, who does what. How to mix the base — how many grams of Sichuan peppercorns, how many blocks of tallow, what temperature counts as done. The chef follows it without you reciting over their shoulder.

Second, check it yourself. Before each pot leaves the kitchen, the chef on duty tastes it. Too salty? Too bland? They know without you driving over from the other location to say “this one’s bad.”

Third, send back anything substandard. A pot that misses the mark gets dumped and remade. No phone call to the boss asking “what do I do with this one.”

Manual done. The first restaurant learns it; the second copies it; the tenth copies it; the hundredth runs the same way.

You’re on a beach vacation, and all hundred restaurants are serving correctly.

That whole system — write the manual, set the standards, let every location run, check, and fix itself — is loop engineering.

Swap “restaurant” for “AI,” swap “chef” for “AI assistant,” swap “operations manual” for the set of rules you write for it. Same thing, exactly.

Take one apart: a Loop has exactly three components

Don’t be intimidated by the word “engineering.” There are three things inside a Loop:

One, task assignment. Who does what, to what standard. In the restaurant, that’s the recipe. In the AI world, it’s the rules and instructions you write.

Two, self-check. After doing the work, check it yourself. The chef’s taste test is the self-check. The AI finishes a pass, then reviews its own output and finds its own flaws.

Three, the cycle. Didn’t pass? Go back and redo it. Passed? Release it and move to the next step. You don’t have to shout “do it again” — the rule is written down, so it sends itself back.

All three together make a Loop. Miss any one and it’s not. Assignment without self-check is just writing a prompt. Self-check without cycling is one review and done. All three assembled, spinning on their own without you watching — that’s a Loop.

What Boris was actually saying

Last time I mentioned a quote from Boris Cherny, who leads Claude Code (Anthropic’s AI coding tool), and glossed past it. This time, word by word.

The original:

“Grill me on these changes and don’t make a PR until I pass your test.”

In plain terms, word by word:

“Grill me” — interrogate me. Find my flaws. Review me like an interviewer.

“on these changes” — about what I just changed. Not a general chat; about my specific output.

“don’t make a PR” — don’t submit. A PR (pull request) is the formal way code changes get handed in. Meaning: if I haven’t passed, nothing gets submitted.

“until I pass your test” — until I pass the exam you set for me.

All together: AI, you’re the examiner now. My changes are yours to review. Until I pass your bar, nothing ships.

Notice what happened?

The exam ran in reverse. It’s not the human testing whether the AI did well — it’s the AI testing whether the human did well.

And the “write the test → grade it → release or reject” process is automatic. The AI writes the test, the AI grades it, and failures bounce back to you automatically for another pass. Boris doesn’t need to seat a human next to the loop watching it.

His quote is a usage tip. But take it apart — assignment, self-check, cycle: all three components present. That’s a Loop running.

In restaurant terms: Boris didn’t write a recipe; he wrote an acceptance manual for the AI. The AI holds the manual, inspects on its own, and decides for itself whether to pass or reject.

A table makes it obvious

Writing prompts is commanding the AI line by line. Writing a Loop is setting the rules so the AI does the work, checks itself, and fixes its own failures. It spins whether you’re there or not.

A Loop isn’t what you think it is

The term has drifted as it spread. Three misconceptions come up constantly; let’s kill them one by one.

Misconception one: “A Loop makes the AI smarter on its own.”

No. An AI running inside a Loop a thousand times still has the same brain — not a bit smarter. What a Loop does is give it an automated process — do, check, fix, check again. The process turns; the brain doesn’t change. Your washing machine doesn’t become a better washer after ten thousand loads.

Misconception two: “A Loop is an infinite loop — what if the AI can’t stop?”

Every properly designed Loop has an exit condition. Like the restaurant rule: taste it; if it passes, serve it; if not, remake it — but not forever. Three failed attempts? Escalate to the head chef. There’s a floor and a kill switch. An infinite loop is a loop without rules. The entire point of loop engineering is to nail the rules down — including when to stop.

Misconception three: “This is a programmer-only game.”

You design Loops every day; you just don’t call them that.

Ever trained an intern or a new hire? You’ve said something like — “check your own work before you give it to me; fix what’s off yourself. If it’s still wrong after two tries, come find me.”

That is a Loop. Assignment, self-check, retry-on-failure, escalation after N tries. Identical to an AI Loop. The only difference: the executor changed from a person to an AI.

The smallest Loop you can try today

By now, you should be able to explain to someone else what a Loop is.

You don’t need to code, and you don’t need to build a system. Next time the AI finishes something for you — an email, meeting notes, whatever — don’t take delivery right away. Add one line:

“Check it yourself, fix anything off, then give me the final version.”

That’s it. You just bolted on the “self-check” and “cycle” components. It’ll finish, review its own output, fix what it finds, and hand you the result.

Want to go one step further? Add an exit rule: “review at most two rounds, then give me the final version.”

That keeps it from checking forever. Rules plus a kill switch.

You just built your first Loop.

Going from “personally commanding every step” to “letting it spin on its own” — crossing that line turns you from an operator into a system designer. It’s not a programmer’s privilege; it’s a threshold everyone who works with AI will cross sooner or later.