VS Code's second AI opinion is a critique, not an approval

Visual Studio Code 1.135 adds GitHub's experimental Rubber Duck command to Copilot Agent Host sessions. A developer can ask a complementary model for a second opinion on the agent's work without leaving the IDE. The feature can surface assumptions, missed details, and edge cases before an implementation moves farther downstream.

That extra perspective is useful, but it changes neither the test result nor the person or system authorized to approve a release. Engineering teams should place Rubber Duck between the primary agent's proposal and their existing verification path. This article explains what the new VS Code surface does, what GitHub's earlier CLI implementation reveals about the mechanism, and which evidence still has to come from outside the model conversation.

What changed in VS Code 1.135?

GitHub's August 31 changelog says a developer can use the experimental /rubber-duck command in a Copilot Agent Host session. GitHub describes the result as a second opinion from a complementary model intended to surface missed details and edge cases.

The VS Code 1.135 release notes give the same bounded description. Rubber Duck appears under Agent Host, the dedicated process that runs agent harnesses and connects the Copilot experience across products. The release is rolling out gradually, and the feature remains experimental.

Those sources establish an IDE entry point and a purpose. They do not say that a Rubber Duck response is an approval, a security review, an executed test, or evidence that a change satisfies repository policy. They also do not state that VS Code automatically invokes the critic at the same checkpoints documented for Copilot CLI.

How does the second-model critique work?

GitHub described the fuller mechanism when it introduced Rubber Duck in Copilot CLI in April. In that experimental implementation, a focused review agent uses a model from a different family than the primary orchestrator. At publication time, GitHub identified GPT-5.4 as the critic when a Claude model was orchestrating, while noting that it was exploring other pairings.

The critic returns a short list of concerns about the plan or work: assumptions to question, details the primary agent may have missed, and edge cases worth considering. The primary Copilot flow then reasons over that feedback and shows the user what changed. In the CLI implementation, Copilot can seek critique around a plan, a complex implementation, tests, or stalled progress; a person can request it as well.

This dependency order matters. Rubber Duck is not a detached certification service that signs an immutable artifact. It is another model call inside the agent workflow, and its feedback can become input to the same flow that produced the work.

What do GitHub's benchmark numbers establish?

GitHub reports that Claude Sonnet 4.6 paired with a GPT-5.4 Rubber Duck closed 74.7% of the measured SWE-Bench Pro performance gap between Sonnet and Opus 4.6. For problems spanning at least three files and 70 steps, the company reports a 3.8% improvement over its Sonnet baseline and a 4.8% improvement on the hardest problems identified across three trials.

These are vendor-reported results from a difficult open-source coding benchmark. They support GitHub's decision to experiment with a complementary model and suggest that cross-family critique can change outcomes on some complex tasks. They do not predict a team's production defect rate, review time, security posture, or return on investment.

The pairing is also part of the tested configuration. A result reported for Sonnet 4.6 with GPT-5.4 cannot be transferred automatically to every future pairing, repository, task type, or VS Code release. Teams should preserve the selected models when they evaluate the feature locally rather than recording only that “Rubber Duck was on.”

Why isn't a second model an independent approval?

Different model families can have different blind spots, which is the reason the feature exists. But diversity of perspective is not the same as independence of evidence. Both models receive a task framed by the same workflow, and the primary agent interprets the critic's response before presenting a revised result.

A critique can say that a test case is missing. Only running the relevant test can establish its observed outcome. A critique can flag a possible authorization problem. It cannot establish that the application enforces the intended access rule across its real identities and data. A critique can question an architectural choice, while the accountable maintainer still decides whether the tradeoff fits the system.

BaristaLabs' interpretation is that Rubber Duck belongs in the proposal layer. It can improve the questions attached to a plan or diff. Repository-native checks, required human review, and release controls remain in the verification and authority layers.

Where should teams place the critique?

Use it early enough that changing direction is still cheap. For a substantial task, ask for critique after the primary agent drafts a plan and before it edits many files. If the change is already implemented, use the response to choose additional checks, not to waive checks that were already required.

Preserve four items for one representative evaluation: the primary model and plan, the critic model and concerns, the revision made after critique, and the external verification result. That record lets a reviewer distinguish “the second model raised this” from “the test proved this” and “the maintainer accepted this.”

A useful evaluation includes tasks where the critic adds no value, raises a false concern, or misses a defect found later. Otherwise the team records only successful anecdotes and cannot judge when the extra model call is worth the delay and usage. The experimental label is a reason to measure the complete path rather than assume stable behavior.

For low-risk work, the critique may remain optional. For complex refactors, broad file changes, or unfamiliar subsystems, teams can make it a deliberate checkpoint before expensive implementation. Security-sensitive and production-critical changes still need the controls assigned to those risk classes; a second model should not silently lower the review floor.

What should the rollout decision be?

Enable the experiment for a narrow task class when the team can identify the model pairing, preserve the critique, run the repository's normal checks, and keep human release authority unchanged. Compare representative tasks with and without the second opinion, including review time, useful concerns, false concerns, escaped defects, and total model usage.

Wait when the organization cannot tell which model acted as critic, the agent's revisions overwrite the reasoning trail, or reviewers are likely to read “second opinion” as “independent approval.” In those conditions, the feature adds another generated conclusion without making the delivery evidence clearer.

VS Code has made cross-family critique easier to request during coding. The business value will not come from counting how often a second model speaks. It will come from placing that perspective before a verification path that can prove what the models only proposed.

BaristaLabs helps teams design coding-agent delivery paths through AI development. If one workflow needs a clear boundary between generated critique, executed checks, and release authority, bring one representative task to a focused review.

Sources

• GitHub Changelog: GitHub Copilot in VS Code, August 2026 releases, August 31, 2026.
• Visual Studio Code 1.135 release notes, August 26, 2026.
• GitHub Blog: GitHub Copilot CLI combines model families for a second opinion, April 6, 2026.

GitHub controls feature availability, model pairing, experimental behavior, and the benchmark claims described in its sources. BaristaLabs supplies the operating interpretation and rollout recommendations.