The Hallucinated Version Number

AI models write code for the median version of a library across the internet, not the version pinned in your lockfile. That mismatch, not a flaw in reasoning, is why clean-looking generated code falls apart the moment it touches a real build.

When a model generates a snippet, it has no access to your requirements.txt or go.mod. It pattern-matches against the aggregate of every repo and doc page it trained on, and if a method signature changed two major versions ago, the newer form usually dominates the training data. The model reaches for that newer form confidently, even if your project is three majors behind and the method does not exist yet.

The failure mode has two signatures worth learning to spot. One is loud: a model importing a module and chaining calls without ever asking what version you run, or adding a dependency to a diff that was never in your manifest. The other is quiet and more dangerous: code that compiles and passes today's tests but leans on a newer pattern, then breaks weeks later when someone upgrades or rolls back a package.

The fix costs almost nothing. State your exact versions before asking for code touching any dependency; a single line like "Django 3.2, Python 3.9" collapses most of the guesswork. Point the model at a file where the dependency is already used so it mirrors existing patterns instead of inventing new ones. Ask it what could break given your stack before it writes anything, request small diffs instead of whole features, and paste real tracebacks back into the conversation instead of describing them.

None of this is process overhead. A sentence of context up front replaces an afternoon of debugging a phantom dependency that only fails in your build, not the sandbox.

Bottom Line: The model is not wrong about the library. It is right about a library you are not running.