There's a specific way agent mode fails that everyone who has used it knows by now. You give Copilot a broad task — "migrate this controller to minimal APIs and update the tests" — and it starts strong. It edits three files, runs a build, hits an error on step five, guesses at a fix, that fix breaks step two's work, and by step seven you're watching an autonomous system confidently dig a hole with no memory of why it started digging. You stop it, revert, and go back to writing smaller prompts by hand.
The new Planning feature in Visual Studio, now in public preview in Visual Studio 2022 version 17.14, is Microsoft's answer to that failure mode. And the interesting part isn't that Copilot "thinks before it acts" — models have done chain-of-thought for years. The interesting part is that the plan becomes a real, inspectable, editable file on your disk.
What Planning actually does
Planning lives inside agent mode, not beside it. When you send a request, Copilot decides whether it needs a plan at all. Simple prompts get an immediate answer; a genuinely multi-step task triggers a coordinated plan instead of an improvised sprint. In Microsoft's words, "Simple prompts get quick answers, while multi-step ones trigger a coordinated plan."
When it does plan, Copilot generates a Markdown file that lays out the task, the research steps it intends to take, and progress updates it writes as each step completes. Behind that Markdown sits an LLM-readable JSON file that tracks progress and — this is the part I care about — logs failed attempts. As the run proceeds, Copilot revises the plan against new results rather than barreling through a checklist it wrote once and never revisited. Progress is tracked directly in the plan file, so at any moment you can see what's done and what's next.
Both artifacts land in a temp folder:
%TEMP%\VisualStudio\copilot-vs\
You enable the whole thing from:
Tools > Options > Copilot > Enable Planning
The plan is the product
Here's my thesis: the model isn't the innovation here. The artifact is.
For a year, agent runs have been a black box with a scrollback. You could read the chat transcript after the fact, but you couldn't intervene in the machine's actual intentions, because its intentions lived in a context window you don't own. Planning externalizes that intent into a file you can open, read, and change while the run is live. That's a different category of tool. A generated plan reads roughly like this:
# Task: Migrate OrdersController to Minimal APIs
## Research
- [x] Locate OrdersController and its route attributes
- [x] Find integration tests referencing the controller
## Steps
- [x] Extract endpoints into a MapOrders() group
- [ ] Rewire DI registrations in Program.cs
- [ ] Update WebApplicationFactory-based tests
- [ ] Delete the old controller and run the full suite
## Notes
- Attempt 1 at test rewrite failed: fixture still resolved the controller type
That "Attempt 1 failed" line is the whole point. The agent isn't just telling you what it plans to do; it's showing you what it already tried and why it backed off. That is the context a senior engineer would carry in their head across a two-hour refactor, made durable and readable.
Does it move the numbers?
Microsoft ran this against SWE-bench, the standard benchmark of real GitHub issues, and reported that both GPT-5 and Claude Sonnet 4 did better with planning turned on — around 15% higher success and 20% more tasks resolved. They note they're continuing to test additional models to confirm the trend.
Read those numbers the right way. SWE-bench is a benchmark, not your codebase, and the post doesn't publish the full baseline methodology. But a 15–20% lift holding across two different frontier models from two different labs is a meaningful signal that the gain comes from the scaffolding, not from one model's quirks. When a technique helps GPT-5 and Sonnet 4 by similar margins, you're looking at a property of the workflow. That's the kind of result worth acting on.
The rough edges worth knowing before you rely on it
This is a preview, and it behaves like one in two ways you should internalize:
- Plans are temporary. They live in the temp folder above and are not saved with your repository. If you want a plan to survive the session — for a code review, a handoff, or an audit trail — you have to manually copy it into your repo. Microsoft says permanent storage is something they're exploring.
- Mid-flight edits don't apply instantly. You can open the Markdown plan and edit it while a run is going, but if you change it while a response is actively streaming, "changes may not take effect immediately." The reliable move is to stop the response, edit the plan, and restart.
That second caveat matters more than it looks. The headline promise — "you can adjust the plan mid-way" — has an asterisk: adjust it between steps, not during one.
The takeaway
Treat the plan file as reviewable code, because that's what it is. When you kick off anything larger than a two-file change, turn Planning on, then stop and actually read the generated Markdown before you let the agent execute a single step. That thirty-second read is your cheapest intervention point — it's far easier to fix a wrong assumption in a checklist than to unwind seven files of committed damage. And when a plan produces a clean result, do the thing the preview won't do for you yet: copy it out of %TEMP% and commit it next to the change. A good plan is documentation of why the diff looks the way it does, and right now Visual Studio throws that away by default. Don't let it.
Sources: Introducing Planning in Visual Studio (Public Preview) — Visual Studio Blog, Agent mode has arrived in preview for Visual Studio — Visual Studio Blog