Every tech lead I talk to has the same AI adoption story: it starts with typing prompts into a coding agent, then copy-pasting the same prompt with small tweaks, then writing a script that does the copy-pasting for you. That last step has a name now — Gergely Orosz calls it loop engineering, and it’s worth understanding before your team reinvents it badly.

The Shift in One Line

Boris Cherny at Anthropic put it simply: engineers are moving from writing prompts to writing loops. Addy Osmani frames it as “replacing yourself as the person who prompts the agent.” Instead of you being the human in the loop who decides what to ask the agent next, you write the system that decides that — a goal, a success condition, and a mechanism that keeps invoking the agent until the condition is met.

That’s the whole idea. It sounds obvious once you say it out loud, which is usually the sign of a real shift rather than a buzzword.

Where It Came From

The pattern traces back to Geoffrey Huntley’s “Ralph Wiggum loop,” published in 2025 — named, appropriately, after the Simpsons character who succeeds through sheer persistence rather than sophistication. The mechanics are simple:

1. Give the agent a task and a clear goal definition
2. Have it write a work plan with explicit success criteria
3. Run the agent repeatedly, checking after each pass whether the goal is met
4. Let it spawn subagents for pieces of the work as needed
5. Persist state between runs through logs and an updated plan file

Huntley’s own caveat matters as much as the technique: “engineers are still needed.” A loop with a badly specified goal just fails faster and more expensively than a badly specified prompt.

From Hack to Native Feature

What turned this from a clever workaround into a real engineering practice was tooling catching up. In the space of about six weeks this spring, the major coding harnesses shipped native support for exactly this pattern:

• April 2026 — Codex shipped a /goal command: a persistent objective with a defined completion condition
• May 2 — Hermes shipped its own /goal, citing Codex as the inspiration
• May 12 — Claude Code shipped /goal, on top of the /loop command it already had for scheduled tasks

What used to require you to hand-roll a bash script wrapping an agent CLI is now a single command. That’s the actual unlock — not a new capability, but a massive drop in the setup cost, which is why adoption jumped this quarter.

What Teams Are Actually Doing With It

The use cases that are sticking aren’t exotic. They’re the same categories of automation engineering teams have always wanted, now with an agent instead of a fixed script on the other end:

• Trigger-based fixes — a Sentry error fires, a loop opens a draft PR before an engineer even looks at the issue (Ivan Pantić)
• Flaky test cleanup — one engineer generated 13 PRs fixing flaky tests via a /loop run (Paul D’Ambra)
• Incident response support — a loop triages and drafts a fix while the on-call engineer is still getting paged (Ivan Abad)
• Scheduled improvement passes — daily cron jobs that read the last 24 hours of logs and ship small product fixes (Jack D)
• Overnight test babysitting — nightly E2E runs get automatically diagnosed and patched before standup (Utku K)
• Large migrations — a React-to-React-Native migration progressed via a cron-triggered loop every 30 minutes (Rafel Mendiola)

Notice the shape: none of these replace judgment. They replace the tedious, repetitive act of noticing something needs doing and re-prompting the agent to do it.

The Skeptic’s Point Is Worth Taking Seriously

Not everyone is convinced this is new. Director Oded Messer’s line is the sharpest pushback: “if my strategic workflow is automatable then it either becomes tactical if the AI is capable enough or it’s just a high level old-school-automation.” In other words: this is webhooks and cron jobs with an LLM bolted on, and teams that already had solid automation practices are seeing less of a step-change than teams that didn’t.

Max Kanat-Alexander goes further, suggesting loops may be a temporary scaffold — a workaround for context window limits that will mostly disappear once harnesses get better at native long-running goals, at which point “loop engineering” as a distinct skill quietly stops being a thing you need to know.

Both critiques point at the same real risk: agent drift. A loop with a vague success condition doesn’t fail loudly — it burns tokens and produces plausible-looking but wrong output, repeatedly, unsupervised, until someone notices the bill or the bad PRs.

A Decision Framework, Not a Mandate

If you’re a tech lead deciding whether to introduce loop engineering to your team, the question isn’t “should we use loops” — it’s “which of our existing automations should become loops, and which of our manual prompt sessions should become automations.” Concretely:

1. Is the success condition machine-checkable? Tests passing, a build succeeding, a lint rule clearing — good candidates. “Does this look right” — not yet, keep a human in the loop.
2. Is the task already repetitive today? If you’re prompting an agent for the same category of fix three times a week, that’s the signal to write the loop, not a new prompt.
3. What’s your blast radius if it runs unsupervised overnight? Flaky test fixes on a feature branch: low risk, good first loop. Anything touching production data or auth: keep a human gate before merge, regardless of how good the loop looks in testing.
4. Do you have token budget visibility? Loops multiply agent invocations. If you don’t already track cost per PR or per fix, you’ll find out the hard way.

What to Do This Week

Don’t start with loop engineering as a strategy. Start with your team’s most annoying recurring manual AI task — the one where someone re-runs the same prompt with minor edits every few days — and turn just that one into a /goal run with an explicit, checkable success condition. Measure what it produces for a week before you trust it unsupervised.

The tooling caught up fast enough that the setup cost is no longer the excuse. The judgment about what deserves a loop is still entirely on you — and that’s the actual tech lead job here, same as it’s always been.