Engineer the loop, not the prompt

There's a phrase making the rounds for the real work around a coding agent: loop engineering. The idea, as Addy Osmani frames it, is to stop being the person who prompts the agent and start building the system that does — the loop that instructs, validates, and refines on its own. The unit you optimize is no longer the prompt. It's the loop. Which leaves one obvious question hanging: what does the loop run against?

Three loops, one of them yours

Andrew Ng describes agentic development as three nested feedback loops. The innermost is the agent's own coding loop — write, test, find the problem, fix, retest — and it turns in minutes, increasingly without you. The outermost is the external loop: real users, real reactions, turning over days and weeks. In between sits the one that's actually yours: the developer feedback loop, where you look at what came back and say what should change — and those changes become new specifications and evaluation criteria. The fast loop is being automated out from under you. The slow loop you can only nudge. The middle loop is where your judgment still does the work.

The middle loop's output is a document

Look at what the developer feedback loop actually produces: new specifications and evaluation criteria. That isn't a vibe or a passing chat message — it's a written artifact. Decisions the agent has to respect, and the checks that say whether it did. Run that loop in a chat window and the artifact evaporates every turn: the criteria live in your head, the agent re-guesses them, and next week nobody can say what “done” even was. Run it against a document and the loop finally has something to hold onto. That document is a plan.

What a loop needs, a plan already is

One breakdown (Shubham Saboo's) splits a loop into five parts: a trigger, execution, validation, memory, and exit conditions. A resolved plan quietly supplies most of them. It's the memory — the state that carries between iterations, so the agent isn't re-deriving the same decisions from a fading transcript. It's the validation — what “done” means, written down (and in the strong case, hardened into an executable acceptance suite). And it's the exit condition — the resolved feature set, the line past which there's nothing left to decide. The agent's inner loop supplies the execution; the plan supplies everything it executes against.

And that's also what lets the fast loop close on its own. The agentic coding loop — write, test, find the problem, fix, retest — only runs without you to the degree the agent knows what “fixed” means. Hand it a vague spec and it spins, or declares victory early; hand it a resolved plan and its tests have something true to check against. So a tighter plan doesn't only steer the developer loop — it makes the agent's loop more autonomous, which is the whole point of engineering it.

Loops rot — maintaining the plan is how you stop it

The unglamorous truth of loop engineering is that loops decay. The term for it is drift: your PRD template, your checklist, your rubric slowly go stale — criteria that no longer match the product, steps nobody follows — and the loop keeps confidently producing the wrong thing. A loop is only as good as the assets it reads, and assets rot. So the real job isn't writing the loop once; it's keeping it current.

This is the part inplan is built for. A plan here doesn't rot, because updating it is the interaction: the agent drafts and raises the new open questions inline, you resolve them in place, and you review each change like a pull request. The maintenance isn't a chore bolted onto the loop — it's the same back-and-forth that is the loop.

Loop engineering isn't a better prompt. It's a better-maintained plan — the one artifact all three loops read from and write back to.

The human stays in the loop that needs a human

The reason to engineer loops at all is to spend humans where humans are still ahead. The agent's inner loop is fast and getting faster; you don't want to sit inside it hunting bugs. What you have that it doesn't — yet — is context: who the user is, what the product is for, which of two reasonable options is actually right here. Loop engineering's whole division of labor is: automate the execution and validation, reserve the human for direction. That's exactly the seam inplan draws. The agent handles the drafting and flags every decision it can't make alone; you make the decisions. You're not writing the code, and you're not writing the prompts — you're engineering the loop, by answering the questions that shape it.

Engineer the loop, not the prompt

So if the advice is to stop tuning prompts and start engineering loops, the most direct way to do it is also the least exotic: build the plan the loops run against, and keep it alive. Hand the resolved plan to the agent and its inner loop tightens around it. Update the plan when the external loop teaches you something, and every faster loop inherits the change. The plan is the developer feedback loop made durable — the memory, the validation, and the exit conditions the whole system leans on. Engineer that, and you've engineered the loop.