GitHub Copilot Fusion Goes GA: Evaluate the Final Diff, Not Just the Answer

The October 28 announcement says Copilot Fusion is generally available in Visual Studio Code, the GitHub Copilot app, Copilot CLI, and JetBrains IDEs. GitHub instructs users to update their client, select Copilot Fusion in the model picker, and choose an effort level.

Selecting Fusion means choosing a routing system rather than a specific model. According to GitHub, it decides which models should handle a prompt and how they should work together. That moves a recurring decision out of the developer’s hands, but it also changes what a useful evaluation should record: the effort level, models used, resulting changes, and work required to accept them.

This article analyzes the announcement and documentation. We have not tested Fusion, so its capabilities below are documented vendor descriptions, not independently observed behavior.

GitHub presents three selectable levels: Fusion Standard for everyday coding, Fusion High for challenging tasks and deeper reasoning, and Fusion Max for the most demanding work. The Fusion documentation adds an important distinction: Standard selects one model for each task, while High and Max can involve additional model calls.

Our editorial recommendation is to begin with Standard on ordinary maintenance work, such as a small bug fix with clear acceptance criteria. Try High when a task spans several related files or requires reasoning through a difficult failure. Treat Max as another candidate to evaluate against the same requirements, rather than assuming its label establishes better results.

GitHub says Fusion is available across Copilot plans, but model selection depends on what is available to the user. Confirm the choices actually shown in your client before designing a team exercise around them.

Fusion’s documented execution patterns are Single, Cascade, and Critique. Single uses one model to complete the task. Cascade starts with an efficient model’s draft, then uses a judge to accept it or escalate to a stronger model. Critique produces a draft, gathers model feedback, and has the original model revise it.

The announcement describes Critique using another model as reviewer. The documentation gives a more detailed description involving multiple models critiquing independently in parallel, with their feedback aggregated. Both describe automated review followed by revision; neither establishes that the resulting code satisfies your project’s requirements.

GitHub also says different prompts within one session can use different patterns. Evaluate the completed change against explicit checks instead of treating the presence of a critique step as an approval. Our AI code review workflow explains how to keep that acceptance decision separate from the assistant’s own assessment.

The documentation’s most consequential limitation for a coding workflow is concrete: if Fusion discards a draft, changes that draft already made in the workspace are not automatically undone. GitHub specifically advises reviewing changes before committing them.

That matters because the final response can represent a revised approach while the workspace still contains edits from an earlier attempt. A developer reading only the concluding explanation could overlook changes outside the intended solution. This is an implication of the documented limitation, not a failure we observed in testing.

For a proposed pilot, begin from a known repository state and inspect every changed file afterward. Check whether each edit belongs to the accepted approach, whether unrelated changes remain, and whether the final explanation matches the actual diff. Use regression tests for AI-generated code to turn the original failure into a concrete acceptance check.

Choose a reproducible bug with a clear expected outcome. Record the starting commit, prompt, client version, and acceptance checks. Run each candidate effort level from the same starting state in a separate trial so an earlier attempt does not supply changes to the next one.

GitHub says users can follow the model used at each step and inspect a list of models beneath the response. Record the information your client exposes, along with elapsed task time, follow-up prompts, failed checks, and manual corrections. These are proposed measurements; this article supplies no results.

Judge success by the final repository state and the effort needed to review it. One successful task should justify another bounded trial, not a team-wide conclusion. Repeat with a different task type before deciding which effort level belongs in your routine.

Fusion is worth evaluating when choosing and switching models has become recurring work. Its appeal is a simpler decision for the developer: choose an effort level and let the system handle the execution pattern. Whether that improves your workflow remains a question for your own tasks.

The documentation says the model pool and execution patterns can change over time. Keep the evaluation recipe so you can revisit it when behavior changes. Expand adoption only when repeated trials produce acceptable changes with manageable review effort. If unexplained edits or repeated corrections make the result harder to assess, keep the trial narrow until you understand why.