> Am 17.04.2026 um 18:59 schrieb Jose E. Marchesi <[email protected]>:
>
>
>>> On Fri, 17 Apr 2026 at 16:54, Andrew Pinski via Gcc <[email protected]> wrote:
>>>
>>> On Fri, Apr 17, 2026 at 5:22 AM Christopher Albert via Gcc
>>> <[email protected]> wrote:
>>>> I fully agree with you, Richard! Making AI assistance transparent and
>>>> have clear rules about it is key. I didn't publicly flag my use of AI
>>>> tools up to now because I was afraid that the contributions would get
>>>> rejected upfront due to unclear policy or strong opinions. Internally, I
>>>> was more open about it out of respect for the reviewers who invested a
>>>> lot of time and effort. From now on, I will add Assisted-by: to the
>>>> patches.
>>>
>>> They absolutely should have been rejected and now they should be
>>> rejected for not disclosing in the past usage of LLMs.
>>
>> Unfortunately, we've probably got other examples where the origin of
>> the code was not disclosed. It's why we need to have a clear policy
>> about it. It's hard to tell people they shouldn't have done something
>> when we never defined that as a rule.
>>
>>> See what OpenJDK does about this; https://openjdk.org/legal/ai.
>>
>> I think this is a good policy. It's very clear, and doesn't try to
>> restrict contributors from using AI (or any other tools) for their own
>> offline purposes. It only restricts the content which is committed to
>> the project, which is (IMHO) as it should be.
>
> FWIW I am of the same opinion.
>
> Once the rule is in place, though, IMHO disclosure should be taken very
> very seriously. A statistically generated patch simply shouldn't be
> reviewed and handled in the same way than intelligent patches.
>
> I also think it would be good to add some explicit statement to the
> policy (if it isn't there already) in the sense that the policy cannot
> be used in order to bypass maintainers/reviewers: compliance to the
> policy in no way means the LLM-generated code shall be accepted. It
> really must be obvious, but better safe than sorry..
I think it’s interesting to collect what people think they’d use LLMs for given
there’s wide enough corporate pressure to use LLMs more with the idea to
increase productivity and save money. With that in mind I for myself am still
in the early evaluation phase, but I can frame a few use cases I think I light
want to use LLMs (if they turn out capable of delivering):
- patch review pre-screening (does the message reflect what the patch does?)
- bug (pre-)analysis - while I’m good at that manually, creating N copies of
myself would be nice to reduce the time I spend daily on bug analysis/review
- feasibility checks - I have a large list of TODO items which my or may not
turn out useful (or even possible), if LLMs can do an early stage prototype
then it should be possible to evaluate those ideas (finally); in fact I have
picked one such item and am turning that into a benchmark for LLMs
I do not think LLMs will help me in actual coding. Maybe in monkey
refactorings, but there’s pre-LLM tools for that as well (never used them,
speaking to LLMs does sound more appealing than learning such tools)
Richard
