You're right that there isn't a good alternative. I'll just describe that I try to do even if it is inadequate. I write the code as obviously as possible without taking more time (as a courtesy to myself), and I then document the scope of what I am writing when I write the code (what I intend for it to do and intend for it to not do). The documentation is a CYA measure. That way, if something does get elevated, well, I've described its limitations upfront.

And to be frank, in scientific circles, having documentation at all is a good smell test. I've seen so many projects that contain absolutely no documentation, so it is really easy to forget about the capabilities and limitations of a piece of software. It's all just taught through experience and conversations with other people. I'd rather have something in writing so that nobody, especially managers, misinterprets what a piece of software was designed to do or be good at. Even a short README saying this person wrote this piece of software to do this one task and only this one task is excellent.