7 ms·

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 deni

by TomasBM 3mo ago

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.

ivorius 3mo ago
> - 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 That would be a dream.
- watwut 3mo ago
  > 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.
  - dspillett 3mo ago
    > allows the reviewer to reject it on the "AI" grounds … but still unfortunately leaves reviewers having to spend time checking submissions and rejecting them.
    - fendy3002 3mo ago
      oh but it'll be very2 helpful and the time spent will be short. It's easy to verify: * new contributor? * more than 10 files affected (higher count are more valid)? * wall of text on description without screenshots, etc? just close the PR as AI, and then the contributor can challenge it if they feel it should not.
      - HelloNurse 3mo ago
        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.
    - jon-wood 3mo ago
      At least half the people firing off LLM generated PRs will have left the "Coauthored-by: Claude" line on it allowing automated rejections.
      - ivorius 3mo ago
        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.
- QuantumNomad_ 3mo ago
  > 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.
  - maybewhenthesun 3mo ago
    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.
    - mcphage 3mo ago
      > when people start to scream it's not fair Or LLMs, as we have seen.
      - chrisjj 3mo ago
        Or, who knows, the "AI" might gain sufficient intelligence to read the policy...
        julianlam 3mo ago
        Then we'll amend the policy to instruct LLMs to author PRs as Fred Flintstone, yabba dabba doo!
    - tayo42 3mo ago
      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_hoser 3mo ago
        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.
- whateverboat 3mo ago
  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.
  - ivorius 3mo ago
    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.
    - adalacelove 3mo ago
      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.'
      - dsign 3mo ago
        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."
    - ray_kay777 3mo ago
      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.
- snarfy 3mo ago
  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.
  - mort96 3mo ago
    And who pays for the (likely significant, and controllable by everyone) tokens such a system would use?
    - julianlam 3mo ago
      A small 4-9B model would be able to run cheaply for this sort of work.
      - krainboltgreene 3mo ago
        What question do you think you're answering?
        Cpoll 3mo ago
        The Godot Foundation pays for it if it furthers their mission.
        mort96 3mo ago
        Does it?
  - skeeter2020 3mo ago
    Please provide 3 examples where layering on MORE of the offending technology has solved the problem. Spam? Malware & Viruses? Customer Service? Hiring & Recruitment?
- paulddraper 3mo ago
  > That would be a dream. “Mission. Fucking. Accomplished.” https://xkcd.com/810/ https://xkcd.com/810/
- stronglikedan 3mo ago
  > That would be a dream. 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.
- DonsDiscountGas 3mo ago
  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.
sixtyj 3mo ago
[flagged]
- grey-area 3mo ago
  If you understood the change, writing a short description of the problem and the fix yourself would be trivial.
  - sixtyj 3mo ago
    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. So why the hate? :)
    - unfocso 3mo ago
      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.
      - sixtyj 3mo ago
        Why do I argue here anyway? :) Before sending it I have tried the patch locally. It worked. So I sent the proposal. And it was accepted by the author.
    - cyclopeanutopia 3mo ago
      Efficiency rarely is the key.
    - chrisjj 3mo ago
      > Efficiency is the key. ... and includes the reviewer efficiency disrespected by your verbose bot.
onesandofgrain 3mo ago
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.
captainbland 3mo ago
> 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.
- someonebaggy 3mo ago
  There's no chance that anyone saw that far ahead in the future and planned it. It's emergent behaviour.
  - x3ro 3mo ago
    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.
  - jayd16 3mo ago
    Big tech: "Should we add any functionality at all to filter AI slop in any of our platforms?" "...nah" Its not 500 moves ahead.
  - Yizahi 3mo ago
    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.
  - 12_throw_away 3mo ago
    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.
flexagoon 3mo ago
> Submitters just add stylistic markers to make their accounts and output seem human-generated https://xkcd.com/810/ https://xkcd.com/810/
- CamouflagedKiwi 3mo ago
  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.
  - someguynamedq 3mo ago
    No different than a human written PR
    - CamouflagedKiwi 3mo ago
      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.
whateverboat 3mo ago
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
- TomasBM 3mo ago
  Seems like this policy would apply pretty well regardless of who/what generated the code.
  - mexicocitinluez 3mo ago
    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.
    - overgard 3mo ago
      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.
      - mexicocitinluez 3mo ago
        > 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?
dspillett 3mo ago
> 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.
- mexicocitinluez 3mo ago
  > 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.
  - krainboltgreene 3mo ago
    Probably because a human authored contribution, no matter how bad, can be trained to make it good and also improves the community.
    - mexicocitinluez 3mo ago
      > can be trained to make it good and also improves the community. AI can be trained. Also, AI can create code that improves the community. It's replies like this that leave me even more confused.
      - skydhash 3mo ago
        Human being trained is already proven (that’s how most maintainers came to be). Can you explain how AI can be trained in the above context?
peepee1982 3mo ago
If a commit is written by AI but reads as authored by a human, the developer has done their job and nothing will be flagged. If commits written by AI wouldn't be substantially different, there would be no need to reject them. So I agree with you that it won't discourage AI-based coding. But that's not even the intent.
blackoil 3mo ago
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.
- ivorius 3mo ago
  I made a PR like that, but it was rejected by the community (for some valid reasons and some not so valid). https://github.com/godotengine/godot/pull/118681 https://github.com/godotengine/godot/pull/118681
  - someguynamedq 3mo ago
    Which goes to show that despite all of the rationalization both here and in the comments of that PR, the push to ban AI is religious not reasoned.
clktmr 3mo ago
> I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category. It's pragmatic. Linus once said, the reason C++ is not allowed in the kernel is to keep the C++ people out.
- ahartmetz 3mo ago
  Joke's on him, many Rust people are current or former C++ people.
  - RicardoLuis0 3mo ago
    just because someone writes or wrote C++ doesn't make them a "C++ person", and "C++ people" are very much against rust
    - ahartmetz 3mo ago
      Only true Scots... err C++ people are against Rust, I see :>
      - RicardoLuis0 3mo ago
        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
  - spopejoy 3mo ago
    > 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." https://www.zdnet.com/article/linus-torvalds-talks-ai-rust-adoption-and-why-the-linux-kernel-is-the-only-thing-that-matters/ https://www.zdnet.com/article/linus-torvalds-talks-ai-rust-a...
reactordev 3mo ago
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.
chrisjj 3mo ago
> I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category. Perhaps reconsider "If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer..."
ahartmetz 3mo ago
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" "Brevity is the soul of wit"
WhitneyLand 3mo ago
How strict is this no AI policy? 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?
- betorabinovich 3mo ago
  from TFA: > 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
shimonamit 3mo ago
[flagged]
mikepurvis 3mo ago
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.
- lokar 3mo ago
  I think OSS maintainers are in the middle of intersecting trends: - tough hiring market, especially for more Jr candidates - the perception (true or not) that OSS contributions help get attention from recruiters - LLMs making it very easy to generate “contributions”
- 8note 3mo ago
  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
- apf6 3mo ago
  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.
thewhitetulip 3mo ago
DoS attack is exactly what I describe an AI generated PR!!
basch 3mo ago
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.
- marcosdumay 3mo ago
  Do you volunteer to maintain the sloppy fork?
  - endominus 3mo ago
    I think most pro-AI people would be happy to let an AI maintain the sloppy fork. What reason would they have to complain, after all?
- TomasBM 3mo ago
  This is actually a good idea. 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.
  - basch 3mo ago
    Precisely. Cherrypick nuggets from poo. It's there if you care to wade into it. May occasionally strike gold.
- overgard 3mo ago
  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)
Bukhmanizer 3mo ago
I recently wrote a tool to help me read AI generated PRs and it’s pretty sad that it’s got to this point.

by TomasBM 3mo ago

ivorius 3mo ago

> - 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 That would be a dream.

watwut 3mo ago
> 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.
- dspillett 3mo ago
  > allows the reviewer to reject it on the "AI" grounds … but still unfortunately leaves reviewers having to spend time checking submissions and rejecting them.
  - fendy3002 3mo ago
    oh but it'll be very2 helpful and the time spent will be short. It's easy to verify: * new contributor? * more than 10 files affected (higher count are more valid)? * wall of text on description without screenshots, etc? just close the PR as AI, and then the contributor can challenge it if they feel it should not.
    - HelloNurse 3mo ago
      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.
  - jon-wood 3mo ago
    At least half the people firing off LLM generated PRs will have left the "Coauthored-by: Claude" line on it allowing automated rejections.
    - ivorius 3mo ago
      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.
QuantumNomad_ 3mo ago
> 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.
- maybewhenthesun 3mo ago
  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.
  - mcphage 3mo ago
    > when people start to scream it's not fair Or LLMs, as we have seen.
    - chrisjj 3mo ago
      Or, who knows, the "AI" might gain sufficient intelligence to read the policy...
      - julianlam 3mo ago
        Then we'll amend the policy to instruct LLMs to author PRs as Fred Flintstone, yabba dabba doo!
  - tayo42 3mo ago
    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_hoser 3mo ago
      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.
whateverboat 3mo ago
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.
- ivorius 3mo ago
  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.
  - adalacelove 3mo ago
    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.'
    - dsign 3mo ago
      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."
  - ray_kay777 3mo ago
    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.
snarfy 3mo ago
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.
- mort96 3mo ago
  And who pays for the (likely significant, and controllable by everyone) tokens such a system would use?
  - julianlam 3mo ago
    A small 4-9B model would be able to run cheaply for this sort of work.
    - krainboltgreene 3mo ago
      What question do you think you're answering?
      - Cpoll 3mo ago
        The Godot Foundation pays for it if it furthers their mission.
        mort96 3mo ago
        Does it?
- skeeter2020 3mo ago
  Please provide 3 examples where layering on MORE of the offending technology has solved the problem. Spam? Malware & Viruses? Customer Service? Hiring & Recruitment?
paulddraper 3mo ago
> That would be a dream. “Mission. Fucking. Accomplished.” https://xkcd.com/810/ https://xkcd.com/810/
stronglikedan 3mo ago
> That would be a dream. 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.
DonsDiscountGas 3mo ago
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.

sixtyj 3mo ago

[flagged]

grey-area 3mo ago
If you understood the change, writing a short description of the problem and the fix yourself would be trivial.
- sixtyj 3mo ago
  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. So why the hate? :)
  - unfocso 3mo ago
    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.
    - sixtyj 3mo ago
      Why do I argue here anyway? :) Before sending it I have tried the patch locally. It worked. So I sent the proposal. And it was accepted by the author.
  - cyclopeanutopia 3mo ago
    Efficiency rarely is the key.
  - chrisjj 3mo ago
    > Efficiency is the key. ... and includes the reviewer efficiency disrespected by your verbose bot.

onesandofgrain 3mo ago

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.

captainbland 3mo ago

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

someonebaggy 3mo ago
There's no chance that anyone saw that far ahead in the future and planned it. It's emergent behaviour.
- x3ro 3mo ago
  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.
- jayd16 3mo ago
  Big tech: "Should we add any functionality at all to filter AI slop in any of our platforms?" "...nah" Its not 500 moves ahead.
- Yizahi 3mo ago
  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.
- 12_throw_away 3mo ago
  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.

flexagoon 3mo ago

> Submitters just add stylistic markers to make their accounts and output seem human-generated https://xkcd.com/810/ https://xkcd.com/810/

CamouflagedKiwi 3mo ago
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.
- someguynamedq 3mo ago
  No different than a human written PR
  - CamouflagedKiwi 3mo ago
    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.

whateverboat 3mo ago

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

TomasBM 3mo ago
Seems like this policy would apply pretty well regardless of who/what generated the code.
- mexicocitinluez 3mo ago
  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.
  - overgard 3mo ago
    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.
    - mexicocitinluez 3mo ago
      > 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?

dspillett 3mo ago

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

mexicocitinluez 3mo ago
> 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.
- krainboltgreene 3mo ago
  Probably because a human authored contribution, no matter how bad, can be trained to make it good and also improves the community.
  - mexicocitinluez 3mo ago
    > can be trained to make it good and also improves the community. AI can be trained. Also, AI can create code that improves the community. It's replies like this that leave me even more confused.
    - skydhash 3mo ago
      Human being trained is already proven (that’s how most maintainers came to be). Can you explain how AI can be trained in the above context?

peepee1982 3mo ago

If a commit is written by AI but reads as authored by a human, the developer has done their job and nothing will be flagged. If commits written by AI wouldn't be substantially different, there would be no need to reject them. So I agree with you that it won't discourage AI-based coding. But that's not even the intent.

blackoil 3mo ago

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.

ivorius 3mo ago
I made a PR like that, but it was rejected by the community (for some valid reasons and some not so valid). https://github.com/godotengine/godot/pull/118681 https://github.com/godotengine/godot/pull/118681
- someguynamedq 3mo ago
  Which goes to show that despite all of the rationalization both here and in the comments of that PR, the push to ban AI is religious not reasoned.

clktmr 3mo ago

> I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category. It's pragmatic. Linus once said, the reason C++ is not allowed in the kernel is to keep the C++ people out.

ahartmetz 3mo ago
Joke's on him, many Rust people are current or former C++ people.
- RicardoLuis0 3mo ago
  just because someone writes or wrote C++ doesn't make them a "C++ person", and "C++ people" are very much against rust
  - ahartmetz 3mo ago
    Only true Scots... err C++ people are against Rust, I see :>
    - RicardoLuis0 3mo ago
      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
- spopejoy 3mo ago
  > 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." https://www.zdnet.com/article/linus-torvalds-talks-ai-rust-adoption-and-why-the-linux-kernel-is-the-only-thing-that-matters/ https://www.zdnet.com/article/linus-torvalds-talks-ai-rust-a...

reactordev 3mo ago

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.

chrisjj 3mo ago

> I personally wouldn't care if it was AI-generated or not, as long as the content fit the latter category. Perhaps reconsider "If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer..."

ahartmetz 3mo ago

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" "Brevity is the soul of wit"

WhitneyLand 3mo ago

How strict is this no AI policy? 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?

betorabinovich 3mo ago
from TFA: > 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

shimonamit 3mo ago

[flagged]

mikepurvis 3mo ago

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.

lokar 3mo ago
I think OSS maintainers are in the middle of intersecting trends: - tough hiring market, especially for more Jr candidates - the perception (true or not) that OSS contributions help get attention from recruiters - LLMs making it very easy to generate “contributions”
8note 3mo ago
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
apf6 3mo ago
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.

thewhitetulip 3mo ago

DoS attack is exactly what I describe an AI generated PR!!

basch 3mo ago

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.

marcosdumay 3mo ago
Do you volunteer to maintain the sloppy fork?
- endominus 3mo ago
  I think most pro-AI people would be happy to let an AI maintain the sloppy fork. What reason would they have to complain, after all?
TomasBM 3mo ago
This is actually a good idea. 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.
- basch 3mo ago
  Precisely. Cherrypick nuggets from poo. It's there if you care to wade into it. May occasionally strike gold.
overgard 3mo ago
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)

Bukhmanizer 3mo ago

I recently wrote a tool to help me read AI generated PRs and it’s pretty sad that it’s got to this point.