4 ms·

These comments have to be bot generated. It's so tiring.

by pmlnr 3y ago

barfbagginus 3y ago
I'm a person. I just write like that because I'm an awful writer and can't read a room. The idea - fixing noisy build codes with the help of AI - is actually a valid one. If you don't want to engage with the idea, then at least don't disparage me for being bot-like. I usually ignore non-constructive criticism. But sometimes devaluing insults can hurt me. Especially when they attack my communication weaknesses. Anyways, if you continue to insult me I will assume you believe I'm a human, and are getting off on dissing my communication style. If you really believe I'm a robot, then prove it by saying nothing.
- pmlnr 3y ago
  It wasn't the writing style, it was the "let's put AI in it" content that triggered me. No, it's not a valid idea, trusting LLMs with this would be plain catastrophic with all it's hallucinations.
  - deleted 3y ago
    [deleted]
  - barfbagginus 3y ago
    You're assuming a few things: 1. I'm using GPT 3.5 level LLMs 2. I'm not using humans in the loop to verify solutions 3. I'm not using testing or self-correcting strategies to verify and correct solutions Given these assumptions, then I agree - hallucinations eat your lunch, big time. What I proposing is using GPT4 to annotate existing solutions and propose drafts, with humans in the loop to approve and revise, and self-correcting workflows to test solutions. And I'm basing this off my own experience with upgrading project build and packaging systems, using the AI to annotate, draft, fix errors, etc. I have full oversight over the final solution. And it has to be simple and clean, or I write another draft. The result is that I can understand and upgrade build and packaging solutions maybe five or ten times faster than I ever could before. Even quite cryptic legacy systems that I would never touch before. Now multiply that times every open source developer in the world. That's why I think we could execute a major build and packaging modernization effort.
- pas 3y ago
  the idea is valid, but current LLMs suck, as the sibling comment says, they hallucinate too much, etc. that doesn't mean they won't improve enough in the next decade (especially coupled with clever loops, where the generated code is checked, end-to-end tested, static analyzed) but this also shows what's really missing from these old projects, infrastructure, QA, CI, modern tools, etc. and adding these requires humans in the loops, and every change needs to be checked, verified, etc. and it's a hard task for a loose community of volunteers. even the super fancy Rust community kind of shrugged and let crev die silently https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev
  - barfbagginus 3y ago
    > Shows what's really missing from these old projects Well that's kind of the opportunity there, right? Usually there are more modern solutions: - use GH actions to do multi platform / multi-compiler tests - use modern packaging solutions (eg, convert setup.py to a Pep 518 style pyproject.toml) - publish to package repos (eg, many python projects are not on pypi) This kind of work was baffling to me before I started working with gpt4 - my main struggle was understanding existing solutions, reading the documentation of existing build and packaging systems, and troubleshooting complex error logs. At first gpt4 simply helped me when my own reading inabilities kicked my butt. But then I got better at understanding existing solutions and proposing new work. Now I can describe things at a high level and give GPT the right context it needs to propose a good first draft solution. And I understand things well enough to manually validate the solution. On top of that we also go ahead and test the solution, and fix issues that come up. As a result I'm simply not scared of build systems anymore, no matter how byzantine or poorly documented. I'm vastly more capable of completing improvements then I was a year ago, and have half a dozen major upgrades under my belt. I don't think that this will ever work automatically given that even gpt4 still hallucinates and lacks big picture thinking and awareness of up to date best practices. However I do see it as a huge Force Multiplier for our loose community of volunteers. We'll have to break down the assumptions that GPT always hallucinates uncontrollably. That's simply not true - GPT4 usually hallucinates in ways that are easy to fix by checking documentation and running tests. It usually introduces less errors than I do if I'm new to a system, and with its help I can correct more errors than I can on my own. I see it as a huge win, if we can educate people in the community.
- otabdeveloper4 3y ago
  "AI" is not actually intelligence, it's an advanced madlibs generator. No, you do not want it anywhere near your source code.

These comments have to be bot generated. It's so tiring.

by pmlnr 3y ago

These comments have to be bot generated. It's so tiring.

I'm a person. I just write like that because I'm an awful writer and can't read a room. The idea - fixing noisy build codes with the help of AI - is actually a valid one. If you don't want to engage with the idea, then at least don't disparage me for being bot-like. I usually ignore non-constructive criticism. But sometimes devaluing insults can hurt me. Especially when they attack my communication weaknesses. Anyways, if you continue to insult me I will assume you believe I'm a human, and are getting off on dissing my communication style. If you really believe I'm a robot, then prove it by saying nothing.

pmlnr 3y ago
It wasn't the writing style, it was the "let's put AI in it" content that triggered me. No, it's not a valid idea, trusting LLMs with this would be plain catastrophic with all it's hallucinations.
- deleted 3y ago
  [deleted]
- barfbagginus 3y ago
  You're assuming a few things: 1. I'm using GPT 3.5 level LLMs 2. I'm not using humans in the loop to verify solutions 3. I'm not using testing or self-correcting strategies to verify and correct solutions Given these assumptions, then I agree - hallucinations eat your lunch, big time. What I proposing is using GPT4 to annotate existing solutions and propose drafts, with humans in the loop to approve and revise, and self-correcting workflows to test solutions. And I'm basing this off my own experience with upgrading project build and packaging systems, using the AI to annotate, draft, fix errors, etc. I have full oversight over the final solution. And it has to be simple and clean, or I write another draft. The result is that I can understand and upgrade build and packaging solutions maybe five or ten times faster than I ever could before. Even quite cryptic legacy systems that I would never touch before. Now multiply that times every open source developer in the world. That's why I think we could execute a major build and packaging modernization effort.
pas 3y ago
the idea is valid, but current LLMs suck, as the sibling comment says, they hallucinate too much, etc. that doesn't mean they won't improve enough in the next decade (especially coupled with clever loops, where the generated code is checked, end-to-end tested, static analyzed) but this also shows what's really missing from these old projects, infrastructure, QA, CI, modern tools, etc. and adding these requires humans in the loops, and every change needs to be checked, verified, etc. and it's a hard task for a loose community of volunteers. even the super fancy Rust community kind of shrugged and let crev die silently https://github.com/crev-dev/cargo-crev https://github.com/crev-dev/cargo-crev
- barfbagginus 3y ago
  > Shows what's really missing from these old projects Well that's kind of the opportunity there, right? Usually there are more modern solutions: - use GH actions to do multi platform / multi-compiler tests - use modern packaging solutions (eg, convert setup.py to a Pep 518 style pyproject.toml) - publish to package repos (eg, many python projects are not on pypi) This kind of work was baffling to me before I started working with gpt4 - my main struggle was understanding existing solutions, reading the documentation of existing build and packaging systems, and troubleshooting complex error logs. At first gpt4 simply helped me when my own reading inabilities kicked my butt. But then I got better at understanding existing solutions and proposing new work. Now I can describe things at a high level and give GPT the right context it needs to propose a good first draft solution. And I understand things well enough to manually validate the solution. On top of that we also go ahead and test the solution, and fix issues that come up. As a result I'm simply not scared of build systems anymore, no matter how byzantine or poorly documented. I'm vastly more capable of completing improvements then I was a year ago, and have half a dozen major upgrades under my belt. I don't think that this will ever work automatically given that even gpt4 still hallucinates and lacks big picture thinking and awareness of up to date best practices. However I do see it as a huge Force Multiplier for our loose community of volunteers. We'll have to break down the assumptions that GPT always hallucinates uncontrollably. That's simply not true - GPT4 usually hallucinates in ways that are easy to fix by checking documentation and running tests. It usually introduces less errors than I do if I'm new to a system, and with its help I can correct more errors than I can on my own. I see it as a huge win, if we can educate people in the community.
otabdeveloper4 3y ago
"AI" is not actually intelligence, it's an advanced madlibs generator. No, you do not want it anywhere near your source code.