Stop Being the Loop

For the last two years, working with AI agents has felt like a conversation. You type a prompt, you get an answer, you check it, you fix what's wrong, you ask again. That motion is so normal we stopped noticing it.

Here's the uncomfortable part: in that setup, you are the loop. You're the one running the cycle, holding the context in your head, catching the mistakes, and deciding when it's good enough. The AI does a step; you do everything around the step.

That's the thing quietly changing right now. This is a short read on what's changing, why it matters, and how we start.

The old way vs the new way

The old way — prompting. You drive every step.

You write a prompt → the agent produces something → you review it → you fix it → you prompt again → repeat.

It works. But you're the bottleneck, the memory, and the quality check all at once. Nothing happens unless you're sitting there pushing it forward.

The new way — looping. You set the destination, not every turn.

You define the goal and what "done" actually means → the loop runs the cycle → it tries, checks its own work against a real standard, fixes what failed, and repeats → it stops when the work passes.

The difference in one line: a prompt gives the agent an instruction. A loop gives the agent a job. Your role moves from operator to designer.

Loop engineering

Loop engineering is the practice of designing a repeatable cycle that takes an agent from a first attempt to a verified result, with as little hand-holding as possible.

Every loop — simple or complex — moves through the same five stages:

Discover → Plan → Execute → Verify → Iterate

Pass verification, ship it. Fail verification, loop again. That's the whole idea.

The stage everyone underrates is Verify. A loop without a real quality gate doesn't save you work — it just produces confident, plausible nonsense faster than you can read it. The gate is the entire game. So a good loop needs a few honest ingredients:

• A clear definition of "done" — something checkable, not a vibe. "All tests in this folder pass and the linter is clean," not "make it good."
• A real feedback signal — tests, type checks, a schema, a checklist, or a second agent reviewing against the spec.
• Reusable context — our conventions, architecture, and rules written down once, so the agent doesn't relearn our project from zero every run.
• A separate checker — the agent that did the work is the worst judge of it. The reviewer should be a different agent, sometimes a different model.
• Memory that outlives the chat — a file or board that records what was tried, what passed, what's still open, so tomorrow's run picks up where today's stopped.

Stop prompting, start looping

It's a great slogan. It's also not literally true, and it's worth being clear about why — because the difference is the whole point.

You don't stop prompting. The prompts move inside the loop. Every cycle still sends one; you've just stopped writing them by hand, one at a time, and stopped being the thing that checks the output. Your leverage shifts from "write a clever sentence" to "design a reliable system."

This is why a mediocre prompt inside a good loop will usually beat a brilliant prompt fired once — but only because the loop has a real way to tell good work from bad. Take away the verification step and you've just automated the production of slop.

So the honest version of the slogan is: stop hand-driving every step. Start building the system that drives them — and keep your hand on the wheel.

Where we start

Don't start with the exciting version. Start with the reliable one.

• Start closed, not open. Pick a task with a clear pass/fail signal — tests pass, output matches a format, a checklist is satisfied. Bounded loops are reliable and cheap. Open-ended "let it roam" loops are powerful but drift into mess fast and burn time and budget without a gate.
• Write down "done" before you start. If you can't describe how the loop knows it's finished, it isn't a loop yet.
• Give context once. Drop our conventions, architecture notes, and "never do this" rules somewhere the agent reads every run.
• Split maker from checker. Never let the same agent grade its own homework.
• Keep a memory file. It sounds too simple to matter. Every long-running loop depends on it.

Pick one annoying, repetitive, verifiable task this week and wrap a closed loop around it. That's the whole on-ramp.

One thing to remember

The loop doesn't know whether you understand the work. Two people can build the exact same loop and get opposite results: one uses it to move faster on something they understand deeply, the other uses it to avoid understanding it at all. Same loop, opposite outcomes — and the loop can't tell the difference. You can.

It also isn't magic or free. A loop is only ever as good as its weakest verification step, and model choice and cost still matter. This isn't about doing less thinking. It's about moving the thinking up a level — from the answer to the system that produces the answer.

We're not trying to prompt better. We're trying to build systems that reach a verified result on their own — while we stay the engineers, not just the people who press go.