Improving code understanding is the main focus of my work and thinking right now. If we want to make advances I believe that we should rely more heavily on one key quality of the program code: It is meant to be executed.
Here are some ideas:
1. Time travel debugging. Reading a PR just like a wall of text is difficult, but what if you could step through the PR and see the state at a given line for some test executions? Time travel debugging can make this possible. You would collect a debug trace and use it to overlay the PR diff with additional controls and information to resemble a debugger's UI. I was part of the team behind Codetracer (https://github.com/metacraft-labs/codetracer) who is trying to work in this direction.
2. Test suites and coverage. We don't use them enough for understanding right now. The test suite encodes what features the code is supposed to have, and the coverage tells us where in the code those features are implemented. I'm playing with an idea about this here: http://atlas.vihren.dev When we intersect coverages for the different test cases we can arrive at code segments which represent "atomic behaviors" present in the code. They form a mathematical structure which can be represented as a graph. I am currently exploring what value we can extract from it for the benefit of both humans and agents.
This seems backwards. We've known for a long time that successful execution is not enough for understanding.