8 ms·

I’m not a big AI fan but I do see it as just another tool in your toolbox. I wouldn’t really care how someone got to the end result that is a PR. But I also th

I’m not a big AI fan but I do see it as just another tool in your toolbox. I wouldn’t really care how someone got to the end result that is a PR. But I also think that if a maintainer asks you to jump before submitting a PR, you politely ask, “how high?”

quotemstr 1y ago
As a project maintainer, you shouldn't make rules unenforceable rules that you and everyone else know people will flout. Doing so comes makes you seem impotent and diminishes the respect people have for rules in general. You might argue that by making rules, even futile ones, you at least establish expectations and take a moral stance. Well, you can make a statement without dressing it up as a rule. But you don't get to be sanctimonious that way I guess.
- voxl 1y ago
  Except you can enforce this rule some of the time. People discover that AI was used or suspect it all the time, and people admit to it after some pressure all the time. Not every time, but sometimes. The threat of being caught isn't meaningless. You can decide not to play in someone else's walled garden if you want but the least you can do is respect their rules, bare minimum of human decency.
  - quotemstr 1y ago
    It. doesn't. matter. The only legitimate reason to make a rule is to produce some outcome. If your rule does not result in that outcome, of what use is the rule? Will this rule result in people disclosing "AI" (whatever that means) contributions? Will it mitigate some kind of risk to the project? Will it lighten maintainer load? No. It can't. People are going to use the tools anyway. You can't tell. You can't stop them. The only outcome you'll get out of a rule like this is making people incrementally less honest.
    - recursive 1y ago
      Sometimes you can tell.
    - blaufuchs 1y ago
      > Will it lighten maintainer load? Yes that is the stated purpose, did you read the linked GitHub comment? The author lays out their points pretty well, you sound unreasonably upset about this. Are you submitting a lot of AI slop PRs or something? P.S Talking. Like. This. Is. Really. Ineffective. It. Makes. Me. Just. Want. To. Disregard. Your. Point. Out. Of. Hand.
    - devmor 1y ago
      There are plenty of argumentative and opinionated reasons to say it matters, but there is one that can't really be denied - reviewers (and project maintainers, even if they aren't reviewers) are people whose time deserves to be respected. If this rule discourages low quality PRs or allows reviewers to save time by prioritizing some non-AI-generated PRs, then it certainly seems useful in my opinion.
    - thunderfork 1y ago
      [dead]
    - nullc 1y ago
      The utility of the rule is so that you can cheaply nuke non-conforming contributors from orbit when you detect their undisclosed AI use. Vs having to deal with the flood of low quality contributions on a individually reviewed basis.
    - eschaton 1y ago
      You’re basically saying “if a rule can be broken, it will be, therefore rules are useless.” If someone really wants to commit fraud they’re going to commit fraud. (For example, by not disclosing AI use when a repository requires it.) But if their fraud is discovered, they can still be punished for it, and mitigating actions taken. That’s not nothing, and does actually do a lot to prevent people from engaging in such fraud in the first place.
  - pixl97 1y ago
    Except the other way happens too. You get someone that didn't use AI getting accused of using AI and eventually telling people to screw off and contributing nothing.
    - nullc 1y ago
      If their work was difficult to distinguish from AI then that sounds like a win too.
- natrius 1y ago
  Unenforceable rules are bad, but if you tweak the rule to always require some sort of authorship statement (e.g. "I wrote this by hand" or "I wrote this with Claude"), then the honor system will mostly achieve the desired goal of calibrating code review effort.
- KritVutGu 1y ago
  > As a project maintainer, you shouldn't make rules unenforceable rules Total bullshit. It's totally fine to declare intent. You are already incapable of verifying / enforcing that a contributor is legally permitted to submit a piece of code as their own creation (Signed-off-by), and do so under the project's license. You won't embark on looking for prior art, for the "actual origin" of the code, whatever. You just make them promise, and then take their word for it.
  - eschaton 1y ago
    And if they’re discovered to not be keeping their word, there can be consequences imposed and mitigating actions taken. Rules can’t prevent bad actions 100% of the time, but they can substantially increase the risk of bad actions.
wahnfrieden 1y ago
You should care. If someone submits a huge PR, you’re going to waste time asking questions and comprehending their intentions if the answer is that they don’t know either. If you know it’s generated and they haven’t reviewed it themselves, you can decide to shove it back into an LLM for next steps rather than expect the contributor to be able to do anything with your review feedback. Unreviewed generated PRs can still be helpful starting points for further LLM work if they achieve desired results. But close reading with consideration of authorial intent, giving detailed comments, and asking questions from someone who didn't write or read the code is a waste of your time. That's why we need to know if a contribution was generated or not.
- KritVutGu 1y ago
  You are absolutely right. AI is just a tool to DDoS maintainers. Any contributor who was shown to post provably untested patches used to lose credibility. And now we're talking about accommodating people who don't even understand how the patch is supposed to work?
  - wahnfrieden 1y ago
    That’s not what I said though. LLM output, even unreviewed and without understanding, can be a useful artifact. I do it all the time - generate code, try running it, and then if I see it works well, I can decide to review it and follow up with necessary refactoring before integrating it. Parts of that can be contributed too. We’re just learning new etiquettes for doing that productively, and that does includes testing the PR btw (even if the code itself is not understood or reviewed). Example where this kind of contribution was accepted and valuable, inside this ghostty project https://x.com/mitchellh/status/1957930725996654718 https://x.com/mitchellh/status/1957930725996654718
    - nullc 1y ago
      If the AI slop was that valuable a project regular, who actually knows and understands the project, would be just as capable of asking the AI to produce it.
cvoss 1y ago
It does matter how and where a PR comes from, because reviewers are fallible and finite, so trust enters the equation inevitably. You must ask "Do I trust where this came from?" And to answer that, you need to know where it come from. If trust didn't matter, there wouldn't have been a need for the Linux Kernel team to ban the University of Minnesota for attempting to intentionally smuggle bugs through the PR process as part of an unauthorized social experiment. As it stands, if you / your PRs can't be trusted, they should not even be admitted to the review process.
- koolba 1y ago
  > You must ask "Do I trust where this came from?" And to answer that, you need to know where it come from. No you don’t. You can’t outsource trust determinations. Especially to the people you claim not to trust! You make the judgement call by looking at the code and your known history of the contributor. Nobody cares if contributors use an LLM or a magnetic needle to generate code. They care if bad code gets introduced or bad patches waste reviewers’ time.
  - falcor84 1y ago
    Trust is absolutely a thing. Maintaining an open source project is an unreasonably demanding and thankless job, and it would be even more so if you had to treat every single PR as if it's a high likelihood supply-chain attack.
    - fnimick 1y ago
      While true, we really should be treating every single piece of external code as though it's malicious.
      - tsimionescu 1y ago
        No, we shouldn't. We live in a society, and that level of distrust is not just unrealistic, it's disastrous. This doesn't mean you should share your house keys with every drive by PR contributor, but neither should you treat every PR as if it's coming from Jia Tan.
renrutal 1y ago
I won't put it as "just another tool". AI introduces a new kind of tool where the ownership of the resulting code is not straightforward. If, in the dystopian future, a justice court you're subjected to decides that Claude was trained on Oracle's code, and all Claude users are possibly in breach of copyright, it's easier to nuke from orbit all disclosed AI contributions.
raincole 1y ago
When one side has much more "scalability" than the other, then the other side has very strong motivation to match up. - People use AI to write cover letters. If the companies don't filter out them automatically, they're screwed. - Companies use AI to interview candidates. No one wants to spend their personal time talking to a robot. So the candidates start using AI to take interviews for them. etc. If you don't at least tell yourself that you don't allow AI PRs (even just as a white lie) you'll one day use AI to review PRs.
- oceanplexian 1y ago
  Both sides will use AI and it will ultimately increase economic productivity. Imagine living before the invention of the printing press, and then lamenting that we should ban them because it makes it "too easy" to distribute information and will enable "low quality" publications to have more reach. Actually, this exact thing happened, but the end result was it massively disrupted the world and economy in extremely positive ways.
  - bootsmann 1y ago
    > Both sides will use AI and it will ultimately increase economic productivity. Citation needed, I don’t think the printing press and gpt are in any way comparable.
    - blurbleblurble 1y ago
      GPT and compilers are though.
      - bootsmann 1y ago
        Compilers don’t randomly fail to compile code that is too difficult for them to understand. Llvm makes sure that I never have to learn assembly, gpt doesn’t guarantee at all that I don’t have to learn to code.
    - alfalfasprout 1y ago
nosignono 1y ago
> I wouldn’t really care how someone got to the end result that is a PR. I can generate 1,000 PRs today against an open source project using AI. I think you do care, you are only thinking about the happy path where someone uses a little AI to draft a well constructed PR. There's a lot ways AI can be used to quickly overwhelm a project maintainer.
- Waterluvian 1y ago
  In that case a more correct rule (and probably one that can be automatically enforced) for that issue is a max number of PRs or opened issues per account.
  - RossBencina 1y ago
    I think this is sane, although possibly not sufficient. Asking people to self-disclose AI usage is not going shield maintainers from a flood of undisclosed AI submissions.
- oceanplexian 1y ago
  > I can generate 1,000 PRs today against an open source project using AI. Then perhaps the way you contribute, review, and accept code is fundamentally wrong and needs to change with the times. It may be that technologies like Github PRs and other VCS patterns are literally obsolete. We've done this before throughout many cycles of technology, and these are the questions we need to ask ourselves as engineers, not stick our heads in the sand and pretend it's 2019.
  - whatevertrevor 1y ago
    I don't think throwing out the concept of code reviews and version control is the correct response to a purported rise in low-effort high-volume patches. If anything it's even more required.
    - oblio 1y ago
      Heck, let's throw out QA, too :-))
Razengan 1y ago
> if a maintainer asks you to jump before submitting a PR, you politely ask, “how high?” or say "fork you."
dsjoerg 1y ago
You haven't addressed the primary stated rationale from the linked content: "I try to assist inexperienced contributors and coach them to the finish line, because getting a PR accepted is an achievement to be proud of. But if it's just an AI on the other side, I don't need to put in this effort, and it's rude to trick me into doing so."
alfalfasprout 1y ago
The reality is as someone that helps maintain several OSS projects you vastly underestimate the problem that AI-assisted tooling has created. On the one hand, it's lowered the barrier to entry for certain types of contributions. But on the other hand getting a vibe-coded 1k LOC diff from someone that has absolutely no idea how the project even works is a serious problem because the iteration cycle of getting feedback + correctly implementing it is far worse in this case. Also, the types of errors introduced tend to be quite different between humans and AI tools. It's a small ask but a useful one to disclose how AI was used.
armchairhacker 1y ago
Agreed. As someone who uses AI (completion and Claude Code), I'll disclose whenever asked. But I disagree that it's "common courtesy" when not explicitly asked; since many people (including myself) don't mind and probably assume some AI, and it adds distraction (another useless small indicator; vaguely like dependabot, in that it steals my attention but ultimately I don't care).
- eschaton 1y ago
  It’s not just common courtesy to disclose, it’s outright fraud not to disclose.
  - Aeolun 1y ago
    That's nonsense. It's like feeling you need to disclose that your IDE has autocomplete. Nobody discloses that, since it's ridiculous. You only disclose that you used Claude Code if you are not certain of the result (e.g. you think it is correct, but the maintainer might be a better judge). If it's exactly the same as what you'd have written manually, and you are confident it works, then what's the point of disclosure?
    - eschaton 1y ago
      It’s completely different from an IDE’s autocomplete because autocomplete in an IDE is only helping you type identifiers that already exist in your codebase or in any SDKs you’re using. An LLM is regurgitating things from outside that space, where you have no idea of the provenance of what it’s putting into your code. It doesn’t just matter that the code you’re contributing to a project is correct, it matters quite a lot if it’s actually something you’re allowed to contribute. - You can’t contribute code that your employer owns to a project if they don’t want you to. - You can’t contribute code under a license that the project doesn’t want you to use. - And you can’t contribute code written by someone else and claim it’s your intellectual property without some sort of contract in place to grant that. If you use an LLM to generate code that you’re contributing, you have both of the latter two problems. And all of those apply *even if* the code you’re contributing is identical to what you’d have written by hand off the top of your head. When you contribute to a project, you’re not just sending that project a set of bits, you’re making attestations about how those bits were created. Why does this seem so difficult for some supposed tech professionals to understand? The entire industry is intellectual property, and this is basic “IP 101” stuff.
bagels 1y ago
You have other choices, such as not contributing.
sheepscreek 1y ago
We keep talking about “AI replacing coders,” but the real shift might be that coding itself stops looking like coding. If prompts become the de facto way to create applications/developing systems in the future, maybe programming languages will just be baggage we’ll need to unlearn. Programming languages were a nice abstraction to accommodate our inability to comprehend complexity - current day LLMs do not have the same limitations as us. The uncomfortable part will be what happens to PRs and other human-in-the-loop checks. It’s worthwhile to consider that not too far into the future, we might not be debugging code anymore - we’ll be debugging the AI itself. That’s a whole different problem space that will need an entirely new class of solutions and tools.
- ryoshu 1y ago
  All we need to do is prompt an LLM with such specificity that it does exactly what we want the machine to do.
  - kentm 1y ago
    Good idea! We can have some sort of standard grammar that we use to prompt the LLM such that it deterministically gives us the result we ask for. We then constrain all prompts to match that grammar. Some sort of language describing programs.
- tsimionescu 1y ago
  This fundamentally misunderstands why programming languages exist. They're not required because "we can't understand complexity". They were invented because we need a way to be very specific about what we want the machine to do. Whether it's the actual physical hardware we're talking to when writing assembly, or it's an abstract machine that will be translated to the hardware like in C or Java, the key point is that we want to be specific. Natural language can be specific, but it requires far too many words. `map (+ 1) xs` is far shorter to write than "return a list of elements by applying a function that adds one to its argument to each element of xs and collecting the results in a separate list", or similar.
  - 1y ago
EarlKing 1y ago
It's not just about how you got there. At least in the United States according to the Copyright Office... materials produced by artificial intelligence are not eligible for copyright. So, yeah, some people want to know for licensing purposes. I don't think that's the case here, but it is yet another reason to require that kind of disclosure... since if you fail to mention that something was made by AI as part of a compound work you could end up losing copyright over the whole thing. For more details, see [2] (which is part of the larger report on Copyright and AI at [1]). -- [1] https://www.copyright.gov/ai/ https://www.copyright.gov/ai/ [2] https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf https://www.copyright.gov/ai/Copyright-and-Artificial-Intell...
- ants_everywhere 1y ago
  > • The use of AI tools to assist rather than stand in for human creativity does not affect the availability of copyright protection for the output. > • Copyright protects the original expression in a work created by a human author, even if the work also includes AI-generated material > • Human authors are entitled to copyright in their works of authorship that are perceptible in AI-generated outputs, as well as the creative selection, coordination, or arrangement of material in the outputs, or creative modifications of the outputs.
  - EarlKing 1y ago
    Original expression, yes, however you should've kept reading: "In the Office’s view, it is well-established that copyright can protect only material that is the product of human creativity. Most fundamentally, the term “author,” which is used in both the Constitution and the Copyright Act, excludes non-humans." "In the case of works containing AI-generated material, the Office will consider whether the AI contributions are the result of “mechanical reproduction” or instead of an author’s “own original mental conception, to which [the author] gave visible form.” 24 The answer will depend on the circumstances, particularly how the AI tool operates and how it was used to create the final work.25 This is necessarily a case-by-case inquiry." "If a work’s traditional elements of authorship were produced by a machine, the work lacks human authorship and the Office will not register it." The office has been quite consistent that works containing both human-made and AI-made elements will be registerable only to the extent that they contain human-made elements.
varelse 1y ago
[dead]
tgsovlerkhgsel 1y ago
If a maintainer asks me to jump through too many stupid hoops, I'll just not contribute to the software. That said, requiring adequate disclosure of AI is just fair. It also suggests that the other side is willing to accept AI-supported contributions (without being willing to review endless AI slop that they could have generated themselves if they had the time to read it). I would expect such a maintainer to respond fairly to "I first vibecoded it. I then made manual changes, vibecoded a test, cursorily reviewed the code, checked that the tests provide good coverage, ran both existing and new tests, and manually tested the code." That fair response might be a thorough review, or a request that I do the thorough review before they put in the time, but I'd expect it to be more than a blatant "nope, AI touched this, go away".
bandrami 1y ago
Whether the output of AI can be copyrighted remains a legal minefield, so if I were running a project where copyright-based protections are important (say, anything GPL) I would want to know if a PR contained them.

quotemstr 1y ago

As a project maintainer, you shouldn't make rules unenforceable rules that you and everyone else know people will flout. Doing so comes makes you seem impotent and diminishes the respect people have for rules in general. You might argue that by making rules, even futile ones, you at least establish expectations and take a moral stance. Well, you can make a statement without dressing it up as a rule. But you don't get to be sanctimonious that way I guess.

voxl 1y ago
Except you can enforce this rule some of the time. People discover that AI was used or suspect it all the time, and people admit to it after some pressure all the time. Not every time, but sometimes. The threat of being caught isn't meaningless. You can decide not to play in someone else's walled garden if you want but the least you can do is respect their rules, bare minimum of human decency.
- quotemstr 1y ago
  It. doesn't. matter. The only legitimate reason to make a rule is to produce some outcome. If your rule does not result in that outcome, of what use is the rule? Will this rule result in people disclosing "AI" (whatever that means) contributions? Will it mitigate some kind of risk to the project? Will it lighten maintainer load? No. It can't. People are going to use the tools anyway. You can't tell. You can't stop them. The only outcome you'll get out of a rule like this is making people incrementally less honest.
  - recursive 1y ago
    Sometimes you can tell.
  - blaufuchs 1y ago
    > Will it lighten maintainer load? Yes that is the stated purpose, did you read the linked GitHub comment? The author lays out their points pretty well, you sound unreasonably upset about this. Are you submitting a lot of AI slop PRs or something? P.S Talking. Like. This. Is. Really. Ineffective. It. Makes. Me. Just. Want. To. Disregard. Your. Point. Out. Of. Hand.
  - devmor 1y ago
    There are plenty of argumentative and opinionated reasons to say it matters, but there is one that can't really be denied - reviewers (and project maintainers, even if they aren't reviewers) are people whose time deserves to be respected. If this rule discourages low quality PRs or allows reviewers to save time by prioritizing some non-AI-generated PRs, then it certainly seems useful in my opinion.
  - thunderfork 1y ago
    [dead]
  - nullc 1y ago
    The utility of the rule is so that you can cheaply nuke non-conforming contributors from orbit when you detect their undisclosed AI use. Vs having to deal with the flood of low quality contributions on a individually reviewed basis.
  - eschaton 1y ago
    You’re basically saying “if a rule can be broken, it will be, therefore rules are useless.” If someone really wants to commit fraud they’re going to commit fraud. (For example, by not disclosing AI use when a repository requires it.) But if their fraud is discovered, they can still be punished for it, and mitigating actions taken. That’s not nothing, and does actually do a lot to prevent people from engaging in such fraud in the first place.
- pixl97 1y ago
  Except the other way happens too. You get someone that didn't use AI getting accused of using AI and eventually telling people to screw off and contributing nothing.
  - nullc 1y ago
    If their work was difficult to distinguish from AI then that sounds like a win too.
natrius 1y ago
Unenforceable rules are bad, but if you tweak the rule to always require some sort of authorship statement (e.g. "I wrote this by hand" or "I wrote this with Claude"), then the honor system will mostly achieve the desired goal of calibrating code review effort.
KritVutGu 1y ago
> As a project maintainer, you shouldn't make rules unenforceable rules Total bullshit. It's totally fine to declare intent. You are already incapable of verifying / enforcing that a contributor is legally permitted to submit a piece of code as their own creation (Signed-off-by), and do so under the project's license. You won't embark on looking for prior art, for the "actual origin" of the code, whatever. You just make them promise, and then take their word for it.
- eschaton 1y ago
  And if they’re discovered to not be keeping their word, there can be consequences imposed and mitigating actions taken. Rules can’t prevent bad actions 100% of the time, but they can substantially increase the risk of bad actions.

wahnfrieden 1y ago

You should care. If someone submits a huge PR, you’re going to waste time asking questions and comprehending their intentions if the answer is that they don’t know either. If you know it’s generated and they haven’t reviewed it themselves, you can decide to shove it back into an LLM for next steps rather than expect the contributor to be able to do anything with your review feedback. Unreviewed generated PRs can still be helpful starting points for further LLM work if they achieve desired results. But close reading with consideration of authorial intent, giving detailed comments, and asking questions from someone who didn't write or read the code is a waste of your time. That's why we need to know if a contribution was generated or not.

KritVutGu 1y ago
You are absolutely right. AI is just a tool to DDoS maintainers. Any contributor who was shown to post provably untested patches used to lose credibility. And now we're talking about accommodating people who don't even understand how the patch is supposed to work?
- wahnfrieden 1y ago
  That’s not what I said though. LLM output, even unreviewed and without understanding, can be a useful artifact. I do it all the time - generate code, try running it, and then if I see it works well, I can decide to review it and follow up with necessary refactoring before integrating it. Parts of that can be contributed too. We’re just learning new etiquettes for doing that productively, and that does includes testing the PR btw (even if the code itself is not understood or reviewed). Example where this kind of contribution was accepted and valuable, inside this ghostty project https://x.com/mitchellh/status/1957930725996654718 https://x.com/mitchellh/status/1957930725996654718
  - nullc 1y ago
    If the AI slop was that valuable a project regular, who actually knows and understands the project, would be just as capable of asking the AI to produce it.

cvoss 1y ago

It does matter how and where a PR comes from, because reviewers are fallible and finite, so trust enters the equation inevitably. You must ask "Do I trust where this came from?" And to answer that, you need to know where it come from. If trust didn't matter, there wouldn't have been a need for the Linux Kernel team to ban the University of Minnesota for attempting to intentionally smuggle bugs through the PR process as part of an unauthorized social experiment. As it stands, if you / your PRs can't be trusted, they should not even be admitted to the review process.

koolba 1y ago
> You must ask "Do I trust where this came from?" And to answer that, you need to know where it come from. No you don’t. You can’t outsource trust determinations. Especially to the people you claim not to trust! You make the judgement call by looking at the code and your known history of the contributor. Nobody cares if contributors use an LLM or a magnetic needle to generate code. They care if bad code gets introduced or bad patches waste reviewers’ time.
- falcor84 1y ago
  Trust is absolutely a thing. Maintaining an open source project is an unreasonably demanding and thankless job, and it would be even more so if you had to treat every single PR as if it's a high likelihood supply-chain attack.
  - fnimick 1y ago
    While true, we really should be treating every single piece of external code as though it's malicious.
    - tsimionescu 1y ago
      No, we shouldn't. We live in a society, and that level of distrust is not just unrealistic, it's disastrous. This doesn't mean you should share your house keys with every drive by PR contributor, but neither should you treat every PR as if it's coming from Jia Tan.

renrutal 1y ago

I won't put it as "just another tool". AI introduces a new kind of tool where the ownership of the resulting code is not straightforward. If, in the dystopian future, a justice court you're subjected to decides that Claude was trained on Oracle's code, and all Claude users are possibly in breach of copyright, it's easier to nuke from orbit all disclosed AI contributions.

raincole 1y ago

When one side has much more "scalability" than the other, then the other side has very strong motivation to match up. - People use AI to write cover letters. If the companies don't filter out them automatically, they're screwed. - Companies use AI to interview candidates. No one wants to spend their personal time talking to a robot. So the candidates start using AI to take interviews for them. etc. If you don't at least tell yourself that you don't allow AI PRs (even just as a white lie) you'll one day use AI to review PRs.

oceanplexian 1y ago
Both sides will use AI and it will ultimately increase economic productivity. Imagine living before the invention of the printing press, and then lamenting that we should ban them because it makes it "too easy" to distribute information and will enable "low quality" publications to have more reach. Actually, this exact thing happened, but the end result was it massively disrupted the world and economy in extremely positive ways.
- bootsmann 1y ago
  > Both sides will use AI and it will ultimately increase economic productivity. Citation needed, I don’t think the printing press and gpt are in any way comparable.
  - blurbleblurble 1y ago
    GPT and compilers are though.
    - bootsmann 1y ago
      Compilers don’t randomly fail to compile code that is too difficult for them to understand. Llvm makes sure that I never have to learn assembly, gpt doesn’t guarantee at all that I don’t have to learn to code.
  - alfalfasprout 1y ago

nosignono 1y ago

> I wouldn’t really care how someone got to the end result that is a PR. I can generate 1,000 PRs today against an open source project using AI. I think you do care, you are only thinking about the happy path where someone uses a little AI to draft a well constructed PR. There's a lot ways AI can be used to quickly overwhelm a project maintainer.

Waterluvian 1y ago
In that case a more correct rule (and probably one that can be automatically enforced) for that issue is a max number of PRs or opened issues per account.
- RossBencina 1y ago
  I think this is sane, although possibly not sufficient. Asking people to self-disclose AI usage is not going shield maintainers from a flood of undisclosed AI submissions.
oceanplexian 1y ago
> I can generate 1,000 PRs today against an open source project using AI. Then perhaps the way you contribute, review, and accept code is fundamentally wrong and needs to change with the times. It may be that technologies like Github PRs and other VCS patterns are literally obsolete. We've done this before throughout many cycles of technology, and these are the questions we need to ask ourselves as engineers, not stick our heads in the sand and pretend it's 2019.
- whatevertrevor 1y ago
  I don't think throwing out the concept of code reviews and version control is the correct response to a purported rise in low-effort high-volume patches. If anything it's even more required.
  - oblio 1y ago
    Heck, let's throw out QA, too :-))

Razengan 1y ago

> if a maintainer asks you to jump before submitting a PR, you politely ask, “how high?” or say "fork you."

dsjoerg 1y ago

You haven't addressed the primary stated rationale from the linked content: "I try to assist inexperienced contributors and coach them to the finish line, because getting a PR accepted is an achievement to be proud of. But if it's just an AI on the other side, I don't need to put in this effort, and it's rude to trick me into doing so."

alfalfasprout 1y ago

The reality is as someone that helps maintain several OSS projects you vastly underestimate the problem that AI-assisted tooling has created. On the one hand, it's lowered the barrier to entry for certain types of contributions. But on the other hand getting a vibe-coded 1k LOC diff from someone that has absolutely no idea how the project even works is a serious problem because the iteration cycle of getting feedback + correctly implementing it is far worse in this case. Also, the types of errors introduced tend to be quite different between humans and AI tools. It's a small ask but a useful one to disclose how AI was used.

armchairhacker 1y ago

Agreed. As someone who uses AI (completion and Claude Code), I'll disclose whenever asked. But I disagree that it's "common courtesy" when not explicitly asked; since many people (including myself) don't mind and probably assume some AI, and it adds distraction (another useless small indicator; vaguely like dependabot, in that it steals my attention but ultimately I don't care).

eschaton 1y ago
It’s not just common courtesy to disclose, it’s outright fraud not to disclose.
- Aeolun 1y ago
  That's nonsense. It's like feeling you need to disclose that your IDE has autocomplete. Nobody discloses that, since it's ridiculous. You only disclose that you used Claude Code if you are not certain of the result (e.g. you think it is correct, but the maintainer might be a better judge). If it's exactly the same as what you'd have written manually, and you are confident it works, then what's the point of disclosure?
  - eschaton 1y ago
    It’s completely different from an IDE’s autocomplete because autocomplete in an IDE is only helping you type identifiers that already exist in your codebase or in any SDKs you’re using. An LLM is regurgitating things from outside that space, where you have no idea of the provenance of what it’s putting into your code. It doesn’t just matter that the code you’re contributing to a project is correct, it matters quite a lot if it’s actually something you’re allowed to contribute. - You can’t contribute code that your employer owns to a project if they don’t want you to. - You can’t contribute code under a license that the project doesn’t want you to use. - And you can’t contribute code written by someone else and claim it’s your intellectual property without some sort of contract in place to grant that. If you use an LLM to generate code that you’re contributing, you have both of the latter two problems. And all of those apply *even if* the code you’re contributing is identical to what you’d have written by hand off the top of your head. When you contribute to a project, you’re not just sending that project a set of bits, you’re making attestations about how those bits were created. Why does this seem so difficult for some supposed tech professionals to understand? The entire industry is intellectual property, and this is basic “IP 101” stuff.

bagels 1y ago

You have other choices, such as not contributing.

sheepscreek 1y ago

We keep talking about “AI replacing coders,” but the real shift might be that coding itself stops looking like coding. If prompts become the de facto way to create applications/developing systems in the future, maybe programming languages will just be baggage we’ll need to unlearn. Programming languages were a nice abstraction to accommodate our inability to comprehend complexity - current day LLMs do not have the same limitations as us. The uncomfortable part will be what happens to PRs and other human-in-the-loop checks. It’s worthwhile to consider that not too far into the future, we might not be debugging code anymore - we’ll be debugging the AI itself. That’s a whole different problem space that will need an entirely new class of solutions and tools.

ryoshu 1y ago
All we need to do is prompt an LLM with such specificity that it does exactly what we want the machine to do.
- kentm 1y ago
  Good idea! We can have some sort of standard grammar that we use to prompt the LLM such that it deterministically gives us the result we ask for. We then constrain all prompts to match that grammar. Some sort of language describing programs.
tsimionescu 1y ago
This fundamentally misunderstands why programming languages exist. They're not required because "we can't understand complexity". They were invented because we need a way to be very specific about what we want the machine to do. Whether it's the actual physical hardware we're talking to when writing assembly, or it's an abstract machine that will be translated to the hardware like in C or Java, the key point is that we want to be specific. Natural language can be specific, but it requires far too many words. `map (+ 1) xs` is far shorter to write than "return a list of elements by applying a function that adds one to its argument to each element of xs and collecting the results in a separate list", or similar.
- 1y ago

EarlKing 1y ago

It's not just about how you got there. At least in the United States according to the Copyright Office... materials produced by artificial intelligence are not eligible for copyright. So, yeah, some people want to know for licensing purposes. I don't think that's the case here, but it is yet another reason to require that kind of disclosure... since if you fail to mention that something was made by AI as part of a compound work you could end up losing copyright over the whole thing. For more details, see [2] (which is part of the larger report on Copyright and AI at [1]). -- [1] https://www.copyright.gov/ai/ https://www.copyright.gov/ai/ [2] https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf https://www.copyright.gov/ai/Copyright-and-Artificial-Intell...

ants_everywhere 1y ago
> • The use of AI tools to assist rather than stand in for human creativity does not affect the availability of copyright protection for the output. > • Copyright protects the original expression in a work created by a human author, even if the work also includes AI-generated material > • Human authors are entitled to copyright in their works of authorship that are perceptible in AI-generated outputs, as well as the creative selection, coordination, or arrangement of material in the outputs, or creative modifications of the outputs.
- EarlKing 1y ago
  Original expression, yes, however you should've kept reading: "In the Office’s view, it is well-established that copyright can protect only material that is the product of human creativity. Most fundamentally, the term “author,” which is used in both the Constitution and the Copyright Act, excludes non-humans." "In the case of works containing AI-generated material, the Office will consider whether the AI contributions are the result of “mechanical reproduction” or instead of an author’s “own original mental conception, to which [the author] gave visible form.” 24 The answer will depend on the circumstances, particularly how the AI tool operates and how it was used to create the final work.25 This is necessarily a case-by-case inquiry." "If a work’s traditional elements of authorship were produced by a machine, the work lacks human authorship and the Office will not register it." The office has been quite consistent that works containing both human-made and AI-made elements will be registerable only to the extent that they contain human-made elements.

varelse 1y ago

[dead]

tgsovlerkhgsel 1y ago

If a maintainer asks me to jump through too many stupid hoops, I'll just not contribute to the software. That said, requiring adequate disclosure of AI is just fair. It also suggests that the other side is willing to accept AI-supported contributions (without being willing to review endless AI slop that they could have generated themselves if they had the time to read it). I would expect such a maintainer to respond fairly to "I first vibecoded it. I then made manual changes, vibecoded a test, cursorily reviewed the code, checked that the tests provide good coverage, ran both existing and new tests, and manually tested the code." That fair response might be a thorough review, or a request that I do the thorough review before they put in the time, but I'd expect it to be more than a blatant "nope, AI touched this, go away".

bandrami 1y ago

Whether the output of AI can be copyrighted remains a legal minefield, so if I were running a project where copyright-based protections are important (say, anything GPL) I would want to know if a PR contained them.