My guess is that people who work on small codebases with low-turnover teams (say, Redis or games like The Witness) would say “obviously you have to understand it completely, otherwise you can’t do good work”. I’d also guess that people who work on large codebases with high-turnover teams (say, the Google web search backend or GitHub) would say “obviously you can’t understand it completely, you just have to do the best you can in your local area”.
These are two largely different ways of programming with different methods, practices and cultures. However, the first group is over-represented in online discussion about software engineering. I want to defend the second group against the first.
Two things: this is phrased as if each change by another developer ruins your theory of the codebase. This is an oversimplification. Changes to the core engine of the codebase can change the theory of the product but many changes are cross cutting concerns. This is why new developers on large codebases are commonly assigned integration work. You develop a theory with a real lower stakes output.
Second the llm thing. Putting aside hallucinations you could get a start of a theory from an llm but you’ve conditioned yourself to be reliant on the llm. To put things in similar terms of tech job stuff like this article does: prior to llms most teams had at least one SME on the whole codebase. They’d get bombarded with questions and if you had any politeness you wouldn’t bother them with every single question about the code or product as a whole. Occasionally you would need to but there was a natural social forcing function to figure stuff out on your own. Llms are the complete opposite: they tell you “good question” “good insight” etc. brains like short cuts so now there is no forcing function.