Plan Mode Without the Terminal

How to Get Claude Code's Best Feature Using GitHub Copilot in Visual Studio

I’ve been around long enough to remember when Visual SourceSafe was state of the art. We’ve seen a lot of silver bullets come and go. UML diagrams that nobody maintained. Agile standups that turned into status meetings. DevOps pipelines that needed their own pipelines. Now we have AI coding assistants, and this time something actually works.

Claude Code has this plan mode feature that’s genuinely clever. It analyzes your codebase, creates an implementation plan, then waits for you to approve each step before executing. It’s a surgical checklist for code. Gawande would approve.

But maybe you’re in Visual Studio working on county systems that need to stay in the Microsoft ecosystem. Maybe your IT department hasn’t blessed another command line tool. Maybe you just want to use GitHub Copilot because it’s already there. Good news: you can get the same benefits. It takes a little discipline, but it works.

Why You Need a Plan

The default Copilot experience is conversational. You ask a question, it gives you code, you paste it in. This works fine for small things. But try adding a feature to an Oqtane module or refactoring a Blazor component hierarchy and watch it fall apart.

The problem isn’t the AI. The problem is you’re making it up as you go. The AI suggests something, you follow it, then three files later you realize you should have started somewhere else. You’re flying by eyesight in fog.

That Model 299 bomber was too complex to fly from memory, so they invented the checklist. Your codebase is the same way. You need pause points. You need a plan you can verify before you start.

How Plan Mode Works

Claude Code’s plan mode is simple: you describe what you want, it analyzes your workspace, generates a numbered list of steps, and stops. It waits. You can ask questions, request changes, approve it. Only then does it execute, one step at a time.

The forcing function is the point. You can’t skip the planning step. It’s like Strategic Doing, you have to say what you’re doing before you act. The action goes faster because the plan is clear.

The Visual Studio Version

Here’s the workflow. It gets you most of the way there.

Start with @workspace

Open the Copilot chat window. Type @workspace to let it see your whole solution. This matters. Without workspace context, Copilot is guessing.

@workspace Analyze the PermitModule. I need to add photo upload for contractors during site inspections.

Ask for a plan first

Don’t let it jump to code. Make it write the plan. Here’s your template:

@workspace Create a numbered plan with: (1) Files to modify, (2) Changes per file, (3) Dependencies between steps. Wait for my approval.

You’ll get something like this:

1. Create IPhotoService interface

2. Implement PhotoService with file storage

3. Add PhotoUploadComponent.razor with GPS metadata

4. Update PermitController endpoint

5. Add database migration for PermitPhoto table

Review and fix the plan

This is your pause point. Read it. Does it make sense? Did it miss anything? Push back if you need to:

We use local file storage, not Azure. Also add notification to inspectors when photos upload. Revise the plan.

Copilot will update it. Keep going until you’re satisfied.

Execute one step at a time

Don’t say “do the plan.” Say “implement step 1.” Review the code. Commit. Then “implement step 2.” Keep the chat window open. That’s your state.

Implement step 1

Copilot generates the interface. You look at it. If it’s good, commit and keep going. If not, iterate. “Add GPS coordinate properties to UploadPhotoRequest.”

Use the shortcut commands

After a step, use /fix for compiler errors or /tests to generate unit tests. These are fast and don’t mess up your main plan.

What’s Different

The big difference: Copilot won’t execute anything without you. This is actually good. You’re the forcing function. Every step needs your go ahead. It’s more manual but safer. The AI never runs wild in your codebase.

The chat window is your plan document. Keep it open and you have the full context and sequence. Close it and you lose that state. So leave it open. Treat it like an open file.

Claude Code can execute steps after you approve the plan. With Copilot you drive every single action. More work, more control.

When to Use This

Use it when things get complex. Adding a feature that touches multiple files. Refactoring a Blazor component tree. Migrating data structures. Integrating a new service.

Skip it for simple stuff. Fixing a typo. Adding one property to a class. Basic search and replace tasks.

The forcing function matters when the task is complex enough that thinking through the steps first actually helps. If you already know what to do, just do it.

How This Fits Into Bedlam and ICECAP

If you know about the Bedlam workflow (BDD + LLM = controlled chaos), this is the same idea. We believe in forcing AI into proven structures. This Copilot workflow is the manual version.

Bedlam generates Gherkin features from transcripts, then generates code and tests in parallel. Everything flows from the features file. The LLM can’t wander because the BDD structure constrains it.

This Copilot workflow is smaller scale but same philosophy. You constrain the AI by making it produce a plan first. The plan becomes your checklist. You execute one item at a time. The AI fills in the blanks but the structure holds.

Not full Bedlam automation. You still manually approve each step. But same principles. Checklists work. Pause points work. Constraints make AI useful instead of chaotic.

Tips That Actually Help

Be specific up front. Don’t say “add photo uploads.” Say “add photo uploads for contractors during permit inspections, GPS metadata in database, file storage in /App_Data/PermitPhotos.”

Reference the plan by number. When you say “implement step 3” Copilot knows what you mean. It just made that plan. If you say “add the photo component” it might forget the GPS part you talked about.

Commit between steps. Git is your safety net. If step 4 goes wrong you revert to step 3 without losing steps 1-3.

Break big plans into chunks. Got a 12 step plan? Maybe do steps 1-4 then reassess. Plans change as you learn. Don’t commit to all 12 before you know if 1-4 work.

Keep the chat open. The Copilot chat is your working memory. Need to walk away? Leave it open. When you come back you’ll remember where you were.

The Real Point

The value isn’t that Copilot writes better code. It’s that you have a better plan before you start. You thought through the dependencies. You know which files change. You spotted the risky parts.

That’s what checklists do. They make you pause and think instead of just reacting. The Model 299 bomber didn’t need fancy autopilot. It needed pilots who remembered to unlock the elevator controls before takeoff. The checklist made sure they did.

Your Blazor app doesn’t need sentient AI. It needs you to think through the implementation before you start. This workflow makes you do that. The AI makes it faster once you have a plan.

Where This Goes

This manual workflow is a bridge. Eventually we want the full Bedlam pipeline. Transcripts to features to parallel generation of tests and code. All living in the repo together. Enforced by CI/CD.

We’re not there yet. That’s fine. We’re learning what works. Building the habits. Getting comfortable with LLMs as tools that need structure, not magic wands.

Small civic organizations can’t afford six month development cycles. They need working software in weeks. This workflow collapses that timeline. Interview the stakeholders. Generate the plan. Execute the plan. Deploy.

The economics work. Our competitors will figure this out. We should figure it out first.

Try It

You don’t need Claude Code to get the benefits. You need discipline. Force the AI to make a plan. Review it. Execute step by step. Commit between steps. Keep your chat open.

The AI fills in implementation details fast. But the forcing function, the checklist, the pause points, that’s what makes it actually helpful instead of just fast and wrong.

Gawande was right about checklists. Strategic Doing is right about pause points. Bedlam is right about constraining LLMs. This is the manual version. The principles hold. Give it a shot.