I asked at an interview if they documented their code with class diagrams.
One of the interviewers told me: "Good code doesn't need a class diagram"

...

*TRIGGERED*

It's probably said to be said. Bullshit.

Reply:

I'll let you know when I see a good enough code that does not need diagrams.

@vlatkozelka "If I have access to the source code and it is well-written, I can understand it what the system does". Yeah you can. If given enough time you could even understand what the system does from the binary too.
But we like to understand fast right? That's what the whole documenting thing is about. To ACCELERATE the comprehension of the system be it for new people who just got in or for you after a few months of working on something else.
It doesn't have to reflect each class perfectly down to every variable and getter/setter. Just the bare essence of them and their relationships to the other most important classes the system uses. That will only change if there are big refactorings or changes in system architecture which, trust me, you WANT to document clearly.
From my personal experience auto-generated class diagrams usually suck.

I've been able to understand large code bases if they are written with modular and "pure" patterns. And I've decompiled .NET libs in the past and they were good, but I'd see why that kind of code needs a class diagram, because it's a pyramid of verbose namespaces which inter-operate on the same level of abstractons, I mean low level code interacts with a ton of other low level verbose classes. Some codebases only interoperate at the highest level like with top of pyramid modules, think Python, TypeScript in Node). In those who don't and have high coupling, even diagrams won't help you. Won't miss to say, yes, Haskell is immune to a lot of these issues.