[TomasBM]

Interesting initiative. What are the guiding reasons behind these lists?

I can't think of a functional reason for a no-AI policy: if it runs, it runs, regardless of who or what made it.

Also, even if you avoid AI-generated slop, you can't really avoid the human-generated or human+AI-generated slop that passes your filters.

Still, I can definitely think of good non-functional reasons: provenance, accountability, proof-of-work, encouraging people to write code themselves, empirically tracking how humans develop codebases, etc.

[Forgeties79]

> Still, I can definitely think of good non-functional reasons

For many people that’s enough of a reason.

As for functional, you can see it all up and down this comment thread. People don’t check their work and leave these massive walls of text and codebases that someone else has to audit/cleanup. It’s exhausting. Too many people offload their work to AI and put zero effort into vetting the results, which punctually means they are just offloading the work downstream. So many maintainers are simply going “no I will not do your work for you,” which is a very functional decision.

To butcher a comment I read on HN that put it very succinctly months ago: everybody wants to let AI do their work for them, but nobody wants to be downstream of AI work. It’s a seriously problematic dynamic on many levels. And that dynamic will not change until the vast majority of people start reliably vetting the results, which I don’t think is going to happen because babysitting a black box and trying to force it to output something a specific way (or constantly copy editing middling work) is not something that most of us enjoy.

[TomasBM]

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).

[Forgeties79]

>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).

Agreed, but my main point is most people continue to do exactly this and simply won’t stop. They think “AI took care of it and it’s good enough” then essentially shove their work on to the recipient 30% completed. So long as that’s the way most people use LLM’s we will continue to see restrictions put in place by the recipients.

[vazark]

Because the goal is two-part

1. Accept quality contributions from someone who understands what they're doing

2. Cultivate a relationship with the contributor who might potentially become a core-team member. Maybe even the next maintainer

[voidUpdate]

I think the main functional reason is that because a human hasn't written the code, its potentially more likely to have subtle hidden bugs that a human cant explain because they didn't write it, as well as large pull requests that have to be validated by a human when smaller human written ones would be better. But I think it's generally the non-functional reasons that projects are rejecting LLM-generated code. Some developers just find LLM generated code icky, and would prefer not to be associated with it

[mschuster91]

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...

[voidUpdate]

Given the amount of web scraping LLM providers have been doing, I'd say it's likely that any code that is publicly accessible on the internet has been incorporated into it's training data, whatever its license

[cyclotron3k]

I'm not disagreeing with you, but it's worth noting there were plenty of GPL violations before LLMs existed.

[mschuster91]

Sure, but at least when I write code by hand I can be fairly certain that I do not copy code without the appropriate license to do so.

[cyclotron3k]

From godot's pov though, banning AI won't guarantee some arbitrary contributor's PR doesn't include GPL code.

[drdaeman]

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.)

[0xMalotru]

There is a "why" a the end of the list

https://codeberg.org/brib/slopfree-software-index#why-care-a...

[kjeksfjes]

> 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".

[deniska]

We should keep some people around who can read paper maps (and keep paper maps around too). We need to keep doctors around who can keep working without a computer. It's a civilization threatening issue not to. There might be plenty reasons, from natural disasters, to self-inflicted "geopolitics", when we suddenly have to take a technological step back, and it's in our interest to maintain "30-50 years ago" level of tech possible, so that we don't have to start all over from something resembling a bronze age.

[TomasBM]

Definite agree on having human-based redundant systems.

But I think the point the parent commenter made is: if there's not a functional difference in the result (i.e., job satisfies the definition of done), it doesn't matter if the AI generated the code or did the diagnosis.

But I think it's also fair to say that the process matters, even if the result is the same. If something exists for our benefit (e.g., there's no real alternative to learning-by-doing, and people need to know stuff for safety/security reasons), and we're fine with the trade-off, there's no reason to just give up the process to the AI.

[ThrowawayR2]

The people under GNSS jamming in war zones might disagree with you about the value of being able to read a map.

(And I'm unfortunately no longer as certain that "Well, that sort of thing can't happen where _I_ live." as I would have been a decade ago.)

[nasso_dev]

or, maybe, as a form of protest? many people are actively against AI for ethical/moral/personal reasons, so they want to avoid using software made with it

you can see it sort of like making a list of vegan restaurants. you might not see anything wrong with other restaurants (they might even have vegan dishes) but to some people it makes all the difference because they get to choose who they support

[croon]

The reasons are functional in aggregate, but not necessarily per specific PR.

You could get a perfectly adequate instance of a PR that is easily readable and verifiable while generated by an LLM, but generally they're not.

A policy pushes the aggregate to at least what looks and communicates as a human made PR that is functionally easier to approve. Whether they are created by an LLM or not is then secondary, but it likely pushes all PRs to be better.

[TomasBM]

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".

[croon]

I agree, both in theory and that it's easier said than done, but I don't necessarily think that education is a primary reason, but merely a long term prerequisite of the project surviving.

I'm sure some are convinced LLMs can (eventually) manage everything, and others (I'm leaning more here) are convinced that you will always need a minimum amount of people both educated in the fundamentals and the domain to steer the project, and these people wont exist down the path of non-human PRs.

[bigstrat2003]

> I can't think of a functional reason for a no-AI policy: if it runs, it runs, regardless of who or what made it.

AI-written code is far less likely to run than human-written code. Even worse, it often gives the appearance that it will be fine, only blowing up down the line. That is an extremely strong functional reason to reject AI code.

[TomasBM]

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.

[vips7L]

> I can't think of a functional reason for a no-AI policy

Imagine morals.

[degamad]

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

[seanclayton]

> I can't

That makes much more sense now. The inability is completely on you, and you admit it at least.

[alberto467]

You can’t understand the difference between functional and non-functional.

[seanclayton]

> I can't think of a functional reason for a no-AI policy

There are functional reasons for a no-AI policy. It helps the Godot Foundation function to establish a no-AI policy. Do you argue it doesn't help them function?

Do you understand the difference between functional and non-functional?

[CuriouslyC]

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

[pjmlp]

Same reasoning that folks apply against AI written blog posts.

[surgical_fire]

> Interesting initiative. What are the guiding reasons behind these lists?

> I can't think of a functional reason for a no-AI policy

These lists don't have you as an audience.

[dirkc]

Please define "if it runs, it runs"?

[TomasBM]

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.

[qsera]

But it is hard to verify it, right?

If you use rsync clone by an LLM to copy a million files, will you bother to verify every single one was copied correctly?

[TomasBM]

Well, unless you needed those million copies for whatever reason, that is an example of spam or denial-of-service, regardless of how it's generated.

And I'm not disagreeing - it is hard to anticipate what needs verifying, regardless if it's functional or non-functional.

But if it's not a spam submission, you could probably design tests or static/dynamic analysis tools that can verify those million copies much faster than manual reviews.

[skydhash]

There’s a reason most project don’t have a lot of unit tests. Because a specification, even when fully documented, doesn’t stay static enough to have time to write tests. And if it’s fluid enough, maintaining those tests will hamper velocity.

So you have integration tests that verify the general specs of the software and rely on your skills to verify the finer details. But if you’re using an LLM (and not reviewing every line), you can no longer be confident about those details.

And reviewing every line kills the speed advantage of using LLM.

[adamddev1]

"If it runs, it runs," is an very naive and irresponsible view of code.

[bwfan123]

> if it runs, it runs, regardless of who or what made it.

If it fails to run who is responsible to fix ? Problem with AI is that it does not have causal-models of how something works, and the reason for that is that it doesnt interact with the world. I think of it as an armchair expert who spouts recommendations without having a grounded understanding in the real world.

[timacles]

So you didn’t read the article?