The Bug Isn't in the Code You Changed

AI-generated code can pass every test and still break production, because the failure lives three layers away from the file that was edited.

AI tools work from a partial map: the files shared, the tests present, maybe a stale README. They cannot see the downstream job that parses responses with a regex, the cache keyed on an old data shape, or the mobile client that cannot be force-updated. A model can be fully correct about the slice it sees and still wrong about the system as a whole, because the most important behavior in a mature codebase often lives outside any single file.

The riskiest legacy code is not the ugly code, it is the clean-looking code that seems arbitrary. A strange early return that filters out a two-letter account prefix might look like dead weight, but deleting it could send a nightly job hunting for a database that was decommissioned years ago. These bugs rarely show up in unit tests, since those tests check the behavior someone thought to specify. They show up in staging, in production, in timing-dependent processes where caches need to warm and retries need room to breathe.

Closing this gap is a knowledge problem, not a modeling problem. A short note describing what a module does, who depends on it, and what has broken before changes the quality of AI output more than a long architecture document would. Before editing a function, tracing every caller and grepping for every schema reference surfaces hidden consumers before they surface in an incident. Treat the first AI pass as a probe: review exposes what the model assumed about the system and what the developer assumed about the request, and the gap closes across iterations, not in one shot.

Bottom Line: Smarter models will not shrink the integration gap; only developers who write down the reasons behind their systems can.