Plan before you generate 🗺️

Every developer who has tried a coding agent knows the moment: you type two lines of prompt, press enter, and you get a whole feature with tests, refactor, and an explanation so tidy it looks like it was written by a senior on a good day. You feel light. Then, three days later, the demo breaks in a way you did not foresee, and you realize you are paying the bill for that first thrill.

That bill is called rework. And this article is about how not to pay it twice.

An agent does not generate slow code: it generates wrong confidence fast.

The vibe coding scene 🎰

Let us call it by its name: vibe coding. You open the tools, describe the goal with a cloud of feelings (“make me a nice dashboard with metrics”), and let the code pour in. The first pass is always wonderful. The problem is not the first pass.

The problem arrives on the third one: when the dashboard must respect an access constraint, when the metrics need to match the source of truth, when someone asks to change something that, on closer look, was the backbone of everything. Every change drags the system in an unforeseen direction, and every fix generates new code to fix.

Vibe coding is not “fast”: it is fast on the first pass. You pay for the time later, with interest.

Why the agent does not plan by itself 🧭

A coding agent is an enthusiastic executor of the next step. You ask it to “add the filter”, and it does: in the most plausible way, with the structure that looks most obvious, without asking whether the filter belonged there, or whether it breaks the flow for whoever comes next.

That is not a flaw, it is a property. The agent optimizes the move, not the path. If you do not give it the path, it will give you a thousand beautiful moves and a random path.

A prompt asks for the next move. A plan says why that move is right.

This is where two ways of working split: using the agent as a machine that generates code, or using it as a machine that executes decisions already made. The second is more boring up front and infinitely more sustainable afterwards. If you want to understand what happens inside an agent when it “decides”, the right read is What is a coding agent.

The plan as a contract 📜

Explicit planning is the contract between human and agent. You do not need a forty-page document: a few lines answering uncomfortable questions will do.

• Goal: what must be true at the end, in one verifiable sentence.
• Constraints: what you do not touch, which conventions apply, which resources are off-limits.
• Success criteria: how we decide it is done.
• Boundaries: which files it may touch, where it must not put its hands.

When a plan exists, the agent’s output stops being a plausible proposal and becomes a verifiable commitment. When it is missing, you are delegating the decisions too — and then you are surprised when random decisions arrive.

In the plan → execute → validate work cycle this rule is the mandatory first step: not because bureaucracy is fun, but because an agent without a plan is a colleague who improvises.

The math of not planning 💸

Let us put it in unromantic terms. Every time the agent generates code without a plan, you burn three resources:

• Tokens: the wrong code must be generated, read, criticized, regenerated.
• Human time: every correction round needs someone to look, judge, and relaunch.
• Trust: after three disappointments, the team stops trusting — rightly so.

Rework is not a linear cost: it is a compounding one. Every rushed fix moves the system away from a clean structure, and the next step costs more. Vibe coding is cheap only if you do not count the second pass.

Plan → execute → validate 🔁

The good news is that the cure is a discipline, not a technology. The work cycle with an agent is simple: you plan what to do, you execute the plan, you validate the result against the success criteria. None of the three phases can skip the others.

The most delicate point is the return from validation: if the result does not meet the criteria, you do not generate more random code, you update the plan. A seemingly small detail, but it is the difference between adjusting the course and rewriting the map.

The full cycle, with a practical step-by-step example, is in the guide The work cycle: plan, execute, validate.

The plan comes from the specification 📐

There is a level even further upstream than planning: the specification. The plan says how to proceed; the specification says what must exist and why. If the specification is ambiguous, any plan is well-formatted wishful thinking.

The most honest method I know to avoid this is asking the right questions first: it is the same thread as Question-driven specification. When the questions are clear, the plan almost writes itself. When they are missing, the plan is a list of aspirations.

Conclusion: five lines before you send ✅

If you want a rule to apply tomorrow, here it is: before pressing enter on a prompt, write five lines of plan — goal, constraints, criteria, boundaries, files involved. It is not rhetorical art, it is a contract with your future self, the one who will have to read the code in three months.

An agent can generate code in a minute. The part you cannot delegate is deciding what must be true. And that is done before, not after.

Plan first, generate later: it costs less and finishes sooner.