Loop Engineering 101: How to Get Claude to Work for Hours Without You
Prompt engineering was one good instruction. Loop engineering is designing the cycle — trigger, work, check, exit. The full playbook, with 24 copy-paste prompts.
👋 Hey, I’m Sid. Each week, I help you get better at using AI tools to accelerate your work — with deep dives, exact prompts, and installable Claude skills you can run yourself. For more: TPC Labs | GetSkills | GetPrompts
P.S. Get a free year of GetSkills Pro ($150) and GetPrompts Plus ($100), the full TPC Labs members hub, AI workflow systems that replace your SaaS tools, custom skills built on request — plus $1,000 in Hyperagent credits — by becoming a paid subscriber. Yes, this is for real.
🎯 The shift nobody announced properly
For two years, the skill was prompt engineering: write one instruction well enough that the model does the thing in one shot.
That skill is quietly becoming less valuable. Not because prompts stopped mattering, but because the constraint moved. Thariq Shihipar, who works on the Claude Code team, put it plainly on Peter Yang’s podcast in July:
As the models have gotten smarter, they need less direction, fewer constraints, and fewer examples.
His team cut Claude Code’s system prompt by 80%. Not to save tokens — because the examples were constraining the model. When you show it five examples of how to use a tool, it starts pattern-matching to your examples instead of reasoning about the situation. When you say “never do X,” you almost always mean “usually don’t do X, and here’s why” — and the reason works better than the prohibition.
So if the model needs less instruction, what’s left to engineer?
The loop. How long it runs. What tells it it’s done. Who checks the work. What happens when it gets stuck at 2am while you’re asleep.
That’s loop engineering, and it’s the highest-leverage AI skill for the rest of 2026.
🧩 So what is loop engineering, actually?
Prompt engineering was one question: what do I say?
Loop engineering is five, and only one of them is about what you say:
What triggers it? You, a clock, or an event.
What’s the unit of work? One turn, one file, one PR, one report.
What tells it it’s done? The exit condition — the part almost everyone skips.
Who checks the work? A test, a script, a rubric, or a second agent that didn’t write it.
What happens when it’s stuck? Escalate to you, skip and log, or burn turns until the cap.
A prompt is a sentence. A loop is a system with a stop condition. That’s the whole reframe.
Here’s the same task run both ways:
Prompt engineering: “Go through this repo and fix all the TypeScript errors. Be careful not to change behavior. Here are three examples of the kind of fix I want…”
You then sit there. It does 80% of it, hits something ambiguous, stops, asks. You unblock it. It stops again. You’re the loop.
Loop engineering: /goal zero TypeScript errors in [DIR] with strict mode on. One module at a time, commit each green step. Skip anything requiring a behavior change and list it at the end. Stop after 40 turns.
Same model. Same task. The difference is that you specified the finish line and the budget instead of the technique — and now you’re not the loop.
The reason this is the skill of the moment: model capability keeps rising, so the “how” keeps needing less specification. But no model will ever know when your work is done, how much you’re willing to spend finding out, or who gets to sign off. Those are permanently yours. Loop engineering is just the practice of stating them explicitly and up front.
A useful way to hear it: a prompt engineer writes instructions for a worker. A loop engineer writes a contract — scope, acceptance criteria, budget, escalation path. The second one scales; the first one requires you to sit there.
🔁 The four loop types (Anthropic’s own taxonomy)
Anthropic published a framework for this. Four loop types, sorted by what triggers them and what stops them. Get this table into your head and everything else follows.
Loop type: Turn-based · Command: (just prompting) · Triggered by: You, each turn · Stops when: Claude thinks it’s done · Best for: Exploration, decisions, anything squishy
Loop type: Goal-based · Command: /goal · Triggered by: You, once · Stops when: Goal verified or max turns hit · Best for: Anything with a checkable finish line
Loop type: TiXme-based · Command: /loop, /schedule · Triggered by: A clock · Stops when: You cancel, or work runs out · Best for: Recurring work, watching external systems
Loop type: Proactive · Command: /schedule + /goal · Triggered by: Events + schedule, no human · Stops when: Each run exits on goal; routine runs till disabled · Best for: Well-defined recurring work at volume
The progression matters: each row hands off more of the judgment to Claude. Turn-based, you verify every step. Goal-based, you only define the stop condition. Time-based, you only define the trigger. Proactive, you hand over the whole thing and read the output later.
Don’t start at row four. Almost everyone who gets burned by autonomous agents jumped straight to proactive on a task they’d never run manually once.
