Contents
TL;DR — A coding agent can turn a vague request into a coherent implementation in minutes. But coherence does not make it the right solution. Plan mode makes assumptions visible, checks constraints and helps choose a direction before those decisions become code someone has to maintain.
RSS
RSS sends new articles to the reader of your choice, without an algorithm or newsletter.
Asking an agent to start coding straight away is tempting. In a few minutes, it can create a service, change a controller, update templates and add tests. You can see progress, sometimes even a working demo. But you still do not know whether the agent understood the requirement.
An incomplete request does not necessarily stop the agent. It leaves gaps for the agent to interpret. The agent fills them with assumptions, then turns those assumptions into code. That is where the problem begins: the result can be clean and well structured while still answering the wrong question.
The first draft has become cheap to produce
Coding agents have lowered the cost of a first draft. They can inspect a repository, find the files that matter and propose an implementation quickly. That is a real gain. It simply moves the risk somewhere else.
The problem is no longer just whether we can produce the code. It is deciding what to build, where it belongs and which constraints it must respect. A request like “add support for X” often leaves important questions unanswered: What should happen at the edges? What data is available at this point in the system? Which versions need to be supported? Should the behavior be configurable? How should it be removed or rolled back?
When those answers are missing, the agent cannot infer the business context. It chooses a plausible interpretation and moves ahead. The further it goes, the more that interpretation becomes part of the architecture.
The resulting code is not necessarily bad. It may even be very coherent. It is simply built around a decision nobody has validated yet.
What I ask for in plan mode
For me, plan mode is not a formality before the “real” work. I ask the agent not to change any code during this phase. First, it restates the requirement. Then it inspects the existing code, separates what it has verified from what it is assuming, and flags the information that is still missing.
I also ask it to surface the choices that could shape the implementation: which files or services are involved, compatibility requirements, dependencies, data being handled, risks and ways to verify the result. If there are several reasonable approaches, it should describe them and explain their trade-offs.
Multiple-choice questions help bring out decisions we have not yet put into words. Should we prioritize compatibility with the existing system, simplicity, performance or future change? Which behavior is non-negotiable? The agent can help clarify these choices, but we still make the decision.
The point is not to create another document. It is to review the reasoning, challenge an assumption and change direction before that direction has spread across several files.
A PrestaShop hook can shape the whole implementation
Consider a common case: adding a feature to a PrestaShop module. Choosing a hook can look like a small technical detail. In practice, it determines when the code runs, in which context, with what data and across which target versions. It can also affect the theme, caching, interactions with other modules and performance.
If the agent chooses a hook before checking those constraints, it can build the whole feature around the wrong entry point. That may become clear later: the required data is not available there, behavior differs between PrestaShop versions, or the theme integration does not match the requirement.
At that point, we may need to do more than change one method. We might have to move the logic, revisit a service, update a template and redo the tests. We also need to check the module’s installation and uninstall paths: a registered hook or obsolete configuration can be left behind after the implementation changes.
A useful plan checks the entry point before implementation begins. Does the hook exist in the versions we need to support? Does it provide the right context? Is it the right place for this responsibility? These questions are quick to answer before coding. They cost more once several components depend on the answer.
Follow-up prompts do not replace scoping
Once coding has started, we can always ask the agent to “move this logic,” “add this rule” or “keep this case compatible.” Those exchanges are part of development. The problem starts when they are used to compensate for a decision that was never examined in the first place.
The agent can update the file we point to and adjust nearby code. That does not guarantee it will find everything that should be removed, moved or tested again. A series of locally reasonable changes can make the whole feature harder to understand.
When corrections start to pile up, it can be better to stop adding instructions and revisit the original question: is this still the right structure? What should be removed or rebuilt cleanly?
Avoiding AI bloat
I use AI bloat to describe the accumulation of plausible code whose need has never been established: an abstraction introduced too early, an extra dependency, a configuration option nobody uses, or a service added because it seemed useful to the agent.
This code is not always bad. Often it is perfectly reasonable, which makes it easy to approve. But every file and mechanism we add will have to be understood, tested and maintained.
A plan lets us ask the question before creating anything: why does this responsibility need to exist? Why is this dependency necessary? Why do we need this configuration or caching mechanism? If the answer is still vague, it is better to clarify the need before adding the solution.
The goal is not to count lines or reject every abstraction. It is to avoid mistaking a complete solution for a useful one.
A validated plan also gives us a way to verify the result
A reviewed and approved plan gives us a reference point during code review. We can check whether the implementation meets the original requirement, respects compatibility constraints and follows the decisions made at the start. We do not stop at “it compiles” or “the demo works.”
The plan also helps define the tests. If it identifies edge cases, target versions and acceptance criteria, those details can guide validation. Without that reference, we often test only the happy path that drove the implementation.
The faster agents produce code, the more clearly we need to know what we are checking. A fast first draft does not remove the need to understand what was added or why.
Before implementation, choose a direction
Plan mode does not replace experience or developer responsibility. An agent can help examine the requirement and make choices visible. We still have to decide whether the assumptions hold and whether the plan is worth implementing.
My rule is simple: before I let an agent change code, I want to understand the requirement it has taken from my request, the constraints it has verified, the ones it is assuming and how we will validate the result. If an important point is still unclear, the code waits.
The first prompt for a feature does not always need to ask for an implementation. It can ask the agent to think, inspect the existing code and challenge the direction first. Once the plan is approved, the next challenge is to control execution and verify what the agent produces. Without a clear direction, the best safeguards will only catch later a mistake we could have avoided at the start.
