Loop engineering: why /goal changes how you build

Last week I caught myself doing something embarrassing. I'd given Claude Code a reasonably complex task, it finished a chunk, and I typed "keep going." It finished more, and I typed "keep going" again. And again. Three times in a row I sat there pressing the human equivalent of Enter, nudging an AI agent forward like a babysitter who can't leave the room.

I was the loop. I was the automation Claude was waiting on.

The term "loop engineering" appeared on X on June 7, 2026. Developer Peter Steinberger posted about it, Addy Osmani picked it up, and Boris Cherny (the engineer who built Claude Code at Anthropic) validated the concept from his own experience. Within a few days it was all over developer Twitter. It resonated so fast because it names something every developer using an AI coding agent has already felt but didn't have a word for.

What loop engineering actually is

The short version: loop engineering is the shift from prompting an AI agent by hand to designing the system that runs the agent for you.

Prompt engineering optimizes a single call. Loop engineering designs what happens between calls and what triggers the next one. It's the difference between asking Claude a question and building a process where Claude asks itself whether it's done yet.

The architecture behind it is the ReAct pattern (Reason + Act), which has been around in AI research for a while. The agent takes an action, observes the result, reasons about it, and decides what to do next. The loop continues until some termination condition is met. For coding, that looks like: write code, run it, read the error, fix it, run it again, repeat until tests pass.

This is how experienced developers actually work. AI coding agents that skip the feedback loop generate code once and stop. That ceiling hits fast on anything real.

Why /goal gets it right

Claude Code shipped a /goal command that implements this cleanly. Here's what it actually does, because the description undersells it.

When you type:

/goal All unit tests pass and no new linting errors

...you're not writing a nicer prompt. You're activating a fundamentally different execution model. Claude runs a turn: reads files, writes code, executes commands. Then a separate lightweight model (Haiku) evaluates the conversation transcript and asks: have the conditions been met?

If no, Haiku tells Claude why and the loop repeats. If yes, it stops.

That last part matters more than it sounds. Claude isn't grading its own homework. A different model makes the call. I've watched Claude confidently declare tasks complete when they weren't, because it was pattern-matching on completion signals rather than actually verifying the outcome. The external verifier breaks that pattern.

Compare /goal to /loop, which runs on a timer. /loop just keeps going at regular intervals regardless of whether anything meaningful happened. /goal stops when you've actually gotten what you asked for. For long-running tasks like fixing a failing build, resolving a dependency conflict, or refactoring a module, the difference between outcome-based stopping and time-based stopping is substantial.

Writing a goal that actually works

The verifier can only evaluate what Claude has surfaced in the conversation transcript. That means your goal has to be measurable from the output.

This is a goal:

/goal All 47 unit tests pass, no new linting errors, 
no changes to the public API surface

This is not:

/goal Improve the code

"Improve the code" is subjective. The verifier has no way to evaluate it. The loop either runs forever, runs once and stops incorrectly, or hallucinates completion. Specific, testable criteria give the verifier something real to work with.

Good /goal candidates: fixing a failing build, migrating an API, resolving dependency conflicts, optimizing Lighthouse scores, validating a CI/CD pipeline. The common thread is that "done" is verifiable, not just observable.

What this actually means for your workflow

Boris Cherny described his own workflow in a recent Acquired interview. He no longer writes production code by hand. He designs loops: automated workflows that prompt Claude and figure out what to build next. He eventually uninstalled his IDE because he hadn't opened it in a month.

The whole Anthropic engineering team is now at 90%+ of code written by Claude Code, with a 200% increase in merges per engineer per day. New engineers who used to need weeks to ramp up are productive in about two days because Claude already knows the codebase.

Honestly, I don't know exactly how to read all of that. The tasks where those numbers hold are the ones loop engineering handles best: well-scoped tasks with clear success criteria in a codebase the agent understands. Architecture decisions, ambiguous requirements, judgment calls about whether a given approach is even the right one — I haven't seen a loop replace those yet. Maybe it will. I have no idea.

What I do think: developers who get good at writing specific, testable goals are going to compound faster than the ones who keep babysitting their agents. That part feels pretty clear.

Where to start

Pick one task you'd normally nudge through three or four "keep going" prompts. Make the done condition specific and testable. Hand it to /goal and go do something else.

If it runs too long with no progress, that's a signal: your goal was too vague, your codebase has a deeper problem, or the task needs to be broken into smaller chunks first. Treat a runaway loop as diagnostic information, not just a failure.

For more on how I'm building with Claude Code and agentic tooling, check out quintonwall.com. If you're building developer products and thinking about how this changes your DevRel strategy, that's exactly the kind of problem we work through at The DevRel Collective.

Sources: