Planning Before Prompting

When you have an AI coding assistant at your side, the temptation is to start immediately: describe the project, watch code appear, iterate. This approach works surprisingly well for tiny scripts and isolated experiments. It breaks down, often catastrophically, for anything larger than a few hundred lines. The reason is architectural: AI models generate locally coherent code — the snippet they produce makes sense on its own — but without a plan, there is nothing to keep the pieces globally coherent. You end up with a collection of fragments that each look fine and do not work together.

Why Planning Changes Everything

A plan is a shared context. When you sit down with a human collaborator to build something, you spend time aligning on the goal, the scope, the components, the data model, and the sequence of work. That alignment means when your collaborator writes a function, it fits the architecture you both understand. An AI assistant has no memory of your previous conversations by default, no understanding of your project's existing structure unless you provide it, and no ability to infer your architectural decisions from code it has never seen. This means the plan you would have shared with a human collaborator must be explicitly written down and provided to the AI on every relevant prompt. A well-written plan does several things: It constrains the solution space. Instead of generating a generic solution, the AI generates one that fits your specific component boundaries, data model, and technology choices. You get code that slots in rather than code that needs to be rewritten to fit. It reduces hallucination. AI models occasionally invent library methods that do not exist or assume APIs have capabilities they lack. When your prompt specifies the exact libraries, versions, and interfaces you are using, the model has less room to improvise incorrectly. It enables incremental building. A plan divides the project into named, ordered tasks. Each task can be a separate prompt. The output of each prompt can be tested before the next task begins. This incremental approach catches errors early, when they are cheap to fix, rather than at integration time when the whole system is broken and it is unclear where the fault lies. It produces reviewable code. When you receive code from an AI, you need to understand it well enough to decide whether it is correct. If you understand your own architecture, you can review AI-generated code purposefully: does this component respect its interface? Does it handle errors correctly? Does it access only the data it is responsible for? Without an architecture in mind, review is guesswork.

There is a specific failure mode worth naming: the monolith trap. Without a plan, an AI will often produce a single large file that does everything. This is because the model is responding to your prompt locally — it generates whatever makes the current prompt's request work. Without guidance, it puts everything in one place because that is the path of least resistance for the generation task. A monolith built through iterative AI prompting is extremely difficult to maintain. When you ask the AI to add a feature, it may rewrite sections you depend on. When you ask it to fix a bug, it may introduce a regression elsewhere in the same file. The monolith provides no seams — no clean boundaries where you can safely replace one piece without touching others. The antidote is explicit component specification in your prompts. Instead of "build me a to-do app," you say "implement the TaskList component according to this interface: it accepts an array of task objects and a callback function onComplete(taskId); it renders each task with a checkbox; calling onComplete passes the task's ID to the parent. Use no global state and import nothing beyond React and the types I have defined." That prompt produces a component that fits your architecture, not a monolith. Planning also helps when you need to correct or debug AI-generated code. If the AI produces a function that handles authentication and also sends emails, you know from your plan that this violates your component design — and you can ask the AI to refactor those responsibilities into separate modules before the code is integrated into the project.

What a Good Pre-Prompt Plan Contains

A pre-prompt plan is a short written document — often just a structured set of notes — that you prepare before opening an AI chat. It does not need to be long; it needs to be complete enough that any competent engineer (human or AI) could work from it without asking basic clarifying questions. A minimal effective pre-prompt plan contains: Project summary: One paragraph describing what the project does, who uses it, and what problem it solves. Component list: The named components, each with a one-sentence responsibility description and its interface (inputs/outputs). Data model: The key entities, their attributes, and their relationships. Technology decisions: The language, framework, database, and any critical libraries already chosen. Current task: A precise description of the one thing you are about to build — not the whole project. The project summary and component list can be reused across many prompts as a context header. The current task changes with each prompt. This structure keeps your AI prompts focused on one thing at a time while keeping the broader context available.