AI Generated Code

[ryneeverett]

Should @GothenburgBitFactory have a project-wide policy on AI generated code? We're only going to see more of this in the future and it might be advantageous to think about it in the abstract when we're not facing an immediate concrete decision. In particular, it seems we need to balance:

• respecting reviewer's time
• preserving code quality
• preserving open-source license integrity
• welcoming contributors with non-traditional programming backgrounds
• encouraging disclosure/attribution of generated code

[djmitche]

I agree! Do you know of examples of policies from other projects?

[tbabej]

My 2 cents are that I think the risk of us getting in trouble due to AI generated code is relatively low, while the likelihood of us driving potentially useful contributions if we enact a strict AI policy is a much more likely scenario. Even in the unlikely case of us accepting proprietary code changes, it would not be that hard to simply remove them from codebase.

I am more concerned about people contributing low-quality, but good-looking PRs that only look good at a cursory glance because they have been mostly AI-generated without the (human) author/supervisor actually understanding the codebase. How to prevent that scenario, is unclear to me at this time.

[lauft]

To me the problem with AI generated code seems to be that it simplifies to create large PRs which then require time and effort to review. Especially if someone "just vibed it".

I agree on addressing the issue, e.g. in the CONTRIBUTING documents, maybe referencing a central statement of the GBF. I would not copy the postmarket policy, though...

[ryneeverett]

I came across the LLVM Policy today and it seems like a much better model, although way too long for our purposes. I would think the core components could be reduced to a sentence or two:

• policy: You the human are fully responsible for the quality of your contributions.
• banning extractive contributions: "Our golden rule is that a contribution should be worth more to the project than the time it takes to review it." -- LLVM policy
• handling (potential) violations: A text that maintainers can copy into a comment in order to minimize the effort of responding, but nice and tentative enough to not offend if the contributor actually did put in the effort and the maintainer's intuition was wrong.

[djmitche]

I like that!

[jbondhus]

Has there been any further thought on this policy? I like the LLVM policy too.

[ryneeverett]

My thoughts on this have evolved a bit over the last year or so now that I have more experience with generated contributions.

• I no longer think disclosure/attribution is important for most projects. AI slop can be smelled a million miles away and well-curated patches aren't substantively different whether they are generated or hand-crafted. Occasionally contributions will fall in the middle of the continuum but if a contributor can be trusted to adhere to an attribution policy they should be able to be trusted just as well with an extractive contribution policy. The relevant thing to disclose would be if there are parts of the patch you don't understand. Perhaps this kind of disclosure should be mandated in an AI policy, but this was a norm before the rise of LLM's. It has always been possible to throw code against the wall until it inexplicably sticks and that's always been something one ought to disclose.
• As we all become more experienced with the impact of generated code on open source, it is less clear to me that an AI policy is necessary for most projects. Perhaps it just takes some time and experience as individuals to adapt socially to this technology and acquire the skills and strategies to deal with edge cases.

[djmitche]

I'm tending to agree. At the moment, we are not inundated with AI submissions. There have been a few, but most are targeted and easy to review. I'm confident these were AI based on the thoroughness of the patch and detail in the PR description -- both beyond what a first-time contributor to this fairly dense codebase would typically produce. There have also been a few PRs that were obvious slop, and I've given the brief reviews then closed them when there was no response. We've also had a number of issues clearly written with the help of AI, almost all of which have just been good, thorough (sometimes extremely) bug reports.

Based on what I've seen in other projects, I believe discussing and somehow "ratifying" an AI policy would be a lot of work and also create a lot of negativity. There's no policy everyone will be happy with, and the discussion will draw in people who will not otherwise participate in the project. I, personally, don't have time to handle that and, unless such a process went impossibly well, would probably end up quitting this project.

All of which to say, I think things are manageable at the moment and would like to prioritize keeping it that way.

[ryneeverett]

That's a good point I'd missed -- the cost of adopting an AI policy is unjustifiable. Especially if both sides are going to converge and find a middle ground in a few years anyway.

[djmitche]

Fingers crossed :)

[jbondhus]

So basically, there's no hard policy around it yet, the quality of the code and effort to review is more what matters. Is that understanding correct? And yeah, I think if you assert quality, accountability, and impact of the chnages relative to review cost, the rest falls into place.

[djmitche]

So basically, there's no hard policy around it yet, the quality of the code and effort to review is more what matters.

This is a good summary.

And my personal approach as maintainer is pretty close to the summary of LLVM's policy that @ryneeverett posted earlier.