Before LLMs, provided that your team did some of their due diligence, you could always expect to have some help when tackling new code-bases. Either a mentor, or at least some (even if maybe partially outdated) documentation. With LLMs, this is gone. The only thing you can rely on is on your ability to decipher what a highly imperfect system generated, and maybe ask explanations to that same imperfect system about your code its code (oh, and it has forgotten everything about the initial writing process by then).

— https://www.mindflash.org/coding/ai/ai-and-the-bus-factor-of-0-1608

This article is fair and relevant commentary on the practicing of thoughtlessly producing code to solve a problem without ever reading it. However, I disagree with this passage’s assertion that “you could always expect to have some help when tackling new code-bases”. At this point in my career, the majority of the codebases I’ve worked in have required that I learn parts of the system from zero, effectively as if there was no one with any knowledge of the system (aka bus factor of 0).

Practically speaking, even if there actually are some people with knowledge of the system, it may be impractical to rely on them to get you up to speed on a codebase where you need to make some change. I’ve found the most success through figuring things out with the aim to unblock myself.

This approach may only go so far. You may be able to create and merge a PR but not deploy. Or deploy but not know how to run migrations. But the more experience I’ve had working as a software engineer, the more relevant and useful doing the archeological work of digging through the history of a codebase has been.