Once your shared mental model of how the codebase works is gone it seems practically impossible to get it back.

You won't want it back. How much time do you spend surfing through your .o or .obj files today?

Back in the day you'd read reference manuals which would tell you about the library, they might be hand written or a listing of the addresses and names. Today in the modern day, we still use reference manuals for writing C and C++. It's just encoded in websites, e.g. https://pubs.opengroup.org/onlinepubs/9699919799/functions/c... and https://en.cppreference.com/

But there are still libraries where familiarising yourself with the header is important, for example stb's libraries. man(1) and GNU Info were both invented to be computer-stored reference manuals, and indeed to this day you can type `man 3p open` to get the POSIX documentation of the system up in front of you.

I am not aware of many codebases that have manuals as complete as this, but back in the day (1970s-era to the 1990s-era) there would be internal documentation written as par of course for the specification created by the waterfall model of development. Post-2010 companies are very lackadaisical about documenting internal interfaces and libraries because they come from startup cultures where "move fast and break things" is the name of the game.

> How much time do you spend surfing through your .o or .obj files today?

Those are not the source of truth for the application logic. But the higher level code is.

The application code describes the behavior of the program and the compiler translates it into a different representation following a set of known, deterministic rules. This is unlike an LLM producing code from a prompt, which is why the source code is still the source of truth, and not a bunch of prompts.