When the agent changes the plan halfway through

Suppose, for the sake of a concrete case, that you approved a plan yesterday. It said the agent would add rate limiting to the public API by wrapping the existing handlers, with limits read from config. Short, clear, easy to say yes to. Today you open the pull request and the handlers aren't wrapped at all. The agent moved the limits into a new middleware layer and changed how config loads at startup. Maybe that's a better design. But now you have two documents in front of you that disagree, and nothing that says when the plan changed or why.

This is an opinion piece, and here's where I land. I think agents re-plan mid-run, and they should. The problem isn't the re-plan. It's that the re-plan usually lives only in the diff. My suggestion is to treat a re-plan as a new decision. The agent writes it into the plan before it keeps going, and a person gives that change a fresh read, the same way a changed diff gets one.

Re-planning is normal, and often right

It's worth saying this plainly first, because the easy version of this post is a complaint about agents that don't follow instructions. That's not my point.

Plans are written before contact with the code. They're a best guess made from the outside. Then the agent opens the files and finds that the handlers share a base class nobody mentioned, or that config is loaded in a way that makes the original approach awkward. A good engineer would change course at that point. So would a good agent. A plan that never changes after the first file is opened is either very lucky or not being looked at.

So I don't want agents that refuse to deviate. I want the deviation to be visible. In the hypothetical above, the middleware approach might be the right call. I'd still like to know that it was a call, and what pushed the agent toward it, before I'm reading a diff that assumes I already agreed.

The failure is the silent re-plan

Here's what goes wrong. The plan says one thing. Partway through, the agent decides on another. It doesn't go back and change the plan. It just starts writing different code. The plan stays exactly as approved, frozen at the moment before anyone knew more.

By the time you review, you're doing a comparison nobody set up for you. You read the plan, then the diff, and you try to work out where they split. Was the change deliberate or a drift? Did the agent hit a real constraint, or misread the plan? Is there anything in the original plan that it quietly dropped along the way? You're reconstructing a decision from its side effects.

I think this is worse than it looks, for a couple of reasons. First, the approved plan carries authority it no longer deserves. It has your sign-off on it. Anyone reading it later, including a fresh agent session, will reasonably treat it as the current intent, even though the code says otherwise. Second, the reasoning behind the change is gone. The agent knew why it switched to middleware at the moment it switched. If it never wrote that down, the diff only shows the outcome, and the outcome can look like a mistake or like a better idea, depending on who's reading.

Diff review also isn't the right place to approve a design change. When you're reading code, you're checking whether it does what was agreed. You're not in the frame of mind to ask whether the agreement itself should change. A re-plan buried in a diff gets reviewed as code, not as a decision.

The habit: plan first, then code

The habit I'd recommend is simple to describe. When the agent decides the plan needs to change, the first thing it touches is the plan, not the code.

It writes a short change into the plan file. What's different now, and why. "Switched from wrapping each handler to a shared middleware. The handlers inherit from a base class that already intercepts requests, so wrapping them would run the check twice. Config now loads limits at startup instead of per request." A few sentences is enough. The point is that the change has a home in the same document you approved, written at the moment the agent had the reason in hand.

Then a person reads that change. Ideally before the work continues, if the change is big enough that you'd want a say in it. At the latest, before the pull request, so you read the new plan first and the diff second. Either way, the re-plan gets reviewed as what it is: a new decision that deserves the same attention the original plan got.

We've found that asking for this in plain words, in the brief, works better than hoping it happens. Something like: "If you decide the plan needs to change, stop and write the change into the plan first, with what changed and why. Then continue." Nothing enforces that sentence. It's an instruction, and like any instruction an agent can miss it. But it gives the agent a clear place to put the change, and it gives you a clear place to look.

A couple of details make the habit easier to keep.

Keep the change next to what it replaces. If the plan said "wrap each handler," the update should sit right there, saying that approach was dropped and what replaced it. A note at the bottom that says "see changes" just recreates the original problem inside one file.

Say what got dropped, not only what got added. Re-plans tend to describe the new approach in detail and skip the parts of the old one that quietly fell away. If the original plan included a per-route override and the new design doesn't, that belongs in the change, in its own sentence.

Don't make the change invisible. The reader should be able to tell that the plan changed, not just see a plan that looks like it was always this way. Writing "changed during the run" next to the update is enough.

What this does and doesn't fix

This won't catch a re-plan the agent never writes down. If the agent changes course in its head and goes straight to the code, the plan stays stale, and you're back to comparing two documents that disagree. I think the habit lowers the odds of that. It doesn't remove them. Reading the diff against the plan is still part of review.

It also doesn't mean every small adjustment needs a ceremony. Renaming a helper or splitting a function the plan never mentioned isn't a re-plan. The line I'd draw is whether you'd have wanted to weigh in. If the change alters the approach, the scope, or something you explicitly agreed to, it goes in the plan first.

Review the change in the plan

Here's the reframe I'd leave you with. We usually think of review as reading the code that changed. When agents re-plan mid-run, the more important change is often in the plan, and if nobody writes it down, there's nothing to review except its effects.

So ask for the re-plan where you'd expect to find it. When the approach changes, it goes into the plan first, with what changed and why, and someone reads that before they read the diff. Then the plan you approved and the code you're reviewing tell the same story, and the decision that changed in between gets the read it deserved.

Written by the team building Gander, live review for markdown an agent is still writing.