Why it matters: Code that opens files, sockets, or database connections can pass every test and still fail silently in production weeks later, because the bug lives in the cleanup path nobody checks.
The Details:
- Models are trained on vast amounts of code where acquisition is explicit and cleanup is often implicit, tucked into a context manager out of view. Without the operational memory of a 2 AM outage, there is nothing pushing the model to pair every open with a guaranteed close on every exit path.
- A tidy function that opens a connection and returns a result reads better than one wrapped in defensive try-finally blocks. Generated code tends to optimize for what looks clean in a diff, and a reviewer skimming logic rarely stops to check whether an exception path releases what it grabbed.
- Standard tests cannot catch this class of bug. A unit test calls a function once or a few times, the OS reclaims leaked handles fast enough to stay invisible, and a demo environment never runs long enough to show the climb. The leak only surfaces after real traffic, disguised as a slow garbage collector or a database that cannot keep up.
- The fix is a different kind of test: run the operation thousands of times in a loop and watch whether file descriptors, memory, or open connections stay flat or keep climbing. Pair that with resource warnings that fail the build and fault injection that forces the exception path on purpose, since that is exactly where AI-generated code tends to leave things open.
Bottom Line: Treat resource lifetime as an architecture decision with a named owner and a release plan, not a detail the model will quietly handle for you.
