Other than the obvious, self-reflective question that the author doesn't pose - "what if I'm the one who's wrong?" - I think it's worth arguing if the conditions are right.
Because I also like being correct, a debate to me has become something of a game where (ideally) we both win in both end scenarios: either my thinking was correct, and now I verified/validated it, and got you to think differently; or my thinking was incorrect, and you corrected it for me (or helped me get there).
However, I implicitly figured out that there are some qualifiers to actually getting the benefits:
- Can I be, and remain, polite and reflective? If not, my personality or knee-jerk responses will always get in the way of an argument's benefits.
- Is the subject sensitive to the person for whatever reason? If yes, any argument inadvertently becomes a signal of a person's worth.
- Are we in a competitive setting (e.g., corporate meeting, or larger social group)? If yes, any argument inadvertently becomes a social status competition.
- Do I know how to stick to the issue (instead of moving goalposts), and stop when the debate gets overwhelming (too long, too much difference)? If not, I'll overstep the boundary after which it isn't mutually beneficial anymore.
These are not easy to figure out, and sure, maybe stop arguing with most people if the conditions aren't right.
But unless you stop communicating altogether, I don't see how you can stop arguing with people in general.
You would be steel-manning his essay if you assume he’s right in these arguments. Unless you believe that no position is more correct than another or that no one is more often correct than others, you can imagine scenarios where the author is often more correct than the people he is dealing with.
Isn't that what I'm already doing? I assume that the author believes that he's right often enough to argue his position(s), but feels dejected without being proven wrong at the end of the argument.
But there's another important point here: the answer to the "am I really right?" question isn't always clear at the start of every argument.
Unless you believe there's room for (dis)proving your position, or getting some nuance on a topic [1], it's not a debate or an argument - it's a lecture. And lectures depend on other social dynamics which don't apply here.
[1] For example, maybe there are other reasons behind the position that the person can't express easily, or maybe you're actually arguing about different things.
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.
> 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.
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).
>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.
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
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...
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
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".
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.
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.
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
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.
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 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.
> 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.
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.
> 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?
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.
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.
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.
> 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.
It's a fair policy. Getting those verbose, AI-authored walls of text is very annoying, especially when you're expected to thoroughly review it. It's like a denial-of-service attack on the human mind. I can only imagine how frustrating this can get in open projects that get a lot of contributions.
However, I don't think this will discourage AI-based coding at all. In fact, I see two potential outcomes of these policies:
- Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier.
- Positive: Submitters actually provide to-the-point, no-bullshit commits and comments - "here's the code, here's why I made that change, here are the effects of that change". Even if AI-generated, these small contributions may become much easier to verify & validate. We may even see some standardization in terms of what qualifies as an appropriately sized contribution, what requires more thorough review (e.g., adding unverified dependencies), etc.
I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category.
> - Negative: Submitters just add stylistic markers to make their accounts and output seem human-generated. This is like syntactic sugar: the core content and the size of contributions stay the same, but the style gets quirkier.
From my experience reviewing, most contributors never read the policies, especially those making a "quick AI PR". I don't expect the new policy to change this much.
> Positive: Submitters actually provide to-the-point, no-bullshit commits and comments
> From my experience reviewing, most contributors never read the policies, especially those making a "quick AI PR". I don't expect the new policy to change this much.
True. At least with a policy about it, the project maintainers can unilaterally close such PRs without further internal or external discussion on any case-by-case basis.
Dingdingding, we have a winner. The main use of such a policy is to be able to just close those giant wall-of-text PRs and have something to point to when people start to scream it's not fair.
Why is a policy necessary. you were never entitled to have your pr merged in the first place? If pr wasn't reviewable pre AI I'd expect it to be closed or ignored too
The policy isn't necessary to close the PR. The policy just helps to shut down the ensuing discussion after closing the PR. It helps in quickly dealing with well-meaning onlookers asking for clarification when you block PRs from the account.
Before AI a large pull request was enough effort to make that you could assume good faith work on the part of everyone. Likely even if it is bad for architectural reasons it is solving an itch other users have and it is reasonable for them to want an explanation why you refused someone who made this much effort. And since the effort required meant it didn't happen often it wasn't a big deal to provide that.
These days large PRs are easy to create and so humans need to shut them down.
Whether or not someone is entitled to something has very little bearing on whether someone believes they are entitled to something (and are willing to waste everyone's time to make a stink about it). Having clear rules to point to, even after the fact, is surprisingly effective in mitigating that.
Or, put more bluntly, your belief in what people ought to feel entitled to has no bearing on what they do believe, and policy needs to address the latter, not the former.
Prior to AI making a PR involved considerable effort from a human. So the default position for many open source projects was that it deserved some level of attention for the effort. Even if many projects in practice would struggle to review every PR. But with AI tools this dynamic has shifted dramatically - many PRs have basically zero effort been put into it. Additionally there are many more of them, and often way bigger also.
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.
Reading AI PRs reminds me of Monty Python's holy grenade:
"And the Lord spake, saying, ''First shalt thou take out the Holy Pin. Then shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thy foe, who, being naughty in My sight, shall snuff it.'
I wouldn't mind reading that and having a good chuckle while processing an MR, as long as the comment had been crafted by a person. But now I think writing in grunts is gonna become the thing. "pete? you good boy? we won't hire you/ paper you gave HR girl with older gigs? remember it pete my boy? too many words/ words were too long/ dots you used dots/ you scratched long dash with knife, but baby saw scratch/we don't ai pete/ask if they have job in next cave/good luck."
I've found that the instructions "be extremely concise" gets me much closer to output that's actually sensible/helpful rather than another wall of text.
> From my experience reviewing, most contributors never read the policies, especially those making a "quick AI PR". I don't expect the new policy to change this much.
The policy allows the reviewer to reject it on the "AI" grounds.
Unfortunately, only a single PR like this comes to mind. Most AI authors we've seen were identifiable mainly by overly verbose PR descriptions, meaningless code changes and copy-pasting more AI output when questioned.
A contributor in good faith is going to accept criticism and resubmit an improved change: less files modified, more explanation, more focus, references to actual tickets and discussion with actual developers.
They could allow AI PRs, but then have another AI PR reviewer reject them if they do not match the definitions for `to-the-point` `no-bullshit` commits.
Please provide 3 examples where layering on MORE of the offending technology has solved the problem. Spam? Malware & Viruses? Customer Service? Hiring & Recruitment?
We just recently started that policy so we'll see how it goes. If anything, having it stated as policy lets us filter out these requests without spending brain tokens on them.
I've always instructed Claude to check the policies first, frankly I'm surprised it's not smart enough to do that already. Would be easy to add to a system prompt. But usually it doesn't matter because many projects have no policies, or maybe they exist but only in hidden forum posts issues or something.
> I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category.
The problem is that a lot of AI contributions are lazily produced without review. Those that have been properly reviewed for correctness (tested to ensure actually working with no obvious undesirable side effects, tweaked where needed to be readable and understandable, fitting the other guidelines of the project, etc) will be indiscernible from human-only contributions, but there are a lot of people who make no such effort so the majority are not nearly this good.
> The problem is that a lot of AI contributions are lazily produced without review.
That sounds like a contributor problem. Not an AI problem.
I still don't understand a "no AI" policy whose only purpose is to weed out bad PRs. You should be weeding out bad PR's regardless of their source. I don't see why treating a purely human-authored, but bad, piece of code should be treated any differently than an AI-authored one.
All they've accomplished is creaking an environment where good code can't be submitted unless the submitter lies.
You should not be weeding out bad PRs regardless of their source! A pull request is a social artifact whose value and meaning is dependent on its author; bad PRs from a human author often mean things such as "I'd like to learn how this works and join your community". So it can be both satisfying and worthwhile to spend your effort on cleaning it up, even if it starts to take as much or even more effort than doing it yourself would have.
You're not the first person I've seen argue that authorship doesn't matter, so I don't want to blame you for it, but I really don't understand where that idea is coming from. To me it seems obviously wrong.
> You should not be weeding out bad PRs regardless of their source! A pull request is a social artifact whose value and meaning is dependent on its author; bad PRs from a human author often mean things such as "I'd like to learn how this works and join your community".
I think the difference in perspective might come from the fact that to many people the code and features matters more than any community or the idea of participating in it. If it works, it works.
Or maybe they’re not even indifferent about the community, just upset at people throwing away working code.
The Godot maintainers have decided they don't support that perspective. In their words, they value "being cautious about feature creep" and "dedicated to high code quality"; they don't accept that all working code should be merged.
Aspiring contributors who'd like to make a different tradeoff are of course free to make a fork. But then all of the stuff in their fork won't benefit from the participation of the community, which I suspect most such people do value even if they identify as a "code first" person.
> they don't accept that all working code should be merged.
That’s perfectly within their rights to do!
> Aspiring contributors who'd like to make a different tradeoff are of course free to make a fork.
Too many of those do fragment the development effort and hurt any project.
Here’s hoping that Godot doesn’t struggle too much with people who don’t care about their rules and spam PRs regardless and that the people who want to commit AI code regardless because it works and is good in their eyes at least demonstrate enough initiative to cheat convincingly (maybe actually read the code and make it their own). Godot is a pretty cool project!
Wonder what the middle ground would look like - a project with super high test coverage and tooling, that also requires at least 20 USD in Opus tokens spent on review on the behalf of the author or something, before an actual human being is bothered with it? Heh.
Says the definition? I don't really understand your response. A pull request is a request from Alice (the author) that one of Barbara, Chris, Daniel (the maintainers) should pull her code into a particular branch.
Many communities do have a norm that all authors are to be presumed equal, as long as they're prepared to take advice and learn from it. (That's where all experts start, after all.) That's the norm that Godot are trying to protect here. If they don't stop accepting AI-authored contributions, they worry, reviewers will start to implicitly load-shed by not reading PRs from people they don't recognize.
I was explaining why the Godot maintainers have chosen to enact the policy described in the source article, in response to a comment saying that they should not have enacted it. I don't understand why you think I'm dictating or arbitrating anything.
> > The problem is that a lot of AI contributions are lazily produced without review.
That sounds like a contributor problem. Not an AI problem.
Ish. The tool is not doing the job fully, the contributor is not doing their task properly, checking for that, and fixing the issues.
> I still don't understand a "no AI" policy whose only purpose is to weed out bad PRs. You should be weeding out bad PR's regardless of their source.
Think of it like offering a job, and getting 100s of CVs. You don't have time to review each in detail, so you weed out a chunk of them using superficial cues that have been indicators of issues in the past. They are filtering the other contributions too, the no AI rule is just part initial triage to save a lot of time.
You have missed a key point in what I wrote: "Those that have been properly reviewed for correctness [before being submitted] will be indiscernible from human-only contributions". It is like a Turing test: if you take the effort to make your AI aided contributions good enough to be indiscernible from good human-only contributions then the no-AI filter won't bother you because the people or automations enforcing it won't be able to discern that your contribution was assisted.
> where good code can't be submitted unless the submitter lies.
No. Unless it looks like a good contribution looks.
The problem a lot of projects are facing right now is being inundated by bad PRs from people using AI without the effort to, or likely the knowledge of how to, properly understand and explain & document the change. People have a limited amount of time and if the filter saves a lot of time then maybe losing one or two good contributions due to the filter is worth it - better that than the project stalling under the weight of managing all the PRs.
This is one of the reasons, even pre-AI, some projects declared themselves "open source but not open contribution".
If they are simply filtering out based on signs of AI, then there is no lie.
If they are explicitly asking “was AI used” then yes, there is a direct lie involved.
If there is no explicit question but you are including “lies by omission”, then be aware that there are many things people choose not to say that they would be unfairly judged for if they did state (gender details, certain parts of their history, etc) so that might not be a line we want to draw.
I'm not exactly pro-AI, in fact I'm avoiding it in DayJob to the point where I expect at some point I'll be given the choice “get with the program or leave” (I plan to leave at that point, preferably by my own choice though we'll see how heated the discussion gets!), but if there is a at least one human at the end of the process that is properly testing and cleaning everything up so there can be nothing problematic in the AI output that survives, is that really practically any different to a fully human created contribution?
The problem with AI contributions in the vast majority of cases is the lazy ones, especially considering the sheer number of them. Using signs of AI as a code/documentation smell when it comes to filtering contributions is fine, especially if you have up-front requested no such contributions be sent. Permanently blocking people who have sent obviously AI-generated contributions previously despite you asking them not to, is also fine just as blocking people who have sent in entirely human made contributions that break your other requests/rules is. But banning all AI use when if you can't tell if a good contribution did or didn't use AI aid somewhere in the process, is both a daft extreme and actually impossible (if you can't tell, how do you tell?!).
I'm saying that most people, even most programmers, don't have the facilities or inclination to train new models man. I've done it plenty of times and I absolutely don't recommend it.
Frankly I don't think you even know what the phrase entails.
So again, you can train people but not AI? That's literally what you've said and now moving the goal posts in a way that makes no difference to what you said being patently wrong.
It's wild having to argue with people who say demonstrably untrue things and then refuse to admit that what they said was wrong.
> It's like a denial-of-service attack on the human mind.
I think this may be an example of deliberate hostile design, attempting to force users to adopt LLM based solutions to then summarise the vast output. Pushing back against AI contributions as such in this context makes sense, especially in software with an existing proven track record of great value delivery like Godot.
Who says anything about „this far in the future“? It’s enough for Anthropic et al to realize this one or two model versions ago, see it as a strategic advantage and push for that behavior.
Literally some of the first advertised uses for LLMs were both "You can feed it bullet points and it will compose an entire email" and "You can take long emails and condense them into bullet points!" They've been doing this since day 1.
While it certainly didn't enter a mind of any director making decisions (because they can't comprehend not defecting in a prisoner's dilemma, being sociopaths), it was plainly obvious to every person even remotely connected to IT in the past two decades. If one makes a better and faster spam generator and the same unchanged program also works in reverse, by sifting through spam and condensing it to a readable summary, that it will be immediately co-opted in a spam arms race by all sides of the war and become essentially mandatory.
AI also works better with concise, focused, high information density text. So AI-spam text hurts both humans and AIs, but humans more so than AIs. It is always a negative, except for the "competition" between (human with) AI and human without AI.
This was the original rule in linux kernel as well. No more than 200 loc per patch. We should also introduce this to git commits and pull request descriptions:
1. 400 chars/10 lines per commit
1b. Not more than 3 commits in the initial pull request
2. 20 lines of explanation for pull request
3. not more than 3 pull request open at any one time
YES! "No AI" policies that are purely based on technical grounds make no sense to me. Bad PR's are bad PR's regardless of their source.
Are we really in a situation where good code that solves a problem won't be merged because the person the person checked the "I used AI" box on the PR?
Ban PR's that are too big, don't have a clear purpose, touch too many areas, etc.
It's really a question of how much time you're willing to spend sorting through spam. "No AI" might be a blunt hammer, but the people submitting slop aren't reading guidelines anyway, and it's easier just to reject it early. Frankly, I'm sure if people wanted to sneak in an AI generated code by carefully reviewing it and making sure it's targeted and well tested... I'm sure they could, but those people aren't the problem.
> Frankly, I'm sure if people wanted to sneak in an AI generated code by carefully reviewing it and making sure it's targeted and well tested
But this is exactly the point I'm making. If the code is carefully reviewed, targeted, and tested, then why make people have to lie in order to submit PRs?
Why not just say "Irresponsible use or agentic-based PR's will be auto-rejected"?
And that's not even mentioning that tools like Github Copilot can just act like fancy autocomplete. There are dozens (if not hundreds) of different ways to use these tools.
I guess I'm just really not sure how you can unequivocally forbid these insanely powerful tools when they are almost certainly going to be a large part of developer's workflows going forward?
> Why not just say "Irresponsible use or agentic-based PR's will be auto-rejected"? ... tools like Github Copilot can just act like fancy autocomplete.
For what it's worth, this is basically what the Godot policy does say. It's not a blanket ban:
> No autonomous AI agent use or vibe coding
> No use of AI to generate substantial pieces of code ... AI assistance should be limited to menial things (like code completion, regex, or find and replace).
more that, most C++ developers aren't "C++ people", the ones that are are a very vocal, but very small minority, though they're disruptive enough that some projects (re: the aforementioned linux kernel) elect to abandon C++ entirely just to avoid them
> Switching to a more modern topic, the introduction of the Rust language into Linux, Torvalds is disappointed that its adoption isn't going faster. "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust."
The whole point of not-accepting AI authored code is because this line is not respected=>"Submitters actually provide to-the-point, no-bullshit commits and comments". You're putting way too much faith into the human minds ability to resist clout-chasing. AI isn't able to humanize code without human supervision.
In my day job, I do a lot of AI coding but almost never have Claude actually create the PR titles or descriptions for me. It produces too much content, and the justification/background sections are often not quite right.
Most PRs to me are not coming out of nowhere anyway, rather they're "here's the linked issue, I started out addressing it by doing X and Y, but then Y got hairy so I switched to Z, hope that makes sense but happy to discuss further as well."
And most feedback is not "let's have you explain the design to me in a diff comment" but rather please explain this design in a code comment so that the next reader of the source will have your context.
Yeah I think this is a good approach. I’m pretty AI-optimistic when it comes to making code changes. But reading AI generated descriptions (including pull requests) is absolutely the worst. That content really needs to be human written. Not just for the benefit of the reader, but it also helps the writer exercise their understanding.
i want to figure out some extra practice - get a step of claude sending me a PR, then me accepting it after review, and then rewriting the merge to be a new PR for general review
Say AI is used to identify and rewrite a single function that improves performance or fixes a bug, then the developer carefully reviews and tests it and submits a nice tight PR with all human communication.
So they don’t want that? They would just reject it?
If I’m understanding correctly, under the policy the higher performance function / bug free submission would be rejected and they could ask for a rewrite.
Should it then be rewritten from scratch, and clean room engineered so it doesn’t resemble the AI too much?
> The Foundation says we can expect Godot's contributing policy to soon include explicit rejections of AI-authored code, noting that contributors should only use AI assistance for "menial things" and must disclose its use. Additionally, the Foundation will reject any AI-generated text in human-to-human communications, saying it's "a basic principle of respect"—though it says machine translations "are still acceptable" if the original text was human-authored.
As long as your bots aren't contributing low-effort garbage in a push to give their operator some of those tasty internet brownie points you should be fine
All these projects should seamlessly run a fork in parallel that accepts AI and has AI for review and approval. Both camps are happy.
Basically a play sandbox for contributors to not get jaded. A honeypot to contain the verbosity vomit, while also serving as positive public relations by keeping young contributor morale from starting in the basement.
Everyone has been that person once early in their life who is told they aren’t welcome and never comes back. Maybe it was SourceForge or IRC, maybe it was Wikipedia.
What's the point of this fork if it's just a landing spot for stuff that's not really wanted? Wouldn't that just be more condescending then telling people what's actually required for a contribution? Besides, the nature of forking is you can just do it yourself anyway. If people love their AI changes they can just make their own fork.
Plus I don't know how you could do this "seamlessly" -- someone has to manage merge conflicts, and as the codebases diverge it's just going to get more and more gnarly. (this is the reason most people don't maintain their own forks in the first place)
I mean, not sure if everyone wants that for their project, and there will surely be plenty of trade-offs.
But it would be a very good compromise: You (the maintainer) get only human-generated PRs in the canonical project, and they (pro-AI contributors) get a lower-threshold sandbox to play with. Best case scenario, you cherrypick the pre-filtered golden nuggets to bring back to the canonical project.
Yes - if I can tell that you used AI (except maybe because of an unnaturally high work rate, or obviously an AI declaration, which is good!), you fail. Keep up the quality and I don't care too much.
I have some misgivings about AI, but I'm not a fundamentalist - you can't be or the machine will squish you, frankly - but please, don't spam me with text or code that could be much shorter. Relevant quotes:
"I didn't have time to write a short letter, so I wrote a long one instead"
My agents operate on their own branch for a feature, they commit code changes after each step or phase with a description of what was changed, why, and what’s left.
This helps with PR reviews as it prevents a giant wall of text but it’s still verbose. However doing it this way cuts down on the wall of text at the expense of increased PR frequency.
Better way is to provide a Claude.md with strong stylistic guidelines and loc requirements. Else it will be a chicken and mouse game of what is from AI.
Not quite accomplished, if it's creating text on the pull requests that looks sufficiently human-like, but you're still worried about the quality of the code and that the submitter doesn't understand it.
Right but as they mentioned, at least then they are communicating with a human about it, not going back and forth with a machine which they clearly do not enjoy.
Efficiency is the key. I haven’t written any issue before so LLM was much quicker than manual experiment. I have personally checked the result before submission.
You "personally checked" the result (generated by an LLM, a huge black box with extensive knowledge of all fields) to the best of your knowledge. There is a mismatch between what the machine knows (and has done as the result of it) and what you think you know.
Implementing a fix implies knowledge of the inner workings that brought you to it. A fix made by a LLM does not give you that.
ArXiv is a good complement to the modern peer review, IMO. As long as someone "vouches" for you, and you adhere to its minimal standards, you're able to post a paper. Other readers can decide whether the paper is worth their attention, and whether the presented ideas or results are valuable.
It's also good that it doesn't gatekeep with the paywalls that you can pretty much only afford by affiliating yourself with a toll-paying institution.
Obviously, there are plenty of flaws with this system:
1. If you're associated with a brand (e.g., Google, MIT) or have a recognizable co-author (e.g., Yann LeCun), you'll get attention and citations no matter what.
2. "Vouching" can also just mean accepting someone's email request without ever having met or known them.
3. It puts the effort on the readers to decide whether each paper is valuable, and particularly scientifically valuable, for which most readers will be unequipped.
4. "Minimal standards" can be gamed by AI-generated submissions.
I'd love to see a synthesis of arXiv, open-access publishing and artifact reviews, like the following:
- Have a number of reviewers on retainer, or design a reward system similar to bug bounties. The reward mechanism probably shouldn't be based on money or allow a winner-takes-all strategy.
- Have a number of badges with respect to the quality and value of the paper. For example: validated by peers (i.e., reviewed by at least 3 peers with minimum borderline accept consensus), valuable (i.e., reviewed by at least 5 peers with a valuable indicator), etc.
- Allow vouched comments on the platform, and moderate for self-promotion, toxicity, etc. Obviously a big ask.
- Improve the "vouching" system, or add badges like "vouched by X people" or "vouched by established scientist".
Hope their new organization will implement some of these improvements.
I volunteered for a project [1] with roughly this philosophy. Traditional publishing currently serves three purposes:
- Organise peer feedback
- Publish the work
- Recognise good work, helping with both discovery and credit
That latter part especially is what allows publishers to charge the ridiculous markup that they do.
But with "modern" technology, feedback and publishing really doesn't require all that infrastructure - email and arXiv can easily be used to self-organise that. So we built a system of recognition that does not block publication, and can be used as a layer on top of arXiv and any other venue, allowing peers to vouch ("endorse") for a work.
I had even proposed and implemented an integration for arXiv Labs that got accepted, but then never merged. I should follow up on that...
Overlay journals can also have a short editorial description of the paper, basically an executive summary of what it says and why it's interesting or noteworthy.
>3. It puts the effort on the readers to decide whether each paper is valuable, and particularly scientifically valuable, for which most readers will be unequipped.
You say it as if replication crisis doesn't exist and publish or perish is not a thing.
Actually, the replication crisis shows how difficult (or underinvested) the process of reviewing is.
Removing this (often very basic) peer review doesn't somehow fix the problem. The solution lies in more thorough reviews and replication studies, not in everyone deciding for themselves.
Unfortunately, I don't think systems thinking alone would help much.
One could present the case in favor of Internet age verification to the nth-order effects, while downplaying the effects in the case against.
So, in addition to presenting the cases with foreseeable effects, we need ways to compare the impact of worst-case scenarios in the two cases, and make a decision or compromise based on that.
Systems thinking is one thing. One sided systems thinking is another.
If you disregard the challenges kids and their parents, or adults as a whole, are facing with just social media, you can easily make a case against age verification.
Yet, the whole reason we are at this juncture, is because there are actual injuries being felt by people. Not because privacy isn’t valued or hasn’t been defended regularly.
While I can understand being skeptical of non-experts' claims that such answers are enough, I don't understand why you call it "psychosis" and not simply naivety or lack of expertise.
At the same time, the new so-called "models" haven't been pure transformer-based LLMs, but entire systems with tools (with access to the Internet), data storage, and the options to trigger additional instances for different tasks.
Because some people develop actual psychosis. They go down some rabbit hole with an LLM until the LLM makes them believe they invented new kind of physics that makes them go harassing experts who obviously try to ignore them because its all nonsense.
For me, what others said and literally showed with Claude Code, et al, and what I’ve been experiencing with it, clearly signal way lower standards. But this was true even before LLMs.
That's really not the argument being made here, and you're panning it further by claiming this is staunchly anti-LLM.
The idea here is to signal that you can absolutely use LLMs to help you figure something out. But also, they're wrong a lot. So use your own brain too.
I'm not always a fan of the squiggles, but I can appreciate the UI pattern. It's definitely one of the more intuitive and recognizable visual markers for "something's wrong with this word".
Your scenario is confusingly formulated, but it ultimately deals with moral risk.
If you suspect that it's fraud, you should seriously consider whether you want to be a part of it, even if you can't prove the fraud. Examples are companies centered around cryptocurrencies: not all of them end up being rugpulls, but enough of them do, making every new company potentially morally risky for each engineer.
If you only suspect that it's an overly ambitious project, but not fraud, the moral risk is obviously lower. Sure, it may be economically risky - as all unproven business models are - or you may discover the fraud later (like the author apparently did). Examples are startups like SpaceX in its initial stages: there was nothing ostensibly fraudulent in trying to make and sell better rockets, just very economically risky.
Obviously, the devil is in the details, but if you're honest with yourself, you should do your due diligence (i.e., does it seem like fraud or not) and determine your moral risk appetite. It's up to the wider society to reduce and punish the unacceptable levels of moral risk, regardless of the appetites of individual engineers.
Because I also like being correct, a debate to me has become something of a game where (ideally) we both win in both end scenarios: either my thinking was correct, and now I verified/validated it, and got you to think differently; or my thinking was incorrect, and you corrected it for me (or helped me get there).
However, I implicitly figured out that there are some qualifiers to actually getting the benefits:
- Can I be, and remain, polite and reflective? If not, my personality or knee-jerk responses will always get in the way of an argument's benefits.
- Is the subject sensitive to the person for whatever reason? If yes, any argument inadvertently becomes a signal of a person's worth.
- Are we in a competitive setting (e.g., corporate meeting, or larger social group)? If yes, any argument inadvertently becomes a social status competition.
- Do I know how to stick to the issue (instead of moving goalposts), and stop when the debate gets overwhelming (too long, too much difference)? If not, I'll overstep the boundary after which it isn't mutually beneficial anymore.
These are not easy to figure out, and sure, maybe stop arguing with most people if the conditions aren't right.
But unless you stop communicating altogether, I don't see how you can stop arguing with people in general.