From Chat to Plans: A First Step Into Spec-Driven Development

Theory

Most engineers start using AI coding assistants in chat mode: describe what you want, get some code back, paste it in, iterate. That works fine for small, well-understood tasks. But as the complexity grows, chat mode starts to break down. The agent doesn't have enough context, the output drifts from what you intended, and you spend more time correcting than building.

Plan mode is the answer to this. Instead of jumping straight into implementation, the agent first:

Analyzes your codebase to understand what already exists, what patterns are in use, and what files are relevant to the task
Pulls the relevant context so the implementation is grounded in your actual project, not a generic guess
Creates an implementation plan in a structured format (usually a markdown file) that lists what it intends to change, why, and in what order
Waits for your approval before writing a single line of code

This step is more valuable than it might seem. The plan surfaces assumptions the agent is making, decisions that need your input, and dependencies you might not have considered. Reviewing and correcting the plan before implementation begins is almost always faster than fixing a half-built feature after the fact.

Why this matters

Without a plan phase, the agent has no way to validate its understanding of the task before acting on it. With a plan, you get a checkpoint: you can see exactly what the agent intends to do, cut steps that are out of scope, redirect the approach, and add context the agent missed. A good plan also makes the implementation phase more reliable because the agent is executing against a structured roadmap rather than reasoning on the fly at each step.

In tests comparing plan-mode vs. straight-to-code implementations of the same feature, plan mode consistently produces better-structured logic, cleaner components, and more thoughtful handling of edge cases. The difference is more pronounced on complex tasks and when using less powerful models.

Plan mode in Cursor vs. Copilot

Both Cursor and Copilot support plan mode, but the experience differs.

Cursor generates a .plan.md file that opens directly in the editor. It is readable, editable, and stays in your file tree as an artifact you can reference during implementation. Once you approve it, a single click switches the agent into build mode and it executes the plan step by step.

Copilot displays the plan inside the sidebar panel. It offers a "Create File" button to save it and a "Build" button to start implementation. The plan is slightly less detailed than Cursor's but still useful. The UX is a bit rougher at the moment: saving the plan can fail in some versions, so you may need to manually prompt the agent to proceed.

How this connects to Spec-Driven Development

Plan mode is not the same as a full spec. A spec defines intent, constraints, and acceptance criteria before the agent gets involved at all. A plan is what the agent generates after it reads that spec (or your prompt) and maps it to your codebase.

But plan mode is a good first step in the right direction. It introduces the habit of reviewing AI intent before AI action. Later in this learning path (Day 5 and Day 6) you'll build on this with formal spec files and SDD frameworks. For now, plan mode gives you the most important part of that workflow: a human review checkpoint before implementation begins.

Practice

Run this in a repository you already know, not a toy project. The point is to feel where the practice helps and where it gets in the way on code that has history.

Pick a moderately complex task from your current work, something that touches at least two files and requires some design decisions. It should be real work, not a toy example.

Write a clear task description. One paragraph: what you want to build, any constraints, and what "done" looks like. Don't use bullet points yet, just describe it naturally.
Run plan mode. In Cursor, press Shift+Tab to switch to Plan Mode before submitting. In Copilot, select "Plan" from the agent mode dropdown. Submit your task description.
Review the plan carefully. Read every step. For each one, ask:
- Is this step correct?
- Is anything missing?
- Is anything out of scope?
- Are there assumptions here I disagree with?
Make at least two corrections. Edit the plan directly (in Cursor, you can edit the .plan.md file; in Copilot, add a follow-up message). Remove steps that aren't needed, add context the agent missed, or redirect an approach you don't agree with.
Build from the corrected plan. Let the agent implement it and observe how closely it follows the plan you approved.
Reflect. How did the plan differ from what you would have built without it? What did the agent catch that you hadn't thought through? Where did it still need correction during implementation?

Read the Nearform article linked above before you start. It walks through a real test of both tools with a concrete feature and the results are a useful reference for what to expect.