And on top of that - no matter if you develop open-source or proprietary software, who is to guarantee the AI didn't get trained with GPL (or even worse, leaked proprietary) source code? Who is going to pay my lawyer when someone files a copyright lawsuit and all I have as an excuse is that I "AI-laundered" my code?

And some projects like WINE or ReactOS probably have to worry about that even more given they need to guarantee clean-room reverse engineering...

This makes sense, but I'm not sure it's directed at the actual issue.

There are probably some subtle bugs I can't explain in the code I wrote all by myself. I sure had a few "what was I possibly thinking when I wrote this" moments working on some old code - and that's only the bits I know about. And I sure had countless times people pointing out "hey, you got this stinky here" in a code review (which is the whole point of it). Attention lapses and brain farts sure happen. Slop can be more frequent with LLMs but it's certainly not a LLM-specific issue. They're very productive, there's a literal outbreak, and by the sheer volume shadow any The Daily WTF stories.

However, I can agree that LLM-generated code most likely has higher probability of slop. But then, a policy "a human contributor MUST fully know and understand all the contents of the submitted work, in fine detail, all the way down to every single line of contributed code and documentation" would probably address that in a more functional manner. And then the code can be from an LLM or monkeys with typewriters author had seen in his sleep. That stops to matter because author takes ownership and responsibility: "here's a recognized rational agent who swears by their work". Makes non-self-authored code require a lot more effort (unless it's a trivial change for obvious reason), but arguably even more robust than self-authored code.

That is, unless the PR authors tend lie about their knowledge - but that'll be a whole different story, where LLMs will be just a background detail.

(I'm not saying Godot should be done something different - their project, their rules, let's use that as an opportunity to watch how it goes. Just musing on the matter in general, if there's any rationally explainable merit in such policy.)

> There is a study showing that doctors who use AI to help detect cancer become less skilled at detecting cancer without AI.

Not exactly an argument against using AI, is it? It's a bit like saying that GPS makes people worse at navigating by memory, which is true, but also not a strong argument for going back to paper maps. I feel the discourse is more about "stop using AI" and less about "how can we ensure our backup skills doesn't disappear".

Good point. Even if you submit small, verifiable and readable changes, you can still overload the review process by submitting too many of them (e.g., 100s of PRs).

But I'd argue that some projects [1] could benefit from the speed (and sometimes, quality) of AI code generation without filtering by something that's difficult to identify (i.e., is it truly human-generated).

One way could be to constrain the size of each commit and PR, and invest more heavily into the review process (e.g., tests, static/dynamic analysis, sandbox deployments), so even if you get 100s of contributions, you can knock each out quickly.

Obviously, easier said than done. And at that point, you may as well use the AI to make the commits yourself, instead of relying on community contributions.

[1] Of course, this is only the case if the project's only purpose is to be a tool, and not also an educational reason for humans to learn how to code - in which case, it makes sense to invest more into identifying the "cheaters".

I think that's completely fair.

There are also plenty of valid personal reasons for refusing to generate code with AI - learning-by-doing and ownership of the result being the main ones, IMO.

> everybody wants to let AI do their work for them, but nobody wants to be downstream of AI work.

This is also true in my experience. But in my work, I found that I don't care how the code or comment was generated, as long as it doesn't try to overload my brain with irrelevant and obfuscated things, and as long as the person is not pretending that it's true, verified or their own creation (when it isn't).

That would be part of the non-functional reasons mentioned in the next paragraph.

Maybe then it should be a no Oligarchs policy, and include code written by capitalist shills as well to be internally consistent.

If you have some requirements/specifications, and the piece of code fits them, then it runs.

Alternatively, if you have some vague idea [1] about what you expect to see/have, and the running code satisfies that idea, then it also runs.

Obviously, there are plenty of non-functional specs (e.g., security, cleanness, readability) that a code should probably fulfill before one finds it acceptable, but these are also not somehow impossible for state-of-the-art models to satisfy.

[1] Vibe, if you prefer, tho I dislike the term. Another related term is eyeball estimation.

That depends on the model and the toolkit it uses. In my experience from using Claude Code (Max, Opus 4.5+) intensely for the past six months, I maybe had 3 instances where the implementation broke functionally. And all of these breaking changes were resolved by Claude.

Obviously, this won't apply to every context: I work primarily with well-known langs (e.g., Python, JS), small to medium codebases (<500k LoC, for sure), and relatively few co-developers.