You don't really need to be good at prompting anymore. The thing to get good at is the loop that does the prompting for you. It's five building blocks plus state that make up a loop: automations, worktrees, skills, plugins, and sub-agents.
Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.
For like two years the way you got something out of a coding agent was you wrote a good prompt and shared enough context. You type a thing, you read what came back, you type the next thing. The agent is a tool and you are holding it the entire time, one turn after the other. That part is kind of over, or at least some think it's going to be.
Now you build a small system that finds the work, hands it out, checks it, writes down what is done and then decides the next thing, and you let that system poke the agents instead of you. Loop engineering sits one floor above the harness. The harness that runs on a timer, it spawns little helpers, and it feeds itself.
The agent proposes a change, runs the experiment, reads the result, and keeps only the ideas that improve the outcome.
Automations handle discovery and triage on a schedule. They are the heartbeat that makes a loop an actual loop and not just one run.
A skill is project knowledge written down in a SKILL.md so the agent doesn't re-derive intent from zero every cycle.
The most useful structural thing: split the one who writes from the one who checks. The model that wrote the code is too nice grading its own homework.
A loop needs five things and then one place to remember stuff. Here is the shape that works in Codex, Claude Code, and every tool that follows.
Automations are what make a loop an actual loop and not just one run you did once. Define an autonomous task, give it a cadence, and let the findings come to you.
The second you run more than one agent the files start colliding. A git worktree fixes it — a separate working directory on its own branch sharing the same repo history.
A skill is how you stop re-explaining the same project context every session. Both tools use a folder with a SKILL.md holding instructions and metadata.
A loop that can only see the filesystem is a tiny loop. Connectors built on MCP let the agent read your issue tracker, query a database, or drop a message in Slack.
A second agent with different instructions and sometimes a different model catches the stuff the first one talked itself into. The maker and checker, split.
A markdown file or a Linear board — anything that lives outside the single conversation and holds what's done and what is next. The model forgets between runs, the repo doesn't.
Stick it together and a single thread turns into a little control panel. Here is the shape that keeps repeating.
Its prompt calls a triage skill that reads yesterday's CI failures, the open issues, the recent commits, and writes the findings into a markdown file or a Linear board.
For each finding worth doing, the thread opens an isolated worktree and sends a sub-agent to draft the fix, and a second sub-agent reviews that draft against the project skills and existing tests.
Connectors let the loop open the PR and update the ticket. Anything the loop can not handle lands in the triage inbox. The state file remembers what got tried, what passed, what is still open.
You did not prompt any of those steps. That is Steinberger's whole point made real, and it's the same loop in Codex or in Claude Code because the pieces are the same pieces.
The loop changes the work. It does not delete you from it. Three problems actually get sharper as the loop gets better.
A loop running unattended is also a loop making mistakes unattended. Your job is to ship code you confirmed works.
The faster the loop ships code you did not write, the bigger the gap between what exists and what you actually understand. Read what the loop made.
When the loop runs itself it's tempting to stop having an opinion. Designing the loop is the cure when you do it with judgment and the accelerant when you do it to avoid thinking.
The fastest answers to the questions people ask first about loop engineering.
Loop engineering is the practice of designing systems that prompt coding agents automatically instead of prompting them by hand. You build a loop that discovers work, dispatches it to agents, verifies the output, and tracks what's done — all while you are not watching.
Automations, worktrees, skills, plugins and connectors, and sub-agents. Plus a sixth element: state or memory that lives outside the conversation.
Prompt engineering is about writing a good prompt. Loop engineering is about designing a system where you don't need to write individual prompts anymore — the loop does it for you.
Both OpenAI Codex and Claude Code ship all five primitives. The names differ slightly but the capability is the same. A loop designed for one works in the other with minimal adjustment.
Yes. Verification is the most important human role in the loop. A loop running unattended is also a loop making mistakes unattended.