What does it mean when GitHub Copilot CLI is rubber-ducking my code?

If you use GitHub Copilot CLI, you may occasionally see a message like this while it is working:

Rubber-duck (model: claude-opus-5)
Review revision sync changes.

The actual topic of review of course changes depending on what you are currently doing. This is not just a funny status message; instead, Copilot CLI has a built-in rubber duck agent that can ask another AI model to review the work being done. The more office friendly name for this is simply code review.

The name comes from the old programming technique called rubber duck debugging. The idea is simple: when you are stuck with some code, explain the problem in small pieces to someone else, or even to an inanimate object such as a rubber duck. Of course, the duck obviously does not solve the problem.

But explaining your assumptions and reasoning out loud often makes you notice the mistake yourself. This very commonly happens with human colleagues, too: you start explaining something, and before the other person answers, you've already found the solution.

GitHub Copilot CLI applies a modern variation of the same idea. While the main agent is planning or implementing a change, it can stop and send the current plan, code, or tests to a second agent for criticism.

The important detail is that the reviewer deliberately uses a different AI model from the one driving the main session.

For example, if the main session is running with a GPT model, the rubber duck may use a Claude model. If the main session uses Claude, Copilot may select a GPT model for the review. The exact model can change. Copilot CLI selects a suitable critic model automatically.

The idea is to avoid asking exactly the same model to simply reconsider its own answer. Different model families may have different blind spots and may notice different problems.

The rubber duck looks for substantive issues such as:

• logic errors
• missing edge cases
• security problems
• architectural mistakes
• cross-file conflicts
• weak or incomplete tests
• performance problems.

It is intentionally a reviewer rather than another coding agent. The rubber duck has read-only access to the codebase and does not make the changes itself.

The main Copilot agent receives the critique and decides how to act on it. Copilot can invoke the rubber duck automatically at useful points, for example after creating a plan, during a complicated implementation, or after writing tests. For small and obvious changes, it may skip the extra review completely.

You can also ask for a review manually:

/rubber-duck What edge cases are missing?

Or simply ask in natural language:

Rubber duck your plan.

Another useful request is:

Get a critique of the changes you've made so far.

I've seen the feature in GitHub Copilot CLI 1.0.84, although the rubber-duck feature itself was introduced earlier and has been evolving through several CLI releases. One thing to remember is that the second opinion is not free. It means another model gets a reasoning task, so the review adds some latency and model usage. For a one-line change, that probably does not buy much.

But for more complex work, like a database migration, authentication change, complicated refactoring, or multi-file editing, an independent critique before continuing can be much more valuable.

I like the idea because it mirrors a good engineering practice: do the work, but occasionally stop and ask another pair of eyes to challenge your assumptions.