3 ms·

Why don't evaluate contributions based on how well the code/documentation is written? What does it matter who wrote it, if it's good? Assuming no spamming by bo

Why don't evaluate contributions based on how well the code/documentation is written? What does it matter who wrote it, if it's good? Assuming no spamming by bots.

somenameforme 3y ago
Same reason LLMs aren't so great for regular usage. They do an excellent job of creating highly plausible looking nonsense, which makes it much more likely for things to slip through the cracks. If there was some sort of magical way to ensure code being submitted was flawless, then we'd no longer have bugs in anything, let alone the endless critical flaws that appear in pretty much everything. For a large highly visible open source project, there's also probably intellectual property concerns. LLMs are being trained wholesale on code that's under IP protections (be that copyright or otherwise) and having that end up in your code base could land you in trouble. 'The AI did it' will probably not be seen as a viable defense.
- rubymamis 3y ago
  Current LLMs. While I agree, they sometimes create more problems than solving (I'm currently debugging a bug caused by GPT4 code that I initially approved), they are getting better by the day and already 1.5x my productivity.
  - passwordoops 3y ago
    That's an oddly specific, very round number. You have metrics for it, or is this the same math being used to declare AGI is a year away?
    - rubymamis 3y ago
      No scientific at all, but I keep a long to-do list for my current project with dates, and it *feels* like LLMs have allowed me to cut a third of development time.
      - passwordoops 3y ago
        If you still have the record of previous projects (with similar tasks, of course) it would be really cool to see the before/after. And if you don't, and therefore cannot quantify, then for future reference simply state "it feels like the LLM makes me more efficient"
        rubymamis 3y ago
        I could have worded it a bit better - I don't have the before and after since I've been using ChatGPT Pro for the past year, yet only started my new project[1] 7 months ago. What I meant is: by keeping track of every little task I'm doing each day, I'm able to perceive how much time the LLM saved me. Like I said, it's unscientific. BTW, I'll, nonetheless, release this list in a future blog post. [1] https://get-plume.com/ https://get-plume.com/
- dagw 3y ago
  highly plausible looking nonsense Ask the LLM to generate some unit tests for the code it just generated. Then if the test fails, ask the LLM to fix the bug in the code. I find that this catches and fixes a surprising number of LLM bugs in generated code.
  - denton-scratch 3y ago
    > Then if the test fails, ask the LLM to fix the bug in the code. If an LLM is intended to generate code, perhaps it's standing orders should include "Generate a comprehensive test suite, run it, fix the bugs, then iterate. Send me an email when you've finished."
    - dagw 3y ago
      I feel pretty convinced that that is the next iteration here, and would be quite disappointed if there aren't at least three companies working it right now. In fact maybe the correct solution is to generate 3 version of each function using 3 different LLMs and only return if at least 2 of them generate the same results, like back in the very early days of computers.
      - denton-scratch 3y ago
        > and would be quite disappointed if there aren't at least three companies working it right now Why does it need three companies working on it? Isn't this just a matter of prompt engineering? I've never played with an LLM, so I really don't know. Perhaps it requires some ordinary linear code to produce a "comprehensive test suite". Ultimately, the problem I can't see 3 or 300 companies solving, is the correct interpretation of technical instructions in English. Native English speakers have trouble with that, and I doubt that a machine can out-perform a native speaker. Maybe I'm wrong, and it can; but it needs to also be able to convince me that my doubt is misplaced. Writing technical specs is like writing laws; you're using vague words to describe something precise. We don't use machines to interpret laws, and I don't trust machines to interpret specs.
  - deleted 3y ago
    [deleted]
belorn 3y ago
Treating everything as if a contribution is done by an unknown entity (or worse, a hostile entity) is more work than generally people in a community want to do. Social communities are built on trust. With the XZ utils backdoor, people are currently removing any contribution done by that attacker. Even if the work done is of limited quantity, evaluating every character and every byte is a huge endeavor requiring large amount of man hours. At some point it often is easier to discard code then doing the necessary in-depth analyses and testing in order to determine with a 100% certainty that the code do what the code should be doing with no side effect, security issue or legal implication.
- bombcar 3y ago
  and if you trust me in general to be writing decent code, the review is a quick one (and let’s be honest, sometimes defacto or minimal). If you think I’m an AI, you have to review it so closely you right as well just have written it yourself.
ajsnigrutin 3y ago
AIs can make good looking pictures too, where everything looks nice... it's all good... ...until you count how many fingers the humans have. Same is true for AI generated code.
- rubymamis 3y ago
  LLMs may not be superbly good at coding right now - I compile a list of code questions they've all failed, so it's very clear they are not there yet. But they are improving at an amazing pace (and already improved my productivity in so many ways - reminding me syntax of different languages, helping to debug obscure code, writing certain functions (with varying degree of success), etc).
michaelt 3y ago
The balance of the past was that if I spent 4 hours making a patch, the busy important unpaid maintainer would spend 15 minutes reviewing it, giving me pointers etc. And they will thank me for it! I've just saved them 3h45m. This ratio stopped maintainers getting buried in review requests etc. With the rise of LLMs there's a risk the ratio will get flipped: someone can make a patch in 5 minutes which needs 15 minutes of review. That could make being a maintainer much more time-consuming - and mean the job is much less about maintaining code, and much more about dealing with timewasters politely, which ain't many people's idea of a fun hobby.
- rubymamis 3y ago
  The solution is simple → don't use automatic code suggestions/PRs. There must be a human involved that suggest a piece of code - and he/she should be fully responsible for it (if there is an error/bug in the code - he/she's at fault). That should be the way, at least, until AI is proven to better at writing code than humans.
keybored 3y ago
It matters because it can eat up the reviewers’ time. Contributors can generate some AI output in perhaps (amortized) basically no time while the reviewer has to review it for half an hour. At scale it doesn’t work to simply judge the content on its merit when the content can be generated at no cost. The content becomes indistinguishable from spam, no matter the intent of the contributor.

Why don't evaluate contributions based on how well the code/documentation is written? What does it matter who wrote it, if it's good? Assuming no spamming by bots.

somenameforme 3y ago

Same reason LLMs aren't so great for regular usage. They do an excellent job of creating highly plausible looking nonsense, which makes it much more likely for things to slip through the cracks. If there was some sort of magical way to ensure code being submitted was flawless, then we'd no longer have bugs in anything, let alone the endless critical flaws that appear in pretty much everything. For a large highly visible open source project, there's also probably intellectual property concerns. LLMs are being trained wholesale on code that's under IP protections (be that copyright or otherwise) and having that end up in your code base could land you in trouble. 'The AI did it' will probably not be seen as a viable defense.

rubymamis 3y ago
Current LLMs. While I agree, they sometimes create more problems than solving (I'm currently debugging a bug caused by GPT4 code that I initially approved), they are getting better by the day and already 1.5x my productivity.
- passwordoops 3y ago
  That's an oddly specific, very round number. You have metrics for it, or is this the same math being used to declare AGI is a year away?
  - rubymamis 3y ago
    No scientific at all, but I keep a long to-do list for my current project with dates, and it *feels* like LLMs have allowed me to cut a third of development time.
    - passwordoops 3y ago
      If you still have the record of previous projects (with similar tasks, of course) it would be really cool to see the before/after. And if you don't, and therefore cannot quantify, then for future reference simply state "it feels like the LLM makes me more efficient"
      - rubymamis 3y ago
        I could have worded it a bit better - I don't have the before and after since I've been using ChatGPT Pro for the past year, yet only started my new project[1] 7 months ago. What I meant is: by keeping track of every little task I'm doing each day, I'm able to perceive how much time the LLM saved me. Like I said, it's unscientific. BTW, I'll, nonetheless, release this list in a future blog post. [1] https://get-plume.com/ https://get-plume.com/
dagw 3y ago
highly plausible looking nonsense Ask the LLM to generate some unit tests for the code it just generated. Then if the test fails, ask the LLM to fix the bug in the code. I find that this catches and fixes a surprising number of LLM bugs in generated code.
- denton-scratch 3y ago
  > Then if the test fails, ask the LLM to fix the bug in the code. If an LLM is intended to generate code, perhaps it's standing orders should include "Generate a comprehensive test suite, run it, fix the bugs, then iterate. Send me an email when you've finished."
  - dagw 3y ago
    I feel pretty convinced that that is the next iteration here, and would be quite disappointed if there aren't at least three companies working it right now. In fact maybe the correct solution is to generate 3 version of each function using 3 different LLMs and only return if at least 2 of them generate the same results, like back in the very early days of computers.
    - denton-scratch 3y ago
      > and would be quite disappointed if there aren't at least three companies working it right now Why does it need three companies working on it? Isn't this just a matter of prompt engineering? I've never played with an LLM, so I really don't know. Perhaps it requires some ordinary linear code to produce a "comprehensive test suite". Ultimately, the problem I can't see 3 or 300 companies solving, is the correct interpretation of technical instructions in English. Native English speakers have trouble with that, and I doubt that a machine can out-perform a native speaker. Maybe I'm wrong, and it can; but it needs to also be able to convince me that my doubt is misplaced. Writing technical specs is like writing laws; you're using vague words to describe something precise. We don't use machines to interpret laws, and I don't trust machines to interpret specs.
- deleted 3y ago
  [deleted]

belorn 3y ago

Treating everything as if a contribution is done by an unknown entity (or worse, a hostile entity) is more work than generally people in a community want to do. Social communities are built on trust. With the XZ utils backdoor, people are currently removing any contribution done by that attacker. Even if the work done is of limited quantity, evaluating every character and every byte is a huge endeavor requiring large amount of man hours. At some point it often is easier to discard code then doing the necessary in-depth analyses and testing in order to determine with a 100% certainty that the code do what the code should be doing with no side effect, security issue or legal implication.

bombcar 3y ago
and if you trust me in general to be writing decent code, the review is a quick one (and let’s be honest, sometimes defacto or minimal). If you think I’m an AI, you have to review it so closely you right as well just have written it yourself.

ajsnigrutin 3y ago

AIs can make good looking pictures too, where everything looks nice... it's all good... ...until you count how many fingers the humans have. Same is true for AI generated code.

rubymamis 3y ago
LLMs may not be superbly good at coding right now - I compile a list of code questions they've all failed, so it's very clear they are not there yet. But they are improving at an amazing pace (and already improved my productivity in so many ways - reminding me syntax of different languages, helping to debug obscure code, writing certain functions (with varying degree of success), etc).

michaelt 3y ago

The balance of the past was that if I spent 4 hours making a patch, the busy important unpaid maintainer would spend 15 minutes reviewing it, giving me pointers etc. And they will thank me for it! I've just saved them 3h45m. This ratio stopped maintainers getting buried in review requests etc. With the rise of LLMs there's a risk the ratio will get flipped: someone can make a patch in 5 minutes which needs 15 minutes of review. That could make being a maintainer much more time-consuming - and mean the job is much less about maintaining code, and much more about dealing with timewasters politely, which ain't many people's idea of a fun hobby.

rubymamis 3y ago
The solution is simple → don't use automatic code suggestions/PRs. There must be a human involved that suggest a piece of code - and he/she should be fully responsible for it (if there is an error/bug in the code - he/she's at fault). That should be the way, at least, until AI is proven to better at writing code than humans.

keybored 3y ago

It matters because it can eat up the reviewers’ time. Contributors can generate some AI output in perhaps (amortized) basically no time while the reviewer has to review it for half an hour. At scale it doesn’t work to simply judge the content on its merit when the content can be generated at no cost. The content becomes indistinguishable from spam, no matter the intent of the contributor.