We never really have a complete mental map.

"Oh, this library just released a new major version? What a pity, I used to know v n deeply, but v n+1 has this nifty feature that I like"

It happened all the time even as a solo dev. In teams, it's the rule, not the exception.

Vibing is just a different obfuscation here.

There's a difference between not knowing the internals of a dependency you chose deliberately and not understanding the logic of your own product.

When you upgrade a library, you made that decision — you know why, you know what it does for you, and you can evaluate the trade-offs before proceeding (unless you're a react developer).

That's not a fog of war, that's delegation.

When an LLM generates your core logic and you can't explain why it works, that's a fundamentally different situation. You're not delegating — you're outsourcing the understanding, and that makes the result not yours.

No. I see this mistake everywhere. You're confusing "knowing everything" or "making assumptions" with "mental maps". They are not at all the same thing.

The benefit of libraries is it's an abstraction and compartmentalization layer. You don't have to use REST calls to talk to AWS, you can use boto and move s3 files around in your code without cluttering it up.

Yeah, sometimes the abstraction breaks or fails, but generally that's rare unless the library really sucks, or you get a leftpad situation.

Having a mental map of your code doesn't mean you know everything, it means you understand how your code works, what it is responsible for, and how it interacts with or delegates to other things.

Part of being a good software engineer is managing complexity like that.