Loop Engineering guide
Then /goal loops on its own, fixing its own mistakes, and a separate check decides when the goal is truly met, so it will not stop early or fake done.
Normal vibe coding is a babysitting loop. You prompt your AI, it makes a mistake, you re-prompt it, it fixes that and breaks something else, and you go back and forth like this over and over, watching every step. You are the loop. The moment you stop typing, the work stops.
Loop engineering flips that around. Instead of driving each step, you hand the AI one clear goal and a clear finish line, then let it run: it works, checks its own result, fixes its own mistakes, and repeats until the finish line is true. The term was coined by Addy Osmani, and it is how the people building these tools now describe their own workflow. As Boris Cherny, the creator of Claude Code, put it: "I don't prompt Claude anymore. My job is to write loops." It does not replace good prompting, it is a layer on top of it.
In Claude Code you do not have to wire that loop up by hand. The /goal command is the loop: you type /goal followed by one clear objective, and Claude keeps working and fixing its own mistakes until that objective is met, without you re-prompting between steps. The example above points to the parts: the /goal command that runs the loop, your goal in plain words, the steps you want it to take, and the finish line it can actually check.
The one rule that makes or breaks it is that finish line. It has to be objective and machine-checkable, not a vague wish, because /goal has a separate check decide when the objective is truly met. "Make it better" gives it nothing to verify against, so it never knows when it is done. A build passing is a weak finish line on its own, it only proves the code compiles, not that the feature works. The strong ones stack several checks and include real behavior: build and lint clean, the new tests pass, AND the thing actually does what it should when you run it. The more of the finish line the loop can run itself, the closer it gets to genuinely ship-ready before it hands back.
A few goals that work well: "add CSV export to the reports page, done when npm run build, npm run lint, and the new reports.test.ts all pass and clicking Export actually downloads a CSV matching the rows on screen", or "the failing test in auth.test.ts passes without breaking the others, done when npm test shows zero failures". Each one is a finish line Claude can run, not a vibe it has to guess at. Keep the objective that concrete and /goal mostly takes care of the rest.