7 ms·

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

by 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.
- geraneum 1y ago
  > Nobody cares if contributors use an LLM or a magnetic needle to generate code. That’s exactly opposite of what the author is saying. He mentions that [if the code is not good, or you are a beginner] he will help you get to finish line, but if it’s LLM code, he shouldn’t be putting effort because there’s no human on the other side. It makes sense to me.
  - blurbleblurble 1y ago
    "but if it’s LLM code, he shouldn’t be putting effort because there’s no human on the other side" That's the false equivalence right there
    - tsimionescu 1y ago
      It's not a false equivalence. You can teach a beginner to become an intermediate (and later a master, if they stick to it). You can't teach an LLM to be better. Every piece of feedback you give to an LLM is like screaming into the void - it wastes your time, and doesn't change the LLM one iota.
      - blurbleblurble 1y ago
        "Every piece of feedback you give to an LLM is like screaming into the void - it wastes your time, and doesn't change the LLM one iota." I think you just haven't gotten the hang of it yet, which is fine... the tooling is very immature and hard to get consistent results with. But this isn't a given. Some people do get good, steerable LLM coding setups.
        sho_hn 1y ago
        Steering via prompting isn't the same as fundamentally changing the LLM by teaching, as you can do with humans. I think OP understands this better than you.
        blurbleblurble 1y ago
- eschaton 1y ago
  You’re completely incorrect. People care a lot about where code came from. They need to be able to trust that code you’re contributing was not copied from a project under AGPLv3, if the project you’re contributing to is under a different license. Stop trying to equate LLM-generated code with indexing-based autocomplete. They’re not the same thing at all: LLM-generated code is equivalent to code copied off Stack Overflow, which is also something you’d better not be attempting to fraudulently pass off as your own work.
  - koolba 1y ago
    I’m not equating any type of code generation. I’m saying that as a maintainer you have to evaluate any submission on the merits, not on a series of yes/no questions provided by the submitter. And your own judgement is influenced by what you know about the submitter.
    - eschaton 1y ago
      And I’m saying, as a maintainer, you have to and are doing both, even if you don’t think you are. For example, you either make your contributors attest that their changes are original or that they have the right to contribute their changes—or you assume this of them and consider it implicit in their submission. What you (probably) don’t do is welcome contributions that the contributors do not have the right to make.
  - fluidcruft 1y ago
    How does an "I didn't use AI" pledge provide any assurance/provenance that submitted code wasn't copied from an AGPLv3 reference?
    - eschaton 1y ago
      It doesn’t, it provides an assurance (but not provenance) you didn’t use AI. Assuring you didn’t include any AGPLv3 code in your contribution is exactly the same kind of assurance. It also doesn’t provide any provenance. Conflating assurance with provenance is bogus because the former is about making a representation that, if false, exposes the person making it to liability. For most situations that’s sufficient that provenance isn’t needed.
KritVutGu 1y ago
[flagged]
- ToucanLoucan 1y ago
  The sheer amount of entitlement on display by very pro-AI people genuinely boggles the mind.
  - mattgreenrocks 1y ago
    They genuinely believe their use of chatbots is equivalent to multiple years of production experience in a language. They want to erase that distinction (“democratize”) so they can have the same privileges and status without the work. Otherwise, what’s the harm in saying AI guides you to the solution if you can attest to it being a good solution?
    - ToucanLoucan 1y ago
      I guess it's just different kinds of people. I have used Copilot to generate code I barely understand (stuff for a microcontroller project, nothing important) but I wouldn't in a thousand years say I wrote it. I broadly understand how it works, and like, if someone wanted to see it, I'd show them. But like... how can you take pride in something you didn't make?
      - mattgreenrocks 1y ago
        Not making the thing is a point in favor of LLMs for some of these people I suspect. So the pride in work thing is just not high on the list of incentives. I don’t get it at all. Feels like modernity is often times just inventing pale shadows of things with more addictive hooks to induce needlessly dependent behavior.
        KritVutGu 1y ago
        > the pride in work thing is just not high on the list of incentives Thanks for putting it so well. That is what hurts. A lot. Taking pride out of work, especially creative work, makes the world a worse place; it makes life less worth living. > inventing pale shadows of things Yes.
otterley 1y ago
If it comes with good documentation and appropriate tests, does that help?
- mattbee 1y ago
  The observation that inspired this policy is that if you used AI, it is likely you don't know if the code, the documentation or tests are good or appropriate.
  - otterley 1y ago
    What if you started with good documentation that you personally wrote, you gave that to the agent, and you verified the tests were appropriate and passed?
    - mattbee 1y ago
      I'd extrapolate that the OP's view would be: you've still put in less effort, so your PR is less worthy of his attention than someone who'd done the same without using LLMs. That's a pretty nice offer from one of the most famous and accomplished free software maintainers in the world. He's promising not to take a short-cut reviewing your PR, in exchange for you not taking a short-cut writing it in the first place.
      - otterley 1y ago
        > in exchange for you not taking a short-cut writing it in the first place. This “short cut” language suggests that the quality of the submission is going to be objectively worse by way of its provenance. Yet, can one reliably distinguish working and tested code generated by a person vs a machine? We’re well past passing Turing tests at this point.
        mattbee 1y ago
        LLMs can't count letters, their writing is boring, and you can trick them into talking gibberish. That is a long way off the Turing test, even if we were fooled for a couple of weeks in 2022. IMO when people declare that LLMs "pass" at a particular skill, it's a sign that they don't have the taste or experience to judge that skill themselves. Or - when it's CEOs - they have an interest in devaluing it. So yes if you're trying to fool an experienced open source maintainer with unrefined LLM-generated code, good luck (especially one who's said he doesn't want that).
RossBencina 1y ago
> "Do I trust where this came from?" In an open source project I think you have to start with a baseline assumption of "trust nobody." Exceptions possibly if you know the contributors personally, or have built up trust over years of collaboration. I wouldn't reject or decline to review a PR just because I don't trust the contributor.
- nullc 1y ago
  Better to think in terms of distrust rather than trust. Presumably if a contributor repeatedly made bad PRs that didn't do what they said, introduced bugs, scribbled pointlessly on the codebase, and when you tried to coach or clarify at best they later forgot everything you said and at worst outright gaslit and lied to you about their PRs... you would reject or decline to review their PRs, right? You'd presumably ban the outright. Well that's exactly what commercial LLM products, with the aid of less sophisticated users, have already done to the maintainers of many large open source projects. It's not that they're not trusted-- they should be distrusted with ample cause. So what if the above banned contributor kept getting other people to mindlessly submit their work and even proxy communication through -- evading your well earned distrust and bans? Asking people to at least disclose that they were acting on behalf of the distrusted contributor would be the least you would do, I hope? Or even asking them to disclose if and to what extent their work was a collaboration with a distrusted contributor?

by cvoss 1y ago

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.
geraneum 1y ago
> Nobody cares if contributors use an LLM or a magnetic needle to generate code. That’s exactly opposite of what the author is saying. He mentions that [if the code is not good, or you are a beginner] he will help you get to finish line, but if it’s LLM code, he shouldn’t be putting effort because there’s no human on the other side. It makes sense to me.
- blurbleblurble 1y ago
  "but if it’s LLM code, he shouldn’t be putting effort because there’s no human on the other side" That's the false equivalence right there
  - tsimionescu 1y ago
    It's not a false equivalence. You can teach a beginner to become an intermediate (and later a master, if they stick to it). You can't teach an LLM to be better. Every piece of feedback you give to an LLM is like screaming into the void - it wastes your time, and doesn't change the LLM one iota.
    - blurbleblurble 1y ago
      "Every piece of feedback you give to an LLM is like screaming into the void - it wastes your time, and doesn't change the LLM one iota." I think you just haven't gotten the hang of it yet, which is fine... the tooling is very immature and hard to get consistent results with. But this isn't a given. Some people do get good, steerable LLM coding setups.
      - sho_hn 1y ago
        Steering via prompting isn't the same as fundamentally changing the LLM by teaching, as you can do with humans. I think OP understands this better than you.
        blurbleblurble 1y ago
eschaton 1y ago
You’re completely incorrect. People care a lot about where code came from. They need to be able to trust that code you’re contributing was not copied from a project under AGPLv3, if the project you’re contributing to is under a different license. Stop trying to equate LLM-generated code with indexing-based autocomplete. They’re not the same thing at all: LLM-generated code is equivalent to code copied off Stack Overflow, which is also something you’d better not be attempting to fraudulently pass off as your own work.
- koolba 1y ago
  I’m not equating any type of code generation. I’m saying that as a maintainer you have to evaluate any submission on the merits, not on a series of yes/no questions provided by the submitter. And your own judgement is influenced by what you know about the submitter.
  - eschaton 1y ago
    And I’m saying, as a maintainer, you have to and are doing both, even if you don’t think you are. For example, you either make your contributors attest that their changes are original or that they have the right to contribute their changes—or you assume this of them and consider it implicit in their submission. What you (probably) don’t do is welcome contributions that the contributors do not have the right to make.
- fluidcruft 1y ago
  How does an "I didn't use AI" pledge provide any assurance/provenance that submitted code wasn't copied from an AGPLv3 reference?
  - eschaton 1y ago
    It doesn’t, it provides an assurance (but not provenance) you didn’t use AI. Assuring you didn’t include any AGPLv3 code in your contribution is exactly the same kind of assurance. It also doesn’t provide any provenance. Conflating assurance with provenance is bogus because the former is about making a representation that, if false, exposes the person making it to liability. For most situations that’s sufficient that provenance isn’t needed.

KritVutGu 1y ago

[flagged]

ToucanLoucan 1y ago
The sheer amount of entitlement on display by very pro-AI people genuinely boggles the mind.
- mattgreenrocks 1y ago
  They genuinely believe their use of chatbots is equivalent to multiple years of production experience in a language. They want to erase that distinction (“democratize”) so they can have the same privileges and status without the work. Otherwise, what’s the harm in saying AI guides you to the solution if you can attest to it being a good solution?
  - ToucanLoucan 1y ago
    I guess it's just different kinds of people. I have used Copilot to generate code I barely understand (stuff for a microcontroller project, nothing important) but I wouldn't in a thousand years say I wrote it. I broadly understand how it works, and like, if someone wanted to see it, I'd show them. But like... how can you take pride in something you didn't make?
    - mattgreenrocks 1y ago
      Not making the thing is a point in favor of LLMs for some of these people I suspect. So the pride in work thing is just not high on the list of incentives. I don’t get it at all. Feels like modernity is often times just inventing pale shadows of things with more addictive hooks to induce needlessly dependent behavior.
      - KritVutGu 1y ago
        > the pride in work thing is just not high on the list of incentives Thanks for putting it so well. That is what hurts. A lot. Taking pride out of work, especially creative work, makes the world a worse place; it makes life less worth living. > inventing pale shadows of things Yes.

otterley 1y ago

If it comes with good documentation and appropriate tests, does that help?

mattbee 1y ago
The observation that inspired this policy is that if you used AI, it is likely you don't know if the code, the documentation or tests are good or appropriate.
- otterley 1y ago
  What if you started with good documentation that you personally wrote, you gave that to the agent, and you verified the tests were appropriate and passed?
  - mattbee 1y ago
    I'd extrapolate that the OP's view would be: you've still put in less effort, so your PR is less worthy of his attention than someone who'd done the same without using LLMs. That's a pretty nice offer from one of the most famous and accomplished free software maintainers in the world. He's promising not to take a short-cut reviewing your PR, in exchange for you not taking a short-cut writing it in the first place.
    - otterley 1y ago
      > in exchange for you not taking a short-cut writing it in the first place. This “short cut” language suggests that the quality of the submission is going to be objectively worse by way of its provenance. Yet, can one reliably distinguish working and tested code generated by a person vs a machine? We’re well past passing Turing tests at this point.
      - mattbee 1y ago
        LLMs can't count letters, their writing is boring, and you can trick them into talking gibberish. That is a long way off the Turing test, even if we were fooled for a couple of weeks in 2022. IMO when people declare that LLMs "pass" at a particular skill, it's a sign that they don't have the taste or experience to judge that skill themselves. Or - when it's CEOs - they have an interest in devaluing it. So yes if you're trying to fool an experienced open source maintainer with unrefined LLM-generated code, good luck (especially one who's said he doesn't want that).

RossBencina 1y ago

> "Do I trust where this came from?" In an open source project I think you have to start with a baseline assumption of "trust nobody." Exceptions possibly if you know the contributors personally, or have built up trust over years of collaboration. I wouldn't reject or decline to review a PR just because I don't trust the contributor.

nullc 1y ago
Better to think in terms of distrust rather than trust. Presumably if a contributor repeatedly made bad PRs that didn't do what they said, introduced bugs, scribbled pointlessly on the codebase, and when you tried to coach or clarify at best they later forgot everything you said and at worst outright gaslit and lied to you about their PRs... you would reject or decline to review their PRs, right? You'd presumably ban the outright. Well that's exactly what commercial LLM products, with the aid of less sophisticated users, have already done to the maintainers of many large open source projects. It's not that they're not trusted-- they should be distrusted with ample cause. So what if the above banned contributor kept getting other people to mindlessly submit their work and even proxy communication through -- evading your well earned distrust and bans? Asking people to at least disclose that they were acting on behalf of the distrusted contributor would be the least you would do, I hope? Or even asking them to disclose if and to what extent their work was a collaboration with a distrusted contributor?