Still Writing Prompts? Let AI Drive Itself with Loop Engineering

Boris Cherny, the head of Claude Code, once said: “I don’t prompt Claude anymore. I have a bunch of loops running that prompt Claude and figure out what to do. My job now is to write loops.” He’s not describing the future. He does this today.

How much time have you spent learning prompt engineering? I’ve spent plenty. Prompt engineering solves the problem of “you being present.” The moment you leave the keyboard, work stops.

I. You Are the Human Engine

Most people use AI like this:

You type an instruction, AI generates it, you check it, you type another instruction, AI generates again. It’s a loop. Every round requires you to sit there, watch, wait, make a judgment, and push it forward.

This pattern has a structural ceiling:

If you’re not there, the process stops.

The one who’s always present, always pushing, is you. You are that human engine.

You turned yourself into a prompt expert, only to realize that “the one who issues instructions” is exactly what’s being automated away.

II. Where Loops Come From

In 2025, a developer named Geoffrey Huntley proposed the “Ralph’s Loop.”

In its purest form, just 3 lines of bash:

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

No multi-agent communication, no complex architecture. Just let AI run continuously, clear context each round, and use test failures as hard feedback.

What happened?

With this “crude” loop, in three months he had AI write a compiler for an entirely new programming language from scratch.

By June 2026, the idea exploded. Peter Steinberger (OpenAI), Boris Cherny (Anthropic), and Addy Osmani (Google Chrome) all publicly endorsed it, officially calling it Loop Engineering.

Prompts make AI move once. Loops make AI keep moving.

III. Anatomy of a Mature Loop: 5 Parts and 1 Memory

Addy Osmani breaks a mature loop system into 5 components, each addressing a pain point you’ve felt after using AI.

Automation Trigger: The heartbeat of the loop. It wakes up and finds tasks without you pressing start — could be on a timer, or when a new PR appears.

Worktree Isolation: When running multiple agents simultaneously, give each agent an independent working directory. The consequences of having them fight over the same file are not pleasant.

Skills (Skill Files): AI forgets everything every time it restarts. Write project conventions into SKILL.md. After reading it, AI can work without you re-explaining the project context.

Connectors (MCP): Let the loop read Jira tickets, query databases, send Slack messages, and auto-open PRs. Break out of the file system and connect into real workflows.

Sub-agent Division (Maker + Reviewer): Letting the model that writes code also score itself leads to constant self-praise. You must assign an independent agent to criticize. Self-scoring is a trap.

Plus one must-have: Memory.

AI forgets between rounds. Progress must be persisted to disk — a single Markdown file suffices. The system needs to know where it left off yesterday.

A loop is a sleepless engineer. But you have to leave it a note — otherwise it thinks every morning is its first day on the job.

IV. Three Debts of Automation

On social media, you only see “The loop ran all night and wrote 6 repositories.”

What you don’t see is an unattended loop making mistakes unattended.

Verification Debt: When AI prints “Done” in the console, that’s a claim, not proof. Without hard stop conditions — tests passing, lints clean — the loop will find ways to cheat and sneak broken code in. The review time you save today becomes a bomb when the system crashes tomorrow.

Understanding Debt: Loops produce code way faster than you can read it. If you let loops submit PRs for months without reading them, one day you’ll find yourself a stranger in your own codebase. When a deep bug surfaces, the loop can’t fix it, and you won’t even know where to start debugging.

Cognitive Compromise (most dangerous): When “press a button to let AI do it” becomes too comfortable, you gradually stop thinking about “should we be building this feature?” or “is the architecture reasonable?” You hand over the most important thing as an engineer — judgment.

One more bill: a loop with no iteration cap can retry hundreds of times overnight, draining your API budget.

V. Start Now (Two Methods)

Method A: /goal command (recommended for beginners)

Write clear acceptance criteria. For example: “All tests pass, and no files under the test/ directory are modified.”

After starting: the model responsible for writing code makes changes; behind the scenes, a small independent model evaluates progress. If criteria aren’t met, it bounces back for rework. It only stops when conditions are met. You don’t intervene until the condition is met or a timeout occurs.

I tested Codex’s /goal feature myself. My goal was to develop a plugin for automatically collecting and scheduling Twitter content — previously a manual repetitive task.

I wrote the acceptance criteria, started it, and went to do other things.

It completed.

It works, it runs, acceptance generally passed.

Only one prerequisite: you need to clearly define “what done means,” not “make something kind of like this.” The more precise the condition, the more reliable the result.

Method B: Minimal Ralph’s Loop (10 lines of bash, for the tinkerers)

• Create progress.txt: persistent memory, tells AI where it left off
• Create spec.md: your acceptance criteria and task list
• A while loop that feeds these two files into AI (Aider or Claude CLI)

Core philosophy: clear context every round, pass progress through a physical state machine, avoid context pollution.

Start with /goal. The bash loop is for when you already know what you want and are willing to monitor output yourself. Don’t overcomplicate from the start.

Go build that loop.

But don’t let yourself become just a machine gatekeeper who presses the start button.

Loops make code production cheap. They don’t make “what should we do” cheap. That judgment — now and in the future — is still your job.

Are you still writing prompts, or are you writing loops?

🥳 Thanks for reading. I’m Phil, former architect → AI product enthusiast.
Follow me @Formulasearch for ongoing AI tools and product thinking.