How do you decide whether a coding agent should plan before editing?

Example Answer

The way I'd approach it in an interview is this: I decide based on scope and dependency structure. If the change touches one file and the path is obvious, planning can just add overhead. If the task spans several modules, has rollout implications, or needs coordination between code, tests, and docs, planning usually improves execution.

The important part is that the plan should earn its keep. A good plan narrows scope, identifies validation steps, and exposes assumptions. A bad plan is just extra prose before the same guesswork.

So I want planning where it reduces uncertainty or review risk, not as a ritual before every edit.

What I always try to avoid is giving a process answer that sounds clean in theory but falls apart once the data, users, or production constraints get messy.

Common Poor Answer

A weak answer is saying coding agents should always plan first. Planning is useful when it reduces uncertainty, not by default.