On Fri, 17 Apr 2026, NightStrike via Gcc wrote: > There is one tertiary risk that isn’t often discussed in any project. Do > you remember when having a GPS in your car first became popular? Everyone > would buy a Garmin and have it suction cupped to the windshield and use it > for going everywhere. At least in my circle of friends, we quickly realized > there was a rapid and astounding psychological impact whereby we simply > “forgot” how to navigate from A to B. Our brains adapted to the tool and > discarded the skills required to remember how to move around. > > Unleashing a heavy reliance on automated tools has the nonzero probability > of significantly reducing the already scarce knowledge and experience of > large scale codebases.
What I said in the glibc AI policy discussion was: I'd say the submitter needs to *understand* the code they are submitting, and to *communicate that understanding* with a high-quality commit message (and be ready to engage in the review discussion and revise the changes or commit message as needed). Some five-line changes have straightforward local explanations and don't need particularly in-depth understanding (provided they are accompanied by a test that fails before and passes after the change, if it's supposed to be doing something user-visible). Others deserve much more involved explanations (including why the fix belongs in a particular place in the code and not in a different place, for example). (It's true that doesn't fully address the risk you describe, because of understanding gained from trying wrong paths that might not feature in the final explanation of the route actually taken in the patch, and might never be gained when an automated tool deals with discarding the wrong paths.) -- Joseph S. Myers [email protected]
