The scarce skill isn’t a well-phrased prompt anymore. It’s the system that keeps prompting for you, checks its own work, and knows exactly when to stop.

For three years, working with a language model meant one loop, and you were it. You typed a request. You read what came back. You typed again, a little more precisely this time. Type, read, type — a private, manual cycle that never really had a name, because it didn’t need one. It was just how the work got done.

In the second week of June 2026, that cycle got a name, and the name exposed something uncomfortable: the cycle itself had become the bottleneck. On June 7, developer Peter Steinberger posted a single line arguing that people should stop prompting coding agents turn by turn and start designing the loops that prompt those agents instead. The post crossed six million views within days. The next day, Google engineering lead Addy Osmani published an essay that gave the idea a name and a working anatomy: loop engineering. Within the week, Boris Cherny, who leads the Claude Code team at Anthropic, described a similar shift in his own routine — he had stopped prompting Claude directly and started writing the loops that prompted it for him while he did something else.

None of this behavior was actually new. A small set of experienced agent builders had been running unattended, self-correcting workflows for months without a name for it. What June 2026 did was hand everyone else the vocabulary — and a reason to notice they were still doing the slow version by hand.

The unit of work is no longer the prompt you type. It’s the loop you design.

Four Layers, Not Four Replacements

It helps to see where this sits on the timeline. 2023 was the year of prompt engineering — getting good at phrasing a single request well. 2024 brought orchestration — chaining fixed steps together into a pipeline. 2025 sharpened into context engineering — controlling exactly what the model sees at each step, and nothing it doesn’t need. 2026 added loop engineering: designing the system that decides what happens next, without a person typing it in.

Each layer sits on top of the last instead of replacing it. A loop is still full of prompts, and every prompt inside it still needs the right context to work. What loop engineering adds is the control structure wrapped around all of it — the part that decides whether to run again, stop, or come ask you first.

A Chain Follows Instructions. A Loop Makes Decisions.

A chain is a fixed script: step one, then two, then three, in an order you decided in advance. It’s reliable precisely because nothing is allowed to surprise it. The trouble is that most real work doesn’t script that cleanly — step three often depends on what step two actually returned, and a chain has no way to notice that a test failed or a draft missed the brief entirely.

A loop is built for exactly that uncertainty. It tries something, looks honestly at what happened, and decides what to do next based on the result, rather than on what a script written yesterday assumed would happen. That reason, act, observe rhythm traces back to the ReAct research pattern from 2022, but the academic lineage matters less than the habit itself: think, do, look, and go again.

The Five Things Every Loop Actually Needs

Running a model again and again isn’t a loop — it’s a slot machine. A loop that survives contact with real work is built from five deliberate parts.

1. A finish line a machine can check. Before any instruction gets written, decide what “done” means in terms a computer can verify — not “make it good,” but “every item on this checklist is checked,” or “the output validates against this schema.” A loop with a vague finish line never knows when to stop, so it either quits too early or runs forever.
2. A verifier that isn’t the model grading its own homework. The verifier is the actual point of the exercise — the check that decides whether an output clears your bar. The most common way loops go wrong is letting the same model that produced the output also judge it; a model grading its own homework tends to hand out A’s. The more external, specific, and grounded your verifier is, the more the loop is worth trusting unattended.
3. More than one way to stop. A loop with a single exit is a loop that can run away from you. A dependable loop stacks several: the verifier confirming the goal is actually met, a hard ceiling on iterations, a budget cap on time or tokens, and a check for whether recent attempts have stopped making any real progress at all. Any one alone still lets a loop misbehave. Together, they make a loop safe to leave unattended.
4. Memory that survives a restart. A loop that forgets everything the moment it crashes has to relearn the same lesson every time. Real state — files, task lists, a running log of what’s already been tried — means a loop that dies on attempt thirty can pick up from twenty-nine instead of starting over.
5. A place where a human has to say yes. Decide in advance exactly which actions require you specifically, before anything gets sent, published, deployed, or deleted. A loop can research, draft, and revise all day without you. Irreversible actions deserve a pause — not because the loop can’t be trusted, but because some mistakes are worth catching before they happen rather than after.

Building Your First Loop, In Order

• Pick something you already do by hand, repeatedly. Choose a task where you could describe a good result if someone asked. A messy, subjective task is the wrong place to start; a narrow, checkable one is the right one.
• Run it manually a few times first, the old back-and-forth way. This isn’t wasted time — it’s how you learn exactly where the task goes wrong and what “finished” really means, and you can’t skip straight to automating a process you can’t yet describe.
• Write the loop down as a contract: the goal, the finish line, the checks that enforce it, the maximum number of attempts, and the exact point where you want to be asked before anything happens. That contract is the loop. Everything else is implementation.
• Run the first pass with the door open. Watch every iteration instead of walking away. You’re hunting for failure modes — does it call victory too early, does it wander from the actual goal, does it satisfy its own weak check while quietly producing something you wouldn’t accept?
• Tighten the verifier with what you saw. Add the check for the specific thing it kept getting away with. Keep going until the loop’s version of “pass” means what your version of “pass” means.

Scaling Past One Loop

Closed loops vs. open loops. A closed loop repeats a bounded task toward a fixed target — cheap, predictable, safe to leave running. An open loop explores more freely, tries approaches you didn’t specify, and spends more budget for a shot at more upside. Decide which one a task calls for before writing its verifier, because the verifier has to match how much novelty you’re actually willing to accept.

The harness underneath. A loop is only as good as the environment it runs inside — the tools it can call, how context gets managed turn to turn, what it’s allowed to touch, and how it recovers from a bad step. A well-designed loop running on a shaky harness will still fail in ways that look like the loop’s fault.

Cost as a design constraint. Loops make far more model calls than a single prompt ever did. Route the easy, repetitive parts to a fast, inexpensive model, save your most capable model for the step that actually needs judgment, and reuse the instructions that don’t change between iterations instead of paying full price for them every time.

Sub-agents for parallel work. When a job actually splits into independent pieces, don’t run them one after another — hand each piece to its own sub-agent, run them at the same time, and stitch the results back together afterward. Hours in sequence can become minutes this way.

From loop to infrastructure. The last step is moving a loop you trust out of a session you babysit and into a script that runs on its own schedule. That’s the point where work finishing while you’re elsewhere stops being an idea and becomes a job you check on once a day.

---

The Actual Skill Is Taste

A verifier is nothing more than your own judgment, written down precisely enough that a machine can enforce it without you in the room. Which means the quality of everything a loop produces is capped by the quality of the judgment you fed into its checks — not by how capable the model is. If you can’t yet tell strong output from merely acceptable output in your own domain, no loop will teach you that. It will just produce the acceptable version faster and at greater volume.

This is why loop engineering rewards people with real experience rather than making that experience irrelevant. Someone who already knows what correct code, or a strong resume bullet, or a well-argued paragraph looks like can write a check that catches the subtle version of wrong. That’s not a skill a loop replaces — it’s the one thing a loop actually runs on.

What a Loop Won’t Do For You

A loop will not rescue a task you don’t understand yourself, and it isn’t a reason to stop paying attention at the moments that matter. The failure modes worth watching for stay consistent: a verifier that’s really just the model approving its own work, a loop with no real exit that quietly drains a budget or runs forever, no state to recover from a bad restart, and human checkpoints removed from the one place they actually mattered.

The idea is barely a month old, which is exactly why it’s worth ten minutes of attention now, rather than later, once it’s just how everyone already works. Loop engineering doesn’t make judgment less valuable. It makes the person willing to write that judgment down, precisely, the most leveraged person on the team.