151–160 of 419 posts
Definitely sympathetic to their policy, but AI tooling and quality are changing quite fast. In a year I'd expect a modification of this as AI agents get better in virtually every possible way.
- Disable public pull requests.
- Require people to open an issue or discussion. Issues and discussions should have stated length/quality parameters. If an issue is a wall of Claude-text, users should be prepared for this text to be automatically summarized into plain language. If you don't want your Claude-text to be machine-turned into something human-consumable, the onus is on you to post human text up front.
- PRs are only drafted once approved in issue or discussion
I'm wondering if this is a tractable approach that yields results. I've seen references to a few projects trying something like this. Would be nice to hear folks experience.
Interesting that on one hand the valuation of these AI providers is based on the assumption that all code (and everything else producing digital artefacts) will be written using AI in the near future, on the other hand almost all popular open source projects fight to keep AI contributions out. Hard to reconcile. Personally I'm also experiencing a bit of AI hangover after using it a lot in my own open-source projects.…
the assumption that all code (and everything else producing digital artefacts) will be written using AI in the near future, This is what AI providers wanted you to believe in because they have a couple of shovels to sell to you. Once you realize that the assumption is delusional, it's no longer hard to reconcile.
No, we don't have to. We can just write code ourselves.
(My condolences to people who have jobs where AI is mandated.)
Earlier quoted context omitted.
> 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…
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…
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.
There are some curated lists of no-AI software. Would be nice to have an index / plot of how that changes in time. https://codeberg.org/brib/slopfree-software-index https://noai.starlightnet.work/list.html
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…
> I can't think of a functional reason for a no-AI policy
These lists don't have you as an audience.
While I agree with the general message, and wish it will eventually radiate to cooperations as well, it is obviously a decision driven by feelings, not logic. The idea that you can't trust code that was generated by heavy users of AI, because _they_ don't understand it enough to fix it, is false, because they can use AI to fix it. In general, I have hard time understanding how one might even block other contributors…
The problem with "they can just have the AI fix what's wrong" is explained a bit more in the contribution policy itself - https://godotengine.org/article/contribution-policy-2026/ - nice-to-have features often require design decisions which aren't obvious to outside contributors, but which can create a lot of work for maintainers, especially in game engines where backwards compatibility is a must.
A good example is their ongoing effort to restore C# support to web builds - https://github.com/godotengine/godot/pull/106125 - in Godot 3.x .NET integration was done through Mono, so web games could just bundle the Mono interpreter, but for 4.x which uses mainline .NET, the original plan of instead building WASM bundles (https://godotengine.org/article/platform-state-in-csharp-for...) was blocked by .NET WASM bundles not supporting dynamic linking, not by Godot itself.
The modal person asking "When is C# going to be supported for web games?" or prompting a fix likely won't know to ask "Does my fix need SharedArrayBuffer support?" and "Does my fix rely on patching the .NET runtime?", or why those questions matter, and will get frustrated when the fix that works on their machine then can't be merged into the main project.
Earlier quoted context omitted.
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…
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?
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.
Do those AI contributors really think they are helping out? Don't they get, that they are destroying such projects with their "work"? Why do they spend money for stuff nobody wants and gets rejected. I don't get it... Don't these people have any hobbies? Or are these free-roaming OpenClaw instances that have been forgotten by their creator and are now doing their own thing?
We are no longer in the era of FOSS where contributions are purely motivated by either scratching your own itch, altruism or curiosity. Haven't been for over a decade, since that's how long companies have been checking out applicants' GitHub pages during hiring. These people are farming contributions to major FOSS projects as a form of CV-padding. The same is happening with vulnerability reports. The sloppers may gen…
They can even list on their CV that they are the maintainers of those projects.
I've seen policies like this in various places and they do not generally seem to be based quantitative measures of code functionality, security, and efficiency.
There are other approaches to take to deal with large numbers of incoming PRs: improved CI, AI-readable standards for AI code, better static testing, AI first-pass review, etc.
It's fine to enshrine hobbyism into your code review policy to keep things fun and human-scale. On the other hand, where projects actually matter, it is necessary to think about code review as part of an industrial process with inputs and outputs, one where this sort of thing has no place.
Earlier quoted context omitted.
But now with AI, this should be "easier" for some definition of easy. In the sense that in the past, this might have taken 15 minutes to write, now with AI, this can take 5 minutes to write by first getting AI to produce a summary and then using human judgement to make it better. So, it's a good idea now to actually demand the dream.
If people knew how to get AI to write terse, focused summaries, sure, that might help. I haven't seen many that do (well, ignoring the toupee fallacy). Though the most important aspect is that we need to know the motivation and thought process, and all AI can do is fabricate a 'plausible' one.