I’d say “explaining how they got there” is math. Formal science in general is like, explain a problem so well that your worst enemy can’t help but agree with you. In programming, you have two such worst enemies: first the computer, and then the maintainer. Problem solving isn’t easy, but once you explain your problem well, you already have a big part of the solution. The definitions and the tests. Your solution can’t be reliable enough for others to build on top of it unless you have a good explanation - every part of the solution has to be useful on its own. In the statement that someone or something is better at solving problems but is bad at explaining the solutions, I see something deeply unscientific.

If somebody sends a working patch but the explanation is insufficient for the maintainers to understand it, it’s simply a bad patch, and the process of working with its programmer to build common knowledge about the problem and have the programmer refactor the patch until both they and every maintainer (including future generations of maintainers) understand enough of it, is how projects stay alive. I’m not convinced using LLMs as a lossy and noisy substitute for both the refactoring tools and the knowledge-building process is a good idea.