Cool. So here's what I'm trying to understand...

Usually when I write code, I assume it's my job to ensure the code works as designed in all reasonable circumstances. That requires understanding the failure modes of any external code I'm calling, at least as far as if/how it could fail.

IIUC, your approach is more like what I'd call prototyping. I.e., you accept that the code might be wrong, but you prefer to deal with that if/when it comes up in testing, so that you can move faster up-front.

Is that how you reason about it?