The Five-Step Agentic Coding Loop

An opinionated refinement of the Plan, Prompt, Execute, Review loop that most agentic-coding guides describe.

The four-step version is everywhere, and it is basically right. But after running it on a real codebase for a while, two things kept biting me that the standard version either understates or skips. This is the version I actually use:

Plan, Prompt, Execute, Review, Record.

The standard loop, in one line each

1. Plan. Force the design decisions before the agent writes a single line. Data schema, stack, and the work broken into vertical slices (one feature built end to end, from database to logic to UI) rather than all the tables first.
2. Prompt. Feed the agent the specific slice, not "build the app." Start every slice with a discussion prompt: "Explain how you intend to implement this. Do not write code yet." Read the plan back before any code exists.
3. Execute. The agent reads files, installs packages, writes the logic, and runs its checks.
4. Review. You become the editor. Run it, read the diff, check the logs.

All of that is correct. Here is where I diverge.

Divergence 1: "Never interrupt the agent" is bad advice

The common guidance says that letting an agent run a long, uninterrupted sweep is safer, because interrupting it "fragments its memory and corrupts state."

This is mostly wrong for modern coding agents. They commit work to disk, not to a fragile in-memory state. A long unsupervised sweep across a large codebase is more dangerous, not less, because a single wrong assumption made early compounds across every file it touches before you ever see it.

The right principle is not "never interrupt." It is this: scope each execution to one vertical slice with a clear definition of done, then stop and review.

Smaller sweeps, reviewed often, committed often. A wrong turn costs you one slice, not an afternoon of tangled changes.

Divergence 2: Review is more than "read the diff and watch the UI"

Reading the git diff line by line before committing is the heart of the whole loop, and most guides underweight it. But there is a category of bug that the diff and the UI will both hide from you: anything that looks right and behaves wrong.

The clearest example is access control. The moment your project gains a backend, "the UI renders correctly" tells you nothing about whether data is actually scoped to the right user. A dashboard that displays your own records perfectly can still be leaking everyone else's through an unguarded query. The screen looks identical either way.

So Review has more than one dimension:

• Diff review. Read every changed line before you commit.
• Behavioural review. Run it, click through it, read the logs.
• Security and authorization review. Verify that data access is actually enforced where it matters: row-level security, auth guards, permission checks. This one is invisible to the first two.

If your slice touched anything to do with who can see what, the review is not done until you have confirmed it from the data layer, not from the screen.

Divergence 3: there is a fifth step, and skipping it rots the loop

Every guide ends Review with "now go back to Plan and do the next feature." That instruction quietly assumes your context is still accurate. It will not be for long.

If you are working with an agent across many sessions, the agent only knows what your project docs tell it. Every slice you ship changes the truth. If you do not write that change down, the next session starts from a stale map, and stale context is where agentic projects quietly fall apart.

So the real loop has a fifth step.

5. Record. Update the status of what you just shipped, append to your decisions log (the why, not just the what), and bump the dates on whatever orientation docs a future session reads first.

It takes two minutes, and it is the difference between a project that compounds and one that drifts.

The loop I actually run

Plan     Retrieve and confirm the slice. If you have living design docs,
         this is mostly "pull up the spec and sanity-check it," not
         "write a fresh PRD every time," which just creates drift.

Prompt   Feed the slice. "Explain first, do not code yet." Verify the
         plan back before any code exists.

Execute  One vertical slice. Checkpointed. Committed when done.

Review   Diff, then behaviour, then security and authorization. The screen
         looking right is not the same as it being right.

Record   Update status, append the decision and its reasoning, refresh
         the docs the next session will read first.

         Then back to Plan for the next slice.

Why these three changes matter

The four-step loop optimizes for speed within a session. These three changes optimize for correctness across sessions, which is the thing that actually breaks when you build something real with an agent over weeks instead of over an afternoon.

• Small reviewed slices beat long sweeps, because errors do not get to compound.
• Security review is a separate sense, because the two obvious senses are blind to it.
• Recording is what keeps the agent's map of your project true.

Credit

Written by vipplovchoudhary.

This is a refinement of the widely described Plan, Prompt, Execute, Review loop, sharpened against what actually held up when shipping real features with a coding agent over many sessions. The four-step version is common knowledge. The three divergences above are the parts I would argue for.