QWE AI Academy Multi-file implementation plan from a GitHub issue. No code yet – just which files to touch and what to do in each one. That’s what Copilot Workspace’s planning phase gave you.
The technical preview was sunset on May 30, 2025.GitHub Copilot Workspace evolved into the fully agentic Copilot Coding Agent – GA since September 2025. The spec-plan-implement workflow still exists, split between Copilot Coding Agent (task execution) and Copilot Spaces (context grounding). This article documents how Workspace’s planning phase worked – understanding that process helps you use what replaced it.
What you got from planning
The output: a file list (creates, edits, deletes, renames) plus bullet steps under each one describing the exact changes. The plan listed out every file it intends to create, modify, or delete, as well as a bullet-point list of the actions to be taken in each file. No implementation code. Just the roadmap.
Why split it? You could catch mistakes – wrong file, missed dependency, bad approach – before Workspace burned tokens generating thousands of lines. Plans regenerated cheap. Implementations didn’t.
Two planning paths with different outcomes
Method A: Auto-generate the plan.Copilot Workspace generates a proposed specification, which is a bulleted list which articulates the state that the codebase would be in after resolving the task. The proposed specification is focused on defining the success criteria of the task, as opposed to getting into implementation details (which is the role of the plan). Fast. File selection sometimes missed context.
Method B: Edit the spec, then plan. After Workspace created the initial spec, you added detail – file names, edge cases, expected behavior. To steer Copilot Workspace towards better file selection, you can mention file names, directory names, etc. in the issue/task panel. Just write it naturally. Then regenerated. Slower upfront, more accurate plan.
Method B won for anything beyond trivial changes. Workspace’s file selection (LLM inference + code search) wasn’t always smart about dependencies. Hints reduced rework.
Starting a planning session
Three entry points:
From a GitHub issue:Open the issue and click the “Open in Workspace” button on the right side panel (underneath the “Development” section).
From the Workspace dashboard:Click “Choose a repository” under “Start a new session” – search for your repo, then define a new task from scratch (kind of like a draft issue).
From a repo page:Navigate to the repository, click the green “Code” button, enter a task from the “Copilot” tab. Submit → Workspace analyzes it.
Anyone with a paid Copilot Individual, Business, or Enterprise subscription could use it. Free tier? Blocked.
The spec→plan workflow in detail
After Workspace read your issue, it generated a “topic” – question-form summary of the task. The topic distills the task down to its essence, giving you an early and fast opportunity to see if Copilot Workspace is on the right track. First checkpoint: wrong topic? Edit or bail.
Next: the spec. Two parts – current state (what the code does now) and proposed state (what it should do after). Both bullet lists. Both editable. Like the spec, the plan is fully editable and regeneratable, which allows you to refine and steer Copilot Workspace in the right direction. Review, fix misunderstandings, click “Generate plan.”
Workspace listed files. Each got steps describing what needed to happen. Each changed file includes a list of specific steps that indicate the exact changes that need to be made. Add files, remove files, edit step descriptions. After edits: “Regenerate selected files” updated just those files – no full rebuild needed.
Pro tip:Often Copilot Workspace will get a task mostly right, but may have trouble with some parts. Select file(s) in the Plan panel, add bullet points, click “Update selected files” to reimplement those file(s) with the new instructions. Selective regeneration saved tokens and time.
What broke (constantly)
| Problem | Root cause | Workaround |
|---|---|---|
| Plan missed relevant files | Copilot Workspace must determine which files in a repo are relevant to the task. This is hard, and Copilot Workspace may not always select the right files. | Mention file/directory names in your task before generating the plan |
| Plan included irrelevant files | LLM picked files via semantic similarity – sometimes too aggressive | Manually remove files from plan, or edit spec to clarify scope |
| Steps too vague | High-level instructions, not detailed pseudo-code | Edit step descriptions for detail, regenerate implementation for those files |
| Whole-file rewriting | Copilot Workspace currently uses “whole file rewriting” as we have found this achieves a high level of thoroughness on the very heterogeneous range of tasks. | None – design choice. Large files? Slow. Sometimes replaced content instead of modifying |
| Hit usage quota mid-session | You have exceeded your usage quota per hour. Copilot Workspace is a limited preview and we’d like everyone to have a chance to try it out. Pro users had quotas too | Copilot Workspace will now display a counter so you can keep track of how many tokens you have left – plan ahead or wait |
The OAuth trap for company repos
Copilot Workspace uses a GitHub OAuth App for authentication. Some organizations can have policies which restrict OAuth applications. You will not be able to perform tasks in private repositories, or create pull requests in public repositories unless the organization admin approves the Copilot Workspace OAuth application. No warning until you tried. Fix: ask admin to approve OAuth app in org settings.
When to stop tweaking the plan
Plans were infinitely editable. Power and trap. You could regenerate a dozen times, tweaking the spec each iteration. Diminishing returns kicked in fast.
The cutoff: right files listed + step descriptions made sense? Good enough. The diff editors are editable, which allows making minor tweaks directly to the code, as opposed to iterating via changes to the task, spec, or plan. Fix details in code after implementation. Spending 20 minutes perfecting a plan to save 5 minutes of code editing was backward.
Think of planning like a rough map before a road trip. You want the major highways right – which city, which route, where to stop. Obsessing over every street name and gas station location? That’s what GPS is for. Same with Workspace: the plan caught catastrophic route errors (wrong file, wrong approach, misunderstood requirement). Those showed up cheap. Fixing them after 15 files were generated? Expensive.
What replaced the workflow
GitHub Copilot Workspace evolved into the fully agentic Copilot Coding Agent – GA since September 2025. More autonomous – assign an issue, it works in background, review PR when done. Less stepwise control, faster execution.
The spec-plan separation? Now it’s internal to the agent. You don’t see the intermediate plan unless the agent hits an error and asks for clarification. You assign a GitHub issue to Copilot, and it independently analyzes the issue description and repository context. The coding agent works asynchronously — you assign the issue and come back later to find a ready PR.
For context grounding: Copilot Spaces. A Space is a collaborative container: you pull in repositories, issues, documentation files, and custom instructions, then use it as a persistent grounding context for Copilot Chat. Ask a question and Copilot answers with the full context of everything in your Space – not just the file you have open. Spaces replaced the manual file-hinting you did in Workspace specs.
The benchmark that didn’t tell the whole story
Copilot Workspace scored 55% on SWE-bench Verified in March 2025, the highest result among commercial coding tools. That benchmark measures end-to-end issue resolution: read issue, understand codebase, write multi-file fix, pass tests. Beat Cursor (48%) and Claude (37%).
What SWE-bench didn’t measure: abandoned sessions because the plan was nonsense. Time spent regenerating plans until file selection worked. Whether developers actually merged the generated code. SWE-bench measured completion, not productivity. Workspace could solve synthetic issues. Faster than writing code manually? Depended entirely on plan iteration count.
FAQ
Is GitHub Copilot Workspace still available?
No. Sunset May 30, 2025. Workflow evolved into Copilot Coding Agent (autonomous execution) and Copilot Spaces (context management). The planning methodology lives on – you just don’t interact with it directly.
Could you edit the plan after implementation started?
Yes. If you aren’t satisfied with the proposed changes, you don’t have to start over from scratch. Simply edit the spec or plan at any point, and Copilot Workspace will regenerate all the downstream steps with your new input. Go back to the plan, add a file, change a step, regenerate just that file’s implementation. Non-linear workflow by design.
What if the plan was completely wrong?
Three options. One: edit the spec to clarify what you wanted, regenerate plan from scratch. Two: manually rewrite the plan – edit file lists and step descriptions yourself. Three: bail on the session, start over with a more specific task description. Option 1 usually fastest. Workspace’s planning quality correlated strongly with how well-specified the original issue was. Garbage in? Garbage plan out. Simple, clear statements of intent like “Switch to use Python numpy” or “Add more unit tests for the server code” can get you a long way. But turns out vague issues like “make it better” produced vague plans – who knew? One debugging session with a fuzzy issue taught most people to front-load the specificity.