Why it matters: AI-generated code often passes every test yet fails in production because it quietly depends on a belief nobody ever wrote down, and standard code review has no way to catch that.
The Details:
A model builds its solution from whatever context it sees: surrounding code, sample data, test fixtures. If every example it read had a populated user ID, it treats that as a rule and writes logic that leans on it, without a guard clause, comment, or type constraint anywhere in sight. The assumption did real structural work but left no trace.
Tests usually can't expose this, because the fixtures often come from the same narrow slice of data that shaped the assumption in the first place. Everything passes cleanly until a real caller shows up: a migration script, a batch job, an empty response from an upstream service on a slow Sunday. That is the moment the hidden precondition finally gets tested, in production.
Adding more defensive code or more tests doesn't fix this, because both require already knowing which case to guard against. The actual fix is disclosure: ask the model directly what has to be true for its function to work before you accept it. Roughly half of these hidden preconditions surface the moment that question gets asked, because the model has to reconstruct them out loud instead of leaving them buried in logic.
This costs one line, not a new process: add a prompt step asking the model to list its assumptions about inputs before writing the code, then read that list during review. Save the deeper interrogation for functions touching real data boundaries, external queues, database writes, upstream responses, since that's where an unstated belief actually turns into an outage.
Bottom Line: The danger was never bad logic; it was a true-sounding belief that nobody was ever asked to say out loud.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
