Loop Engineering: From Ralph Loops to the Enterprise

Loop engineering is the practice of designing systems that repeatedly run an AI coding agent toward a defined goal — so a human no longer prompts the agent at all. Gergely Orosz's The Pragmatic Engineer put the term on the industry's map this month in "What is 'loop engineering?'", tracing it from a bash one-liner to first-class /goal commands in the major coding harnesses. It is the best write-up of the practice available, and this article builds on it deliberately — because we think the story has a second act Gergely's practitioner lens only gestures at: loops are how delegation stops being a developer trick and becomes an enterprise operating model. Here is what loop engineering is, where it came from, and what it looks like when an organization — not a developer — owns the loop.

What is loop engineering?

The cleanest definition in the Pragmatic Engineer piece comes from Addy Osmani: "Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."

The practice has a charmingly crude origin. In July 2025, Geoffrey Huntley published "Ralph Wiggum as a 'software engineer'" — the "Ralph loop," named after the Simpsons character, was essentially:

while :; do cat PROMPT.md | claude-code ; done

Run the agent against a prompt file. When it stops, run it again with fresh context. Repeat until the goal is reached. What looked like a joke turned out to be a structural insight: an agent that loses its way in one long session often converges when restarted repeatedly against a well-specified goal. The approach went viral in late 2025, picked up high-profile practitioners in 2026 — The Pragmatic Engineer quotes Anthropic's Boris Cherny: "I don't prompt Claude anymore… My job is to write loops" — and by May 2026 the major harnesses had absorbed it as a feature: /goal commands in Claude Code and Codex run the whole loop from a single instruction.

The anatomy of a loop

As the Pragmatic Engineer article lays it out, a working loop has five parts:

1. A prompt that captures the task and defines a goal — the loop's exit condition.
2. A plan of work, each item with its own success criteria.
3. Iteration: the agent processes one item per pass.
4. A goal check: if not met, restart with fresh context — the loop's defining move, trading accumulated confusion for a clean run at the remaining work.
5. Subagents spawned as needed for parallel or specialized steps.

Notice what this actually is: a definition of delegable work. A task you can put in a loop is a task with an explicit goal, decomposed items, and verifiable success criteria — precisely the profile we use to route work to autonomous agents in agentic engineering. Loop engineering and agentic engineering are the same discipline seen from different altitudes: one developer automating their prompting, versus an organization automating its delivery.

Why the idea matters more than the bash script

The deep point in Gergely's piece is not the tooling — it is the role change. When Matt Pocock describes waking up "to working code, where your coding agent has worked through your backlog," the engineer's job has moved up a level: from producing changes to specifying goals and verifying outcomes. That is the exact transition we describe in Agentic Engineering vs. AI-Assisted Development — the human leaves the keystroke loop and takes ownership of the verification loop.

Gergely also lands two caveats that deserve amplification rather than argument. First, loops are expensive at scale — token-metered iteration with no cost ceiling is a CFO incident waiting to happen. Second, most engineers do not need to build loops by hand: with /goal commands built into the harnesses, hand-rolled Ralph loops are already semi-obsolete, and for engineers outside AI infrastructure, context fundamentals matter more. We agree with both — and they point somewhere specific.

The enterprise second act: the loop as a managed platform

Here is our thesis as practitioners who deploy this for enterprise clients: the Ralph loop's anatomy is exactly what an enterprise delegation platform industrializes. Take each part of the loop and ask what it becomes at organizational scale:

Loop part (developer version)	Enterprise version
PROMPT.md with the goal	Playbooks — codified, reusable task templates
while :; do … done in a terminal	Schedules and event triggers: tickets, CI failures, cron
Fresh context per iteration	Isolated sessions, each with a reproducible environment
Goal check by the developer	CI-green exit criteria plus a human review gate on every PR
Subagents	Fleet-scale parallel sessions across repositories
Cost anxiety	Per-session metering with budgets and full audit

That right-hand column is a description of how Devin operates as a platform — org-level schedules, Playbooks, session isolation, iterate-until-green, and ACU metering per session — which is why we tell clients: the correct enterprise response to loop engineering is usually not "teach every developer to write loops"; it is buy the loop as a governed platform and spend your engineering judgment on goals and success criteria. The loops that fix flaky tests nightly, triage incidents, and grind through migration backlogs — the exact use cases the Pragmatic Engineer catalogs — are what an organization-owned agent platform runs as a product feature, with the governance already attached.

Gergely's caveats map cleanly onto that claim. Runaway cost? A platform loop is metered per session with budgets — cost per merged PR becomes a query. Agent drift? The loop's exit gate is not vibes; it is CI plus a human reviewer, the discipline we detail in production-safe AI-generated code. The practitioner insight stays; the operational risk gets an owner.

Where hand-rolled loops still make sense

Honesty about the boundary: if you are building AI infrastructure, experimenting with harness behavior, or running one-off personal automations, a hand-built loop (or a /goal run) is the right tool — cheap to start, fully in your control, wonderfully educational. Geoffrey Huntley's own caveat applies at every altitude, though: "Engineers are still needed… Anyone claiming a tool can do 100% of the work without an engineer is peddling horseshit." Loops do not remove engineering judgment; they concentrate it into goals, success criteria, and review — which is why teams that adopt loops without a verification discipline mostly automate the production of rework.

FAQ

What is loop engineering?

Designing an automated system that repeatedly runs an AI coding agent toward a defined goal — prompt, plan with success criteria, one work item per iteration, restart with fresh context until the goal check passes. The term was popularized by The Pragmatic Engineer's July 2026 analysis.

What is a Ralph loop?

Geoffrey Huntley's original technique (July 2025): a bash while loop that pipes a prompt file into a coding agent forever, restarting it with fresh context each pass — named after Ralph Wiggum from The Simpsons. It went viral in late 2025 and inspired the /goal commands now built into major harnesses.

Do my engineers need to learn loop engineering?

Most do not need to build loops by hand — harnesses now run loops natively, and at organizational scale the loop is better bought as a governed platform capability. What every engineer does need is the skill underneath loops: specifying goals, decomposing work with verifiable success criteria, and reviewing agent output — the curriculum of our 90-day enablement plan.

How is loop engineering different from agentic engineering?

Same discipline, different altitude. Loop engineering is the practitioner's framing — a developer automating their own prompting. Agentic engineering is the organizational framing — delegation run as an operating model with governance, measurement, and review gates. The loop anatomy is identical; the owner changes.

What are the risks of agent loops?

The two the Pragmatic Engineer flags: cost (token-metered iteration at scale) and drift (agents wandering without a firm goal check). Both are governance problems — solved by per-session metering and budgets, CI-based exit criteria, and a human review gate, not by better prompts.

The bottom line

Loop engineering is the most useful new name of 2026 for an old truth of delegation: work moves when it has a goal, a plan, success criteria, and relentless iteration toward them. Read Gergely Orosz's original analysis — it is the definitive practitioner account. Then ask the organizational question: which share of your backlog could run in a governed loop tomorrow? That is exactly what our agentic engineering services operationalize, and what the AI Readiness Assessment maps in your own codebase — the goals, the delegable slices, and the review capacity to close the loop.