Re: [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance

[Junio C Hamano <gitster@pobox.com>]

Scott Chacon <scott@gitbutler.net> writes:

> As an example, an OpenAI model was used to help me research, compare and
> craft the appropriate legal language for this policy change to help us
> match the modern, legally reviewed approaches now taken by peer GPL
> projects such as the Linux kernel [1].
>
> [1] https://docs.kernel.org/process/coding-assistants.html

That makes it sound as if this is just as legally sound as what the
kernel project uses.  However, the only assurance we get (unless you
are willing to act as our lawyer, and I do not know if you are one)
is that an OpenAI model produced plausible-sounding utterances.

Indeed, the proposed text seems to instruct developers and reviewers
to do quite different things from the rules I see in the above URL.
Note that in the following, I will be playing devil's advocate for
much of the time, so please accept my apologies in advance if I
sound too skeptical.

> +AI tools may be used to help prepare contributions, including code,
> +tests, documentation, and commit messages. AI assistance does not by
> +itself disqualify a contribution. The same requirements for correctness,
> +maintainability, licensing, and review apply regardless of the tools
> +used.
> +
> +You are responsible for the entire contribution. Before submitting it,
> +review and understand the changes, check factual claims, and perform
> +the testing appropriate to the change. Be prepared to explain your
> +decisions and respond to review comments. Do not pass unreviewed tool
> +output on to reviewers, including in commit messages or mailing list
> +replies. Keep explanations concise and relevant to the change.

It looks, at least to me, that there is not much that can be
meaningfully enforced by reviewers and followed by contributors in
the above text.  It seems to be little more than "the world would be
a wonderful place if everybody behaved this way."

A violation of "concise and relevant" seems to be the recent trend
of much AI-generated slop, so it may be a good suggestion to give
today.  But would we need to update it once the trend of text
generated by AI tools becomes "concise and relevant" nonsense that
merely sounds plausible?  What if an "AI-assisted" contributor lacks
common sense to tell between plausible-sounding nonsense and a
well-written description?  What if reviewers get too many such
"contributions" and cannot allocate enough review bandwidth to sift
good contributions from plausible-sounding nonsense?

> +The <<dco,Developer's Certificate of Origin>> applies unchanged. Only a
> +human can make that certification; an AI tool cannot sign off on your
> +behalf. Consider the origin and licensing of generated material,
> +including any third-party material it reproduces, and comply with
> +applicable license and attribution requirements. A tool's assurance
> +that its output is original or compatible with our license is not a
> +substitute for checking those requirements. If you cannot certify the
> +DCO for a contribution, do not submit it.

Again, this is a good aspiration to have, but I doubt that anyone
can practically certify that the output of an LLM is devoid of
content borrowed from problematic sources under the rule the text
above gives.  Would it not be more useful to help contributors by
defining what not to do more clearly?  Our current text says as much
more directly: you cannot practically certify, so do not send in
AI-generated slop, period.

> +Disclose substantial AI assistance in each affected commit with an
> +`Assisted-by:` trailer naming the tool and, when available, its model
> +or version. For example:
> +
> +....
> +	Assisted-by: ExampleTool version 1.2
> +....

I thought the kernel guidelines instructed us to say only "LLM"
these days, to avoid giving free advertising.  On the other hand,
they ask contributors to also list non-LLM tools, like coccinelle
and clang-tidy, that were used in their machine-assisted
contributions.  I am undecided on the merit of specifying the
exact model and version, but listing non-LLM tools alongside
materials for independent reproduction looks like a good idea.

> +Maintainers may request more explanation, testing, or information about
> +provenance, and may decline contributions they cannot confidently
> +assess.

The text of the kernel guidelines appears to give maintainers more
latitude (cf. https://docs.kernel.org/process/generated-content.html).
They can treat it just like any other contribution, reject it
outright, or choose any approach in between.  The proposed text above
does not account for cases where reviewers simply lack the bandwidth
to even think about what explanation and proof to request, and it
makes it sound as if declining a submission in such a case an unfair
rejection.