Copilot Workspace

Discover how GitHub Copilot Workspace transforms issues and ideas into fully implemented, multi-file code changes through an AI-driven planning and implementation workflow.

What is GitHub Copilot Workspace?

GitHub Copilot Workspace is an AI-native development environment that takes a fundamentally different approach from traditional coding. Instead of helping you write code line by line, Workspace operates at the task level - you describe what you want to accomplish, and it creates a complete plan and implementation across your entire codebase.

Think of Workspace as a senior developer who reads your issue, understands your codebase, drafts a technical specification, creates an implementation plan, writes the code across all necessary files, and then lets you review everything before committing. The key difference from other AI tools is that you remain in control at every step - you can edit the spec, adjust the plan, and modify the generated code before anything touches your repository.

Workspace is accessible directly from GitHub.com. When you open an issue, you will see an "Open in Workspace" button that launches the Workspace environment for that specific task.

The Workspace Workflow: Issue to Pull Request

Copilot Workspace follows a structured, four-stage workflow that mirrors how experienced developers approach complex tasks. Each stage builds on the previous one, and you can intervene at any point.

Stage 1: Issue Analysis

Workspace begins by reading the GitHub issue (or your natural language description) and analyzing the relevant parts of your codebase. It identifies which files are likely to be affected, what patterns exist in your code, and what the issue is really asking for.

Stage 2: Specification

Based on its analysis, Workspace generates a specification that describes the current behavior of the system and the desired behavior after the changes. This is presented in plain English so you can verify that Workspace understood the task correctly.

Current Behavior:
- The /api/users endpoint returns all users without pagination
- Response includes sensitive fields like password_hash and api_key
- No rate limiting is applied to this endpoint

Desired Behavior:
- The /api/users endpoint supports pagination with page and limit parameters
- Default page size is 20, maximum is 100
- Response excludes sensitive fields (password_hash, api_key)
- Rate limiting of 60 requests per minute per API key is applied
- Response includes pagination metadata (total, page, limit, pages)

Stage 3: Plan

Workspace then creates a detailed implementation plan listing every file that needs to be created, modified, or deleted, along with a description of the changes for each file.

Files to modify:
1. src/routes/users.js
   - Add pagination parameters (page, limit) with validation
   - Add field filtering to exclude sensitive data
   - Apply rate limiting middleware

2. src/middleware/rateLimiter.js (NEW)
   - Create rate limiting middleware using sliding window algorithm
   - Configure 60 requests/minute per API key

3. src/utils/pagination.js (NEW)
   - Create pagination helper for consistent response format
   - Calculate total pages and metadata

4. tests/routes/users.test.js
   - Add tests for pagination, field filtering, rate limiting
   - Test edge cases (page 0, negative limit, exceeding max)

Stage 4: Implementation

Finally, Workspace generates the actual code changes for every file in the plan. You see a full diff view showing exactly what will change, and you can edit any file before proceeding.

Editing and Refining the AI-Generated Plan

You are never locked into what Workspace generates. At every stage, you can edit, add, or remove items. This collaborative approach is what makes Workspace practical for real-world development.

Common refinements you might make:

• Adjusting the specification - Add constraints Workspace missed, such as backward compatibility requirements or specific error messages
• Adding files to the plan - Workspace might miss a configuration file, a migration, or documentation that needs updating
• Removing unnecessary changes - Sometimes Workspace proposes refactoring that is out of scope for the current task
• Changing the approach - You might prefer a different pattern than what Workspace suggests (e.g., using an existing library instead of writing custom code)
• Splitting the plan - Break a large plan into smaller, reviewable chunks

After you edit the plan, click "Regenerate" to have Workspace produce updated code that reflects your modifications. You can iterate on this cycle as many times as needed.

Multi-File Changes and Orchestration

One of Workspace's strongest capabilities is coordinating changes across multiple files while maintaining consistency. When implementing a feature that touches models, routes, tests, and configuration, Workspace ensures that:

• Type definitions match across files
• Import statements are added wherever the new code is referenced
• Test files cover the new functionality with appropriate mocks
• Configuration files are updated to reflect new options or dependencies
• Existing patterns in the codebase are followed for naming and structure

For example, if you ask Workspace to add a new API endpoint, it will typically generate changes across all of these layers:

Modified files (7):
  src/models/subscription.ts        (+45 lines)  - New data model
  src/routes/subscriptions.ts       (+82 lines)  - Route handlers
  src/services/subscriptionService.ts (+67 lines) - Business logic
  src/validators/subscription.ts    (+34 lines)  - Input validation
  src/routes/index.ts               (+2 lines)   - Register new routes
  tests/routes/subscriptions.test.ts (+120 lines) - Integration tests
  docs/api.md                       (+28 lines)   - API documentation

Running and Testing Code in Workspace

Workspace includes an integrated development environment where you can run and test the generated code before creating a pull request. This environment includes:

• Terminal access - Run build commands, tests, linters, and any other CLI tools
• Live preview - For web applications, view your changes in a browser preview
• Iterative refinement - If tests fail, you can ask Workspace to fix the issues and regenerate
• Codespace integration - Open the Workspace session in a full GitHub Codespace for deeper debugging

A typical workflow looks like this:

1. Review the generated code in the diff view
2. Open the terminal and run npm test (or your project's test command)
3. If tests fail, tell Workspace what went wrong and ask it to fix the issues
4. Repeat until all tests pass and you are satisfied with the implementation
5. Click "Create Pull Request" to open a PR with all the changes

Workspace vs. Coding Agent: When to Use Which

Both Copilot Workspace and the Copilot Coding Agent can implement multi-file changes, but they are designed for different scenarios. Understanding when to use each will make you more productive.

Current Status and Getting Access

Copilot Workspace is available as part of GitHub Copilot. To access it:

• You need an active GitHub Copilot subscription (Pro, Business, or Enterprise)
• Navigate to any GitHub issue and look for the "Open in Workspace" button
• You can also start a Workspace session from a blank task by visiting copilot-workspace.githubnext.com
• Workspace sessions are saved automatically so you can return to them later

As with all AI-powered features, Workspace works best when your repository has clear structure, good naming conventions, and existing tests that serve as examples. The better your codebase's quality, the better the generated code will be.