Policy on use of LLM tools and bug fixes

[Joseph Myers]

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
josmyers@redhat.com