I respectfully disagree. If they are separated into thoughtful modules, then it would be much easier to parse by simply looking at the file and folder names and going from there. This will especially be true when this expands past it's current state, and it becomes impossible (Or more impossible) to see what uses what.

IMO, 20,000 is already way to much, but when that reaches 100,000 even just editing it will be a chore, let alone using it. It will simply be unmaintainable and unusable. I say this having worked on code bases which have reached that point and attempted to deal with the issues it creates. There's a reason every decently sized code base out there uses multiple files and a hierarchy. It's a natural way to create modular code, and modular code is simply better code.

Perhaps if you are the author of the 20,000 line header file, but from my experience, this is certainly not the case when developing software in a team. Having all the code in one file is significantly more difficult to understand for a new team member since it becomes more cumbersome trying to understand the dependencies between different modules.

On the same note, proper modularization of source files also encourages better discipline for dependencies among modules, such as discouraging circular dependencies.