Each piece of AI-written code can pass every test on its own and still break the system the moment it meets another piece, because the assumptions behind it were never written down anywhere a reviewer or a second model could see.
The Details:
Picture a retry wrapper paired with a cache. A backend call fails for two seconds, the wrapper retries three times, but the cache has already stored the first failed response under that key. Every call afterward returns the cached error for the full lifetime of the entry, turning a brief hiccup into a prolonged outage. Add a rate limiter and the loop compounds: clients retry into the outage, the limiter reads that traffic as abuse and blocks it, and the blocks generate the very errors that keep the retries coming.
The root issue is not a coding mistake; it is fragmented context. When a model writes the wrapper in one chat and the cache in another, it reasons correctly about each file but has no view of how the other behaves under failure. Those unstated expectations about timing and state never appear in the code, so nothing in a normal review catches them.
The fix is giving the model the seam, not just the parts. Asking in one conversation what should happen when the wrapped call throws surfaces a question that isolated prompts never raise: what exactly gets stored when things go wrong.
The lasting artifact is a short paragraph per boundary describing what each component assumes about the other and what breaks if that assumption fails. It costs little to write, reads like plain prose, and gives every later conversation and every later reviewer something concrete to check against instead of rediscovering the same failure in production.
Bottom Line: A passing test proves a component works alone; only a written account of its boundaries proves the system will survive contact with its neighbors.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
