Plan Mode for Your Problems, Edit Mode for Claude's

The 2-Hour Dead End

At work I had some data and needed to build a system that made predictions, using constraints from existing data. Not something I typically need to do. I thought I'd solve it by making a classifier to find common characteristics, and use those patterns to make the constraints. I worked on it, first working version, made 0% successful predictions. After another 15m its up to 5% success, sweet it's working. After another hour it's up to 21%. I'm confident that I'll have this done by end of the day.

Fast forward to the end of the day, and it's stalled at 23%. I'm generating so much code and it's not improving. In frustration I paused. Switched to Plan mode (Shift+Tab twice). Asked: "I need to make predictions using constraints from existing data. How could we do that?"

Claude immediately suggested sklearn—a library I know but don't use enough. It had the exact feature I needed, battle-tested and documented!

I'd wasted all that time hours directing Claude to build my overcomplicated solution instead of 2 minutes in plan mode telling it my problem

The Pattern: Directing vs. Asking

The mistake wasn't technical one. I was treating Claude like a junior developer executing my architectural decisions.

Here's the thing—Claude is trained on all of human knowledge. When you ask for its approach, you're tapping into solutions from thousands of developers who've solved similar problems. When you direct it to build your solution, you're limiting it to your knowledge alone.

The Mental Model: Plan Mode vs. Edit Mode

On the call, my brother and I worked out a simple rule that I hope makes this pattern stick:

"Plan mode for your problems, Edit mode for Claude's problems."

This is where you present the actual challenge you're facing. You're not dictating the solution—you're asking Claude to think, research, and propose an approach.

The workflow:

1. Hit Shift+Tab twice to enter Plan mode
2. Describe your problem (not your solution)
3. Ask: "What approach would you take?"
4. Review the plan critically

Edit Mode = Claude's Problems

Once Claude has proposed a solution, now you're directing implementation specifics. This is where your domain knowledge and preferences matter.

"Actually, use this library instead of that one" "Put this file here, not there" "Follow this naming convention" "Use our existing error handling pattern"

Claude has given you the architecture and approach. Now you're steering the details based on your codebase, your team's standards, your production environment.

The Simple Rule

Next time you're about to tell Claude how to build something, pause.

Ask yourself: Am I solving my problem, or am I directing a solution?

If you're solving a problem, switch to Plan mode. Describe the challenge. Ask what Claude would do.

After reviewing, switch to Edit mode. Direct the implementation details. Steer it toward your codebase patterns, your team's preferences, your architectural constraints.

The Bottom Line

I wasted 2 hours building the wrong thing because I was directing instead of asking. A simple question—"What approach would you take?"—would have saved those 2 hours and produced better code.

The rule sticks because it maps to the two modes: Plan mode for your problems (asking), Edit mode for its problems (directing).

Try it. Next time you're about to tell Claude what to build, switch to Plan mode and ask for its approach first.

You might be surprised how often Claude's solution is better than the one you were about to direct it to build.