A deprecation warning surfaced in a config path we rarely touch, so we dropped the message into the agent and asked for a fix. It came back with a tidy snippet: guard the call, fall back to the older method, add a one-line comment explaining the choice. The unit tests passed. CI went green. We merged.

The break only showed up under the real configuration, which our tests do not cover. The method the snippet called had been removed in the installed major and replaced with a plain property. The old name still existed as a deprecated alias that silently ignored its argument, so the call compiled, ran without throwing, and changed nothing.

Why the top vote is the wrong signal

Upvotes accumulate over years. The accepted answer wins for readers on the major version that shipped when the question was asked; a newer, correct reply for the current API often sits below it with fewer votes. The search index ranks by age and accumulated agreement, not by compatibility with your lockfile today.

Votes answer one question: was this ever useful to someone? They do not answer: does this method still exist on the pinned major, and does it behave the same way now? The agent trusts the top result because it reads confidently and carries a high score, and that confidence outranks the version check nobody asked for.

Check the answer against the installed version before accepting it

Three cheap checks block most of this class:

  • Read the accepted answer's year and the version it names, then compare that major to the one pinned in the lockfile. A gap of one or more majors means treat the snippet as a hypothesis, not a fix.
  • Grep the installed package for the exact symbol the snippet calls. A name that survives as a deprecated alias can typecheck and still no-op; confirm the current shape of the method or property, not just that the string exists.
  • Rebuild the call against the current framework documentation for the installed version. Use the Q&A thread to understand the problem shape, then write the call against today's API rather than copying the old body.

Where the tests let it through

The unit test exercised the path with defaults and asserted only that the function returned without raising. A call that silently does nothing still returns cleanly, so absence of an exception is the wrong assertion here. Assert the observable result: read the config value back, inspect the outgoing request shape, or verify the side effect the call was supposed to produce. A no-op call that changes nothing should fail that test, not pass it.

A ten-second review habit

Before accepting a pasted snippet, ask the agent one question: which major version does this answer target, and does the pinned dependency still support that exact method name? Keep it on the review checklist. It takes seconds, and it catches regressions that a defaults-based test suite cannot see.

The index ranks answers by how many people found them useful once; your lockfile ranks by what runs today. Those two lists rarely agree, and the confident top result is the one most likely to be stale.