It seems to me this is the same problem we previously had: how do we understand codebases we didn't write?

Creating while writing allowed us to build a mental context but in a unproductive way, it never scalled.

I believe we need to move onto a new way of reading codebases that go beyond reading line by line.

I know people have explored representing code in 3D spaces. I don't know the solution. But I believe that is the problem.

Ask your AI to chart the data flow through the program. Not that that's a magic solution but it's a pretty good start.

By default, if you ask an AI to "generate documentation for this code" it generates the same broken documentation all the humans do too; an enumeration of all the modules in the code and what their API is. I'm not surprised, the training data is biased probably at least 25:1 in favor of this rather than the useful data flow documentation. Fred Brooks was complaining about this over 50 years ago and the discipline as a whole still gets this wrong.

I'm not saying this is a future solution to all problems, but it is a now solution to some problems.

3D doesn't help. We live in a 3D world but our vision is 2D with a bit of augmentation from a second view point just a bit away. We derive some depth information from that, but we don't really "see in 3D". To do that we'd need to be 4D beings. There's a lot less juice in the 3D squeeze than meets the eye.