The Usual Disaster

If you're reading this, you've probably been there. You open your AI assistant, feeling optimistic. "Hey, can you refactor this authentication system to use JWT tokens?" you ask. The model enthusiastically agrees and proceeds to delete half your middleware, hallucinate some packages that don't exist, and somehow break your database migrations in the process.

You try to course-correct with follow-ups. "No, keep the session logic." The assistant apologizes profusely and restores some code while quietly breaking something else. Three prompts later, you're running git reset --hard and wondering if you should just do it yourself.

This is how most people start with AI coding assistants. It works fine for trivial tasks, but for anything complex, it's a recipe for chaos. The model loses context, starts hallucinating, and you end up babysitting it more than you'd spend just writing the code.

The "Thousand-Line Prompt" Era

The intermediate solution many engineers discover is pre-planning. Instead of iterating in chat, you spend a session preparing a directory of detailed prompts. Something like:

instructions/
  ├── summary.md
  ├── stage-1-setup.md
  ├── stage-2-core-logic.md
  ├── stage-3-integration.md
  └── stage-4-testing.md

Each file contains exhaustive instructions: "First, update the user model in models/user.ts to add these three fields. Then modify the validation schema. Don't touch the auth middleware yet, we'll do that in stage 3..."

This approach actually works. The model stays focused, hallucinations drop significantly, and you maintain control over each stage. The problem? Your prompts balloon to thousands of lines. Reviewing them becomes nearly impossible. You're essentially writing documentation so detailed that you might as well have written the code itself. It's powerful but painful.

Planning the Plan (Yes, Really)

Since Cursor and other tools introduced Plan mode, there's a better way. The key insight is this: Plan mode produces manageable output. A plan is rarely more than a few hundred lines, which means you can actually review and adjust it.

For small to medium tasks, you can just use Plan mode directly and execute. But for the really complex stuff—bootstrapping a new service, major refactorings, features that touch dozens of files—you can use Plan mode to build that documentation directory for you.

Think of it like Xzibit on Pimp My Ride: "Yo dawg, I heard you like planning, so I put a plan in your plan so you can plan while you plan."

The Process

Here's how it works:

1. Ask Plan mode to build your documentation directory

The crucial part is being explicit about what you want:

Please prepare a detailed implementation plan for migrating our auth
system from sessions to JWT. Create this as a directory structure
where each stage is its own markdown file. This plan is specifically
for another agent to execute, so be thorough and specific about file
locations and changes. DO NOT modify any code yet.

2. Review the plan

You'll get something manageable—maybe 200-300 lines total. You can actually read this. Check if stages make sense. Add edge cases the model missed. A useful trick: ask "Does this plan look complete to you?" Sometimes the model will realize it forgot to handle migrations, or testing, or whatever.

3. Execute the plan

Switch to Agent mode and let it build the documentation directory. You'll end up with your feature-xyz/ folder full of detailed instructions.

4. Execute stage by stage

Now you're in familiar territory: "Using the instructions in stage-1-setup.md, implement stage 1." Check the output. If it looks good, move to stage 2. If not, you know exactly which stage went wrong and can adjust.

When to Actually Use This

Let me be clear: this approach is overkill for most tasks. If you're fixing a bug or adding a simple endpoint, just use Agent mode directly. This is for the big stuff:

• Bootstrapping new services
• Major architectural refactorings
• Large features that span many files
• Anything where "just running it" and seeing what breaks isn't acceptable

It's more time-consuming upfront, but you get predictable results and maintain control. No more git reset --hard at 2 AM.

The Real Benefit

The best part isn't just the control—it's that you're forced to think through the problem first. By the time you've reviewed the plan and built the documentation, you actually understand what needs to happen. The AI becomes a force multiplier for your thinking, not a magic box that sometimes works.

Plus, that documentation directory? Keep it. Next time you need to do something similar, you have a template. Or when someone asks "how does our auth migration work?"—you literally have the manual.

Final Thoughts

AI coding assistants aren't going to write your app for you. Not yet, anyway. But used correctly, they can handle the tedious implementation details while you focus on architecture and edge cases. Plan mode is the first tool that makes this actually practical for complex work.

Just remember: the goal isn't to avoid coding. It's to avoid coding the boring parts while maintaining the same quality you'd write yourself. If you find yourself fighting with the model more than you'd spend just writing code, you're doing it wrong.

And maybe run git commit before you start. Just in case.

The final draft of this article was generated with AI assistance, but the idea and planning were crafted manually out of my head and experience. This is why there is a quick summary on the top.