VS Code 1.135 sends an agent's work to a second model for review

The pattern devops.com opens with is the one every team recognises: the agent writes confident code, the tests pass, and a human reviewer later finds the edge case the model never considered ^[15].

What the reviewing model gets to look at is what the first model produced ^[2]. Microsoft's framing is "a second opinion from a complementary model on the agent's work" ^[3]. That framing is honest about the limit. A model reading a diff can flag an unhandled branch or a test that asserts nothing. It has no access to the requirement that was never written down, or to the shape of the production data nobody sampled. Mitch Ashley of The Futurum Group puts it more bluntly: "Rubber Duck answers verification pressure with more generation, and that only goes so far" ^[11].

The arithmetic is simple and worth doing before anyone writes this into a review policy. A reviewed turn is two model passes on one task, the agent's and the reviewer's ^[13]. The reviewer's input is the primary's output, so the input side of the second pass grows with the size of the change. Until this release, teams running several models through Copilot had a poor read on where tokens went ^[10]; the new hover breakdown splits input, cached input and output per model on a given turn ^[9], which is the first time the reviewing pass has a visible price tag next to the work it reviewed.

Then there is how the feature is triggered. It is a typed command, which makes review opt-in per turn ^[14]. In practice, developers will likely reach for it on the changes that already worry them, and skip it at 6pm on the ones that do not. That makes it a habit that depends on someone remembering to invoke it, applied unevenly across a team rather than enforced on every change.

The Agent Host half of the release has a clearer beneficiary. It is for the developer with a task running long enough that they want to look in on it from a second window, or who left a session running in another application and does not want to rebuild the context by hand ^[4]. Teams that would rather not have cross-application agent activity appearing in the editor get a setting rather than an argument, which is more than most editor features offer ^[7].

A way to decide whether Rubber Duck earns a slot in your workflow: take the last three defects that escaped to production, and sort each on two questions. Was it visible in the diff? Did the tests pass anyway? The cell where both are true is the cell this feature is built for. If your escapes cluster in the other three, because the requirement was wrong, or the failure only appears under real traffic, then a second model reading the same diff buys tokens and a feeling of coverage. Knowing which cell your team keeps landing in costs nothing and settles the question.