Rubber duck debugging works because explaining your reasoning to something that can’t push back forces you to notice the gaps yourself. VS Code 1.135, shipped across the August 2026 release cycle, took that idea and gave the duck an opinion. The new /rubber-duck command in Copilot Agent Host sessions invokes a second AI model — deliberately different from the one driving your session — to review the primary agent’s plan, code, or tests and surface what it missed. It’s not rubber duck debugging anymore. It’s adversarial review, built into the editor, on demand.

What Shipped

VS Code 1.135 introduces the Agent Host Protocol, and three features sit on top of it:

  • /rubber-duck — an experimental command that hands the current plan, diff, or test suite to a different model for critique. If your primary session is running Claude, the duck can run GPT or Gemini, and vice versa — the point is a genuinely different model, not the same model asked to second-guess itself.
  • External session continuation — agent sessions started in other applications (say, a Claude Code CLI run) now show up in VS Code’s Sessions list, and you can pick them up mid-task without losing context.
  • Multi-window session connection — the Agent Host lets multiple VS Code windows attach to the same running agent session, so you can watch (or steer) one long-running agent from more than one place.
# inside an active Copilot Agent Host session in VS Code
/rubber-duck

# the critic model receives: current plan, diff so far, test output
# it responds with a structured critique — not a rewrite, a review

The distinction that matters: /rubber-duck doesn’t hand control to the second model. It stays a critic. The primary agent keeps driving; the duck just gets a formal turn to say “did you consider X” before you commit to the plan.

Why a Different Model, Not the Same Model Twice

Self-critique from a single model has a well-known failure mode: the same weights that produced a blind spot are often the same weights evaluating whether that blind spot exists. Asking Claude to review Claude’s own plan catches surface-level mistakes — a missed edge case in obviously wrong logic — but it’s much weaker at catching the kind of systemic bias where the model’s whole approach to the problem was subtly off. A structurally different model, trained differently, tends to disagree in more useful places.

This mirrors something good engineering orgs already do with human review: you don’t want the PR author reviewing their own PR, and you get more value from a reviewer who thinks about the problem differently than one who’d have written it the same way. VS Code just automated the “get someone who’d approach this differently” step and made it a slash command instead of a Slack ping.

Where This Actually Helps

Plan review before code exists. Firing /rubber-duck at a proposed implementation plan — before the primary agent writes a line — is the highest-leverage moment to use it. Catching “this approach won’t handle concurrent writes” at the plan stage costs one critique cycle. Catching it after 200 lines of generated code costs a rewrite.

Test coverage gaps. Pointing the duck at a generated test suite and asking it to find untested branches plays to a specific strength: a second model with no investment in the first model’s test-writing choices is more likely to notice “there’s no test for the empty-input case” than the model that just wrote the tests and, implicitly, believes they’re sufficient.

Architecture decisions with real tradeoffs. For anything with a genuine judgment call — cache invalidation strategy, retry/backoff design, schema migration approach — a critique from a differently-trained model surfaces alternative framings faster than re-prompting the same model with “are you sure?”, which tends to produce polite agreement more often than substantive pushback.

Where It Doesn’t Replace Anything

/rubber-duck is not a substitute for human code review, and treating it as one is the failure mode to watch for on your team. It catches a different class of error than a human reviewer does — it’s very good at “did you consider this edge case” and structurally weak at “does this match how our team actually wants this feature to behave,” “is this consistent with the three other places we solved a similar problem,” or “does this introduce a security assumption our threat model doesn’t cover.” Those require context the critic model doesn’t have unless you explicitly feed it, and even then, a human who knows your codebase’s history has judgment the critique loop doesn’t.

The multi-window session connection has a similar boundary: it’s genuinely useful for a tech lead wanting to observe a long-running agent task from a second machine without interrupting it, but it’s not a governance feature. Anyone with access to that session can steer it, so treat shared session access with the same care you’d give shared production credentials.

Practical Adoption Pattern

  1. Default /rubber-duck into your plan-review step, not your final-diff step. The earlier you catch a flawed approach, the cheaper the fix — this is true whether the critic is a person or a model.
  2. Pick a critic model deliberately different from your driver model. If your team standardized on Claude for the primary agent, don’t default the duck to another Claude session — the whole value proposition depends on architectural difference, not just a fresh context window.
  3. Don’t skip human review because the duck approved. Log what the duck flagged and what it missed for a few weeks. That log tells you concretely where it adds value on your codebase and where your human reviewers are still doing work no model-vs-model critique loop replaces.
  4. Use external session continuation for handoffs, not for parallelism. Picking up a CLI-started session in VS Code to finish reviewing it is a good use. Running the same session steered from two people at once, expecting it to behave predictably, is asking for the kind of race condition worktree isolation was built to prevent in the first place.

The Pattern Behind the Feature

This is the same trajectory multi-agent tooling has been on all year: single-model workflows are giving way to structured multi-model workflows where different models play deliberately different roles — driver and critic, generator and verifier, implementer and reviewer. The interesting shift isn’t that a second model can catch mistakes the first one made. It’s that editors are now shipping the orchestration for that pattern as a built-in primitive instead of leaving it to teams to wire up themselves with separate API calls and custom glue code. Expect the next iteration to formalize roles further — a critic that also runs a subset of tests, or a security-focused critic distinct from a correctness-focused one — rather than staying a single generic /rubber-duck command.

Thuận Lương is a Technical Lead with 15+ years in .NET, cloud architecture, and AI systems. He writes about real-world lessons from building production systems.

Export for reading

Comments