Re: GCC LLM policy adopted

Ansgar =F0=9F=99=80 <[email protected]> writes:
> On Thu, 2026-07-30 at 10:45 -0700, Russ Allbery wrote:

>> That doesn't mean I think LLM-based analysis tools are devoid of
>> problems, but incorporating substantial portions (substantial in terms
>> of semantics, not in terms of lines of mechanical changes) of
>> LLM-generated code adds additional risks and concerns that use of LLMs
>> for code analysis does not.

> I don't think there is much difference:

> A thorough review with potentially concrete, actionable suggestions can
> easily have as much influence on the final changes as the initial change
> revision. The final change that gets merged is as much derived from the
> initial patch as from the review comments. Or in some cases the review
> is even the majority of the contribution.

You seem to be assuming that my concerns are about incorporating
substantial LLM output are about copyright law. They are not, primarily.
For good or for ill, my working assumption is that copyright law will be
rewritten to say whatever the corporations with the most money want it to
say, either implicitly through the courts or explicitly through the sort
of open corruption practiced by the US government. It seems quite unlikely
at this point in time that this process will converge on an anti-LLM
interpretation. Maybe the EU will succeed in being a bastion against this
trend, but I'm dubious.

The additional risks that I see come more from incorporating code that the
person responsible for the code doesn't understand. This has obvious
short-term risks (LLMs can be better with localized security flaws than
humans because they're good at being relentlessly pedantic, but they can
miss structural flaws outside their context window that would be obvious
to an experienced human), and more subtle long-term risks if the code base
as a whole turns into something only LLMs are modifying and that no person
understands in full and imposes some structure over.

In a Debian context, this is less relevant to most packaging situations,
where the total complexity of the packaging is usually not very high, and
more relevant to our own infrastructure and to patches against upstream.
Human *comprehension* seems important here, to me. In that context, a
detailed explanation from an LLM is at least somewhat better than blindly
cutting and pasting the LLM code. Even if someone is following LLM
instructions, the process of turning those instructions into keystrokes
provides some opportunity to go "wait, this is weird."

It's been very illuminating in this area to follow how the Linux kernel
has been approaching this problem. They're making heavy use of LLMs for
code analysis, and some use of LLMs for mechanical code changes or other
sorts of tedious modifications that are relatively easy to review but
annoying to generate, but substantial blocks of new LLM code get
heightened review and attention from expert humans with full context and
are treated with more skepticism.

Debian is more vulnerable in this area because we do not have the
resources to do anything close to the level of code review that is
standard in Linux kernel development, so I think it's reasonable to be
somewhat more concerned in the Debian context that a practice of
incorrporating large blocks of LLM-generated patches into packages could
further exacerbate a problem Debian already has: Insufficient human
understanding of the changes in and interactions between distribution
packages to make good strategic decisions.

I'm guessing you're going to rightfully point out that we already do a bad
job at this, and I agree, but I still think that unsupervised agentic
development (to take the most extreme example) would make that problem
noticeably worse.

--=20
Russ Allbery ([email protected])              <https://www.eyrie.org/~eagle/>