The main issue with these set of tools is that I mostly read and understand code more than writing it myself.
Not enough attention is been given to this imbalance.
It is impressive having an AI that can write code for you, but an AI that helps me understand which code we (as a team) should write would be much more useful.
My immediate instinct was to agree with you whole-heartedly. Then I remembered that Copilot has an "Explain this" button that I never click.
Maybe this is because I'm just not used to it, maybe the workflow isn't good enough, or maybe it's because I don't trust the model enough to summarize things correctly.
I do agree that this is an area that could use improvement and I see a lot of utility there.
My issue is not explaining how the code work. My issue is understanding why the code exists at all.
The default workflow is to follow the commit history until I don't get to where and when the code in it's current shape was introduced. Then trying reading the commit message that generally link to a ticket and then acquire from tribal knowledge of the team why it was done like that. If it is still necessary, what can we do today instead, etc...
And similarly when designing new code that needs to integrate on existing piece of code... Why there are such constraints in place? Why was it done like that? Who in the team know best?
AI could help with this. It could pull the version history for a chunk of code you have highlighted, pull up the related tickets, sift through them, and then try to summarize from commit messages and comments on the ticket why this was added.
What I could have used the other day was "find the commit where this variable became unused". I wanted to know if the line that used it was intentionally deleted or if it got lost in a refactor. I eventually found it but I had to click through dozens of commits to find the right one.
I get the frustration with this workflow too. This is where having all of your issues in Git would be great, but alas no one wants to collaborate in ticket comments via Git commits...
Inevitably the issue tracker gets moved/replaced/deprecated, and so all of that context disappear into the void. The code however is eternal.
This is great feature, but targeted mostly at junior developers who don't yet understand how particular library or framework work. But when I read the code, I spend most of my effort trying to understand what did original developer meant by this, and LLMs are not yet very helpful in that regard.
I partially agree with you: not knowing what particular functions etc. do is one use case, another for me would be to detangle complicated control flow.
Even if I can reason about each line individually, sometimes code is just complicated and maintains invariants that are never specified anywhere. Some of that can come down to "what were the constraints at the time and what did we agree on", but sometimes it's just complicated even if it doesn't have to be. The latter is something I would love for a LLM to simplify, but I just don't trust it to do that consistently correct.
There are a lot of tools that promise to help you understand existing code. However, it's a really hard problem and to me none of them is production ready.
Personally, I think the problem is that if the AI got it wrong, it would waste you a lot of time trying to figure out whether it's wrong or not. It's similar to outdated comments.
No one should be submitting code that's difficult to understand, regardless of how it was 'written'. This problem exists just the same as a developer who's going to copy large blocks of StackOverflow without much thought.
It isn't always the piece of code that is hard to read. It's about how it fits into the 200,000+ line application you're working with, what it was trying to solve, whether it solved the right problem, and whether there will be unexpected interactions.
Not enough attention is been given to this imbalance.
It is impressive having an AI that can write code for you, but an AI that helps me understand which code we (as a team) should write would be much more useful.