GitHub's Copilot Workspace plans a change before writing code

The setup

GitHub opened a technical preview of Copilot Workspace on 29 April 2024, according to the company's own announcement, written by then-CEO Thomas Dohmke. Access started with a sign-up waitlist, not general availability. The entry point is a GitHub repository or an existing Issue; an archived GitHub Next project page, describing the research prototype behind the product, names the small team credited with building it and labels the effort a research prototype, not yet a shipped feature.

What the documents show

Both documents describe the same sequence: the tool reads an issue, including its comments and linked pages, and proposes a plan before writing code. GitHub's announcement states it offers a step-by-step plan based on its understanding of the codebase and issue replies, and stresses that everything proposed, from plan to code, is fully editable. The GitHub Next page adds a technical detail the announcement omits: validation runs through GitHub Codespaces as headless, ephemeral compute, so clicking Run pushes modified code to a new codespace, attempts a build, and feeds any error back to the model to attempt a repair. That is GitHub's own account of an automated retry loop, not an independent test of how often it succeeds.

The friction

Neither document claims a change reaches production without a person acting on it. The announcement is explicit about what follows a satisfactory plan: filing a pull request, running GitHub Actions and security code scanning, and asking teammates for human code review, the same path any pull request takes. The GitHub Next page frames iteration as necessary, noting a user can open the same issue in multiple tabs and try different paths when a first proposal is wrong, itself an admission that a single pass is not reliably correct.

What changed in the work

The documented shift is in where a developer's first move happens. Instead of a blank file, the starting artifact is a plan a person edits before code exists; GitHub's stated aim is lowering the barrier at a task's beginning rather than in the coding itself. Whether that changes total effort is not something either source measures, and a separate productivity figure GitHub cites elsewhere in the same post concerns its older autocomplete product, not Workspace, so it should not be read onto this tool. What the sources do support is a kept step: human review before merge did not go away, it moved later, after a plan and a build attempt already exist.

• Does the proposed plan actually reference the specific files and constraints of this repository, or generic patterns?
• How many build-and-repair cycles ran before the change was ready to review, and is that visible to the reviewer?
• What part of the review checklist changes when a pull request arrives with an editable plan already attached to it?

Reading the product announcement next to the research page behind it shows a consistent claim about where automation stops: at the pull request, where a person still has to say yes.