Every function an AI writes can pass its tests and still be a landmine, because the danger was never inside any single file. It was in the unspoken choices each function made about what the next function could assume.
The Details:
When a model writes code without a full specification, it fills gaps with reasonable guesses: what to do with a null, an empty list, a malformed row. Nobody wrote that choice down. The next layer gets built on top of it, inheriting an assumption it never knew existed, and a third layer stacks another guess on top of that.
Better prompts only push the problem earlier. Spelling out more edge cases shrinks the space of unspecified decisions, but that space is never zero, and the model will still improvise on whatever you missed. A tighter prompt is progress, not a cure.
Code review cannot catch this because reviewers check whether code does what it claims, not whether it was ever asked to do that. A function that gracefully handles null looks like good defensive coding. Nobody sees that upstream code never promised a null would arrive, so that tolerance quietly becomes load-bearing for everything downstream.
The fix is making assumptions impossible to skip. A comment asking callers to validate input is a suggestion; a type that refuses to compile on unvalidated input is a wall. Building types like ValidatedEmail instead of raw strings, writing a boundary test that pins down the empty-input case, and having one deliberate conversation about what a seam promises before building on either side of it all move the assumption out of someone's head and into something durable.
Bottom Line: As models get more capable and handle bigger chunks of work, the hidden surface for silent assumptions grows with them; explicit contracts are the only thing that keeps that surface from swallowing your system whole.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
