Agentic Coding Loops: From a Bash One-Liner to /goal, Checks and Hard Stops

A single sentence from Peter Steinberger dominated the AI-coding conversation in June 2026 and passed two million views: coding agents should no longer be prompted by hand, and loops that prompt the agents should be designed instead. The replies turned into an argument over what that means. When someone asked what it looks like in practice, the most-quoted answer joked that only two people knew. That is funny and incorrect. The idea is not mystical, and the way in is one command.

Rather than debate whether prompt engineering is dead, the useful move is to build one, starting from a line that can be pasted in five minutes.

Three points carry the rest:

• A loop is a script that sends a prompt to the agent, inspects the output, judges whether the job is done and repeats if it is not. The human no longer sits inside the cycle typing instructions. The loop is authored once and the model serves as a subroutine within it.
• The simplest useful loop is one line of bash, and the most useful is a single slash command. No orchestration framework is needed to start, and starting with one is a mistake.
• What separates a loop that works from one that drains a budget comes down to two things: a means of testing its own output against an external truth, and firm stops that make it halt.

A definition and a ladder

Boris Cherny created Claude Code, and by his account Claude Code authored every one of his own contributions to it in a recent month, 259 pull requests, while his IDE has been uninstalled since November. He describes the method plainly: he no longer prompts Claude, loops run and prompt it for him and decide what happens next, and his job is writing loops.

His three-rung ladder makes the idea concrete. A year ago the work was handwritten code with autocomplete. Then came several agent sessions in parallel, each prompted by hand. Now the work is the program that prompts the agent, and the engineer goes off to do something else. The job moved up a level, from writing code to writing the thing that writes code. He is explicit that this does not retire engineers. Someone still decides what to build, good engineers matter more, and checking results always counts. The keystrokes left and the judgment stayed.

The smallest loop: one line of bash

The whole concept fits in a one-liner, and running it once gives a feel for it. It is called the ralph loop, after Ralph Wiggum, and Geoffrey Huntley popularized it in 2025.

while :; do cat PROMPT.md | claude -p --dangerously-skip-permissions; done

That is the whole thing. The same prompt file is fed to Claude Code in headless mode, the agent works until it quits, and then the cycle restarts with an identical prompt. A pass never remembers the previous one, so it regains its bearings from the files, the checklist and the commits earlier passes left. There is no framework or state machine involved, only an endless while around a coding agent.

Take care before pasting it: the flag that skips permission prompts is as blunt as it sounds, and the agent will run commands without asking. A disposable git worktree or container, on a branch that is fine to lose, is the right place, never the main checkout.

The cleverness lives in the habit, not the code. Rather than let one enormous conversation grow stale, every iteration starts from a fixed set of anchor files. The prompt file names the same few documents each time, usually a spec and a checklist that the agent ticks and commits as it proceeds. A fresh pass therefore starts oriented, and committing progress each round keeps the agent from drifting or redoing finished work.

Does a trick this crude pay off? A team at a Y Combinator hackathon got six repositories out overnight using a ralph loop and about 297 dollars of API spend, which they valued at around fifty thousand dollars of contractor labor. Huntley produced an entire small programming language the same way. As a toy the one-liner gets outgrown, yet it teaches the whole shape in half a minute.

The catch is why the people deepest in this treat it as old hat. The ralph loop assumes the terminal stays open and never asks whether the job is done. It simply runs forever, and the next two sections address that.

One command: /goal and /loop

Writing the bash by hand is not required. Claude Code includes two commands that package the same loop more safely.

The /goal command keeps the agent working until a stated condition is true, and the condition is where the craft lies.

/goal all tests in test/auth pass and the lint step is clean,
      or stop after 20 turns

What lifts it above a while-true is the next step. When each turn ends, Claude Code hands the condition and the conversation to a separate small, quick model, Haiku by default, which answers yes or no and gives a reason. A no returns that reason as guidance for the following turn. The worker model never gets to declare itself done.

The limitation that matters most is that the judge neither runs tests nor looks at the repository. It sees only the transcript, so the condition has to be provable from the agent's own output. Passing tests in the auth folder qualifies, because the agent ran them and the result is in the conversation. A claim that the auth is solid does not, since nothing in the transcript can settle it. The judge reads receipts and does not audit code, so the genuine verification is still a real command run by the agent, with the judge deciding whether the receipt reads pass.

A sound condition names one measurable end state and says how the agent will demonstrate it in output. Making the auth better is not a condition. Auth tests passing, a zero exit from the test command and a git status showing changes only to auth files is one, since each clause shows up in the transcript as a command the agent ran. Add a limit such as stopping after 20 turns, plus a maximum-turns flag as a firm backstop, so an unattended run cannot spin forever.

An unattended one-shot run uses headless mode with that flag and the goal in quotes. The process must stay alive while it works, so it needs a terminal left open or a server, not a closed laptop. For shutting the lid, Claude Code in the cloud is the route. Ctrl+C ends a local run early.

A short run in practice, two turns and roughly forty cents, looks like this.

> /goal all tests in test/auth pass, npm test exits 0, or stop after 15 turns

◎ /goal active · turn 1
  ran: npm test
  ✗ 2 failing in test/auth/login.test.ts
  judge: not done, expired-token case still throws◎ /goal active · turn 2
  edited src/auth/token.ts
  ran: npm test
  ✓ 41 passing, exit 0
  judge: done, npm test exits 0 and only auth files changed✓ goal achieved · 2 turns · ~$0.40

Everything is visible there: the agent runs the check, the output enters the transcript, and the judge reads it and rules continue or stop.

The /loop command is the scheduled cousin that babysits. Cherny's own starter example is worth copying with the nouns changed.

/loop babysit all my PRs. Auto-fix build issues, and when
      comments come in, use a worktree agent to fix them.

It repeats on an interval, handles whatever is new since the previous pass, and goes on until someone stops it or it concludes the work is finished. This is polling and not event handling, which suffices for watching pull requests and repairing breakage. What gets written is the intent and the stop behavior, with the steps left out.

Self-verification makes it trustworthy

A loop that writes code and never checks it turns out confident mistakes at increasing speed. It has to test its output against something external and objective and not against its own view.

People who run these converge on one principle: an outside check, not the model's own assessment, decides completion. The loop carries on until docker build succeeds, the container starts and the health check passes, and the agent saying it looks good counts for nothing. Objective criteria stand in for vibes. In pseudocode a sturdy loop body looks like this.

loop:
  agent: make progress on the task
  run:   npm test  (or the build, or the linter)
  if check passes:   done, exit
  if check fails:    feed the failure back, try again
  if no progress in N tries, or budget hit: stop and ping me

Production users add two refinements. One is to have a different model review the code than the one that wrote it, since a model shares its own blind spots and a new reviewer spots what the author misses. Dan Kornas built roborev for this: it reviews each commit in the background and sends findings to the agent while context is still fresh. The other is to run at least two review passes even if the first is clean, and to cap rounds at five or six so the cycle cannot oscillate endlessly.

The loop is not where the magic is. The feedback inside it is. With a real check it works as an engine, and without one it only generates a bill.

Guardrails that keep the budget intact

With code generation nearly free, the expense moves to the loop that runs it, and a loop with no bounds is a real financial risk. Uber limited each engineer to 1,500 dollars per tool per month for Claude Code and Cursor after spending its whole annual AI budget in four months. What production teams dread is the loop that never ends, where a forgotten terminal becomes a four-figure invoice by morning.

Every serious loop carries the same three hard stops, and all three belong in place before one ever runs unattended.

max_iterations:   stop after N turns           (the runaway cap)
no_progress:      stop if M turns change nothing (the stuck cap)
budget_ceiling:   stop at $X or T tokens         (the wallet cap)
on_stop:          ping me with the state and the reason

The /goal command nearly gives the runaway cap for free, by writing a stop after 20 turns into the condition and passing the turn flag. The remaining two have to be added manually. Detecting a lack of progress is not built in, and the simplest approach is a Stop hook or small wrapper that compares git diff --stat between turns and halts after a few unchanged rounds. A budget ceiling belongs in the provider's spend controls, as a hard dollar limit on the workspace configured once in the console before any loop is left alone. The pitch sounds like writing loops while a thousand agents build a company overnight, but in practice most of the engineering effort ensures they stop.

The asset inside is a skill

The loop is plumbing, and the valuable part is whatever it calls.

Steinberger repeats a second piece of advice that lasts longer. Whatever is done twice becomes a reusable skill, and whatever is hard becomes a skill once solved, making the next run free. A loop that rediscovers how to run tests, locate config and format output on every iteration pays the model to relearn the project indefinitely. One that calls a small library of tested, named skills, such as running the suite, opening a pull request in the team's style or deploying to staging, builds on itself, because each iteration starts competent. It costs less and drifts less. Skills hold the value, and the loop merely invokes them in sequence.

Loops that supervise loops

At the frontier, and in what Steinberger and Cherny actually mean, loops watch over other loops. A supervising loop assigns work to many agents simultaneously, monitors them and chooses the next step, keeping durable git-backed state so a crash does not end everything. Steve Yegge's open-source Gas Town illustrates it, with twenty to thirty Claude Code instances run by a Mayor agent while patrol agents loop continuously. The dynamic workflows in Claude Code are the packaged form, where the agent writes the orchestration script and operates a fleet of subagents.

Nobody starts there. The order is one /goal, then a self-check, then the three caps, and orchestration only when a single loop cannot hold the work, which happens later than the hype suggests.

A first loop this week

1. Test the check by hand on a disposable branch. Make a branch like loop-test and run the test command yourself, confirming a non-zero exit when something breaks. Where the agent cannot distinguish pass from fail, the judge cannot either.
2. Take one bounded job with an objective finish line. A flaky test, a small migration or a lint cleanup suit it. Skip anything where done is a matter of taste.
3. Phrase it as a /goal with a limit. Use a real command and not a vague shape, such as the headless call with a 15-turn ceiling and a condition naming the auth tests, a zero exit from the test command and a stop after 15 turns.
4. Check that the agent can run the check from start to finish. Dependencies must be installed, nothing may wait for a keypress, and failure must produce a non-zero exit. First runs stall silently at this point.
5. Stay for the first run. Observe where the judge answers not done and how the agent reacts to a failing check. Ctrl+C stops it.
6. Set spending limits before anything runs unattended. A hard dollar limit on the workspace in the console, and the turn cap on every run: the first stops runaways and the second stops slow bleeds.
7. Keep the repeated part as a skill. The test command, the pull request steps or any recurring explanation goes into a SKILL.md so the next loop starts from competence.

By the end of the week there is real work that nobody typed, a loop seen checking and correcting itself, and a cap that stops it going over a cliff. That is the whole practice in miniature.

The reply to what a loop is has nothing to do with prompt engineering dying. It amounts to leaving the inside of the cycle: write the loop once, add a real check and reusable skills, cap it so it halts, and spend the freed attention deciding what to build. Steinberger and Cherny describe the same animal from two directions, and the front door today is one slash command.