6 ms·

The pre-ai reaction was also unwarranted: committing a massive amount of potentially unmaintainable handwritten code isn't a necessarily positive contribution a

The pre-ai reaction was also unwarranted: committing a massive amount of potentially unmaintainable handwritten code isn't a necessarily positive contribution and any decent engineer (or person tbh) would understand that & not expect gratitude, no matter how concerted their effort. In that context, I wouldn't expect an idiot (of which there has always been far too many in this industry) to change their behaviour in a post-ai world. They were always out of line & continue to be. Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem.

DrewADesign 5mo ago
Sure, but I think we should judiciously avoid the false equivalence yielded by only looking at this on a developer-by-developer basis, rather than systemically. The truth is that in practice, AI is not a neutral force. Obviously AI can enhance the output of smart, experienced developers and improve the efficiency of code reviews, mitigating the effects of garbage PRs. However, it increases the percentage of PRs contributed by entirely inexperienced and/or not-smart devs from zero to, potentially, the majority. It entirely removes the barriers inherent to coding that kept Dunning-Krueger cases from submitting ill-conceived or poorly constructed changes— actually getting them to run in some way, even poorly. That makes them much more difficult to distinguish from well-constructed PRs than those from, say, someone cargo-culting code from tutorials. Moreover, as these tools become more expensive, people with money to blow on tokens will be able to drown maintainers that don’t have enough token-cash to help them deal with it. People see this as mostly a matter of time and energy, but I reckon it will soon be a financial issue.
- abirch 5mo ago
  I see AI as a barrier remover. Unfortunately some barriers are good or minimally necessary. I think we'll need to revert to artificial barriers such as bonds, e.g., if you want to do a PR to my repository you need to pay a 10 dollar bond. If the PR is good and I want future PRs, you keep your bond. If it's slop and spam, I get 10 dollars for my time.
  - DrewADesign 5mo ago
    I agree with the bond in theory, but that would entirely stop contributions from people in economies where a shady maintainer could keep their code, and their weekly food budget.
  - applfanboysbgon 5mo ago
    This is entirely too much friction in the wrong place. Public open source will simply die before a system like that ever becomes the norm. The previous barriers worked because they were organically perfectly in line with a contributor's internal incentives. A contributor gains very little benefit from submitting a patch; the likelihood is infinitesimally small they'll ever get any career advancement, financial recompense, or even much community recognition for it. At most, it shifts the burden of maintaining the code they're contributing from themselves to the community / long-term maintainers. The real incentive for a contributor was making the patch, because they get to see the feature or fix they want made for the software. The previous barriers were in making the patch, and contributors would overcome that friction to gain the benefit of having the patch they want. Moving the barrier to merely submitting the patch after it has already been made will simply result in people not bothering, because there is very little incentivizing them to deal with the friction.
    - abirch 5mo ago
      I don't disagree, where is the right place for the friction?
      - deleted 5mo ago
        [deleted]
  - Forgeties79 5mo ago
    We already have trouble with people maintaining open source projects without getting paid, now you want people to pay for the privilege to participate in free work?
    - 5mo ago
Fraterkes 5mo ago
Gratitude was maybe the wrong word. As the article mentions, before ai I think larger PRs, while sometimes inconsiderate, at least implied some amount of care / effort / good faith. In my experience, that was often rewarded with the maintainers at least taking a look at the code. I meant it's odd to have the same expectation when you dump 3000 lines in a pr that you won't even personally write a description for.
Klonoar 5mo ago
> Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem. It is hard for me to imagine another engineering discipline that would be totally fine accepting work from those who don't have the actual engineering background required to do the work. If I had to push this take to the extreme: software engineers never learned class solidarity and it's now biting the industry in the ass.
- dcrazy 5mo ago
  Man, you must hate those handymen who put up YouTube videos showing how to do basic home maintenance. A truly class-conscious handyman would insist that the homeowner hire them to replace a light switch.
  - Based-A 5mo ago
    Come on, are you really going to strawman "engineering should be inherently disqualifying" into "so people shouldn't DIY in their own home"? Please try a little bit harder.
    - dcrazy 5mo ago
      I’m not strawmanning anything. I’m pointing out what I believe to be ridiculous gatekeeping. Software engineering isn’t some holy magic that must be kept from the masses. I can go on YouTube and get step-by-step instructions on how to safely wire an entire house. In many jurisdictions I would even be allowed to do that. I can get instructions on how to completely redo a bathroom, down to the studs and up through the waterproofing and tiling. I can get instructions on how to do foundation repair, which might be a bit much for me but can help me ask the right questions to keep the contractor I hired honest. These are all examples of experts acting as “traitors” to their particular group. In reality, technology enables both specialization and despecialization. Some people try to cling to their specializations and cry “class warfare” when threatened.
jakolaptu 5mo ago
But your company employs said individual, whereas arbitrary drive-by patches from randos on open source projects with no consequence of submitting a mountain of garbage. The answer: require a written proposal for changes before a patch will even be considered unless it is sufficiently small. Also fight AI with AI: have a bot auto reject patches unless they can link to a previously approved enhancement document. Folks who commit minimal effort will f*ck right off. Then the cognitive burden is focused on the ideas, and code authors should have at least conveyed the intent. If they actually care to invest their skin in the game then they need to collaborate and not just drop garbage on the front door.
- lucideer 5mo ago
  just to clarify: 1. my company also employs its fair share of folk that would fit into the so-called "idiot" category of my post - I just thought it was of note that I have encountered exceptions to this stereotype 2. I fully support what Ladybird is doing here & find it unfortunate that they have to. I didn't intend my post to criticise their move - my example is definitely the rare exception in a sea of unmaintainable garbage. I do think however that it was already a challenging prospect to manage garbage oss prs in the pre-llm era (see umpteen posts on maintainer burnout) & I wouldn't have faulted any open source project for doing what ladybird is doing even pre-llm.
- zzzeek 5mo ago
  yes. github has very minimal controls for PRs (either shut them off completely, or not at all) but through GH webhooks you can essentially script "auto-close" of PRs that dont have correct preliminary approval. it's time for there to be some really nice workflow tooling that people can plug into their GH repos that does this and other things.
isityettime 5mo ago
On this topic, "Open-Source Isn't About You": https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...

DrewADesign 5mo ago

Sure, but I think we should judiciously avoid the false equivalence yielded by only looking at this on a developer-by-developer basis, rather than systemically. The truth is that in practice, AI is not a neutral force. Obviously AI can enhance the output of smart, experienced developers and improve the efficiency of code reviews, mitigating the effects of garbage PRs. However, it increases the percentage of PRs contributed by entirely inexperienced and/or not-smart devs from zero to, potentially, the majority. It entirely removes the barriers inherent to coding that kept Dunning-Krueger cases from submitting ill-conceived or poorly constructed changes— actually getting them to run in some way, even poorly. That makes them much more difficult to distinguish from well-constructed PRs than those from, say, someone cargo-culting code from tutorials. Moreover, as these tools become more expensive, people with money to blow on tokens will be able to drown maintainers that don’t have enough token-cash to help them deal with it. People see this as mostly a matter of time and energy, but I reckon it will soon be a financial issue.

abirch 5mo ago
I see AI as a barrier remover. Unfortunately some barriers are good or minimally necessary. I think we'll need to revert to artificial barriers such as bonds, e.g., if you want to do a PR to my repository you need to pay a 10 dollar bond. If the PR is good and I want future PRs, you keep your bond. If it's slop and spam, I get 10 dollars for my time.
- DrewADesign 5mo ago
  I agree with the bond in theory, but that would entirely stop contributions from people in economies where a shady maintainer could keep their code, and their weekly food budget.
- applfanboysbgon 5mo ago
  This is entirely too much friction in the wrong place. Public open source will simply die before a system like that ever becomes the norm. The previous barriers worked because they were organically perfectly in line with a contributor's internal incentives. A contributor gains very little benefit from submitting a patch; the likelihood is infinitesimally small they'll ever get any career advancement, financial recompense, or even much community recognition for it. At most, it shifts the burden of maintaining the code they're contributing from themselves to the community / long-term maintainers. The real incentive for a contributor was making the patch, because they get to see the feature or fix they want made for the software. The previous barriers were in making the patch, and contributors would overcome that friction to gain the benefit of having the patch they want. Moving the barrier to merely submitting the patch after it has already been made will simply result in people not bothering, because there is very little incentivizing them to deal with the friction.
  - abirch 5mo ago
    I don't disagree, where is the right place for the friction?
    - deleted 5mo ago
      [deleted]
- Forgeties79 5mo ago
  We already have trouble with people maintaining open source projects without getting paid, now you want people to pay for the privilege to participate in free work?
  - 5mo ago

Fraterkes 5mo ago

Gratitude was maybe the wrong word. As the article mentions, before ai I think larger PRs, while sometimes inconsiderate, at least implied some amount of care / effort / good faith. In my experience, that was often rewarded with the maintainers at least taking a look at the code. I meant it's odd to have the same expectation when you dump 3000 lines in a pr that you won't even personally write a description for.

Klonoar 5mo ago

> Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, with review feedback graciously received & expediently addressed, so this isn't a matter of the idiots not being technical, it's an attitude problem. It is hard for me to imagine another engineering discipline that would be totally fine accepting work from those who don't have the actual engineering background required to do the work. If I had to push this take to the extreme: software engineers never learned class solidarity and it's now biting the industry in the ass.

dcrazy 5mo ago
Man, you must hate those handymen who put up YouTube videos showing how to do basic home maintenance. A truly class-conscious handyman would insist that the homeowner hire them to replace a light switch.
- Based-A 5mo ago
  Come on, are you really going to strawman "engineering should be inherently disqualifying" into "so people shouldn't DIY in their own home"? Please try a little bit harder.
  - dcrazy 5mo ago
    I’m not strawmanning anything. I’m pointing out what I believe to be ridiculous gatekeeping. Software engineering isn’t some holy magic that must be kept from the masses. I can go on YouTube and get step-by-step instructions on how to safely wire an entire house. In many jurisdictions I would even be allowed to do that. I can get instructions on how to completely redo a bathroom, down to the studs and up through the waterproofing and tiling. I can get instructions on how to do foundation repair, which might be a bit much for me but can help me ask the right questions to keep the contractor I hired honest. These are all examples of experts acting as “traitors” to their particular group. In reality, technology enables both specialization and despecialization. Some people try to cling to their specializations and cry “class warfare” when threatened.

jakolaptu 5mo ago

But your company employs said individual, whereas arbitrary drive-by patches from randos on open source projects with no consequence of submitting a mountain of garbage. The answer: require a written proposal for changes before a patch will even be considered unless it is sufficiently small. Also fight AI with AI: have a bot auto reject patches unless they can link to a previously approved enhancement document. Folks who commit minimal effort will f*ck right off. Then the cognitive burden is focused on the ideas, and code authors should have at least conveyed the intent. If they actually care to invest their skin in the game then they need to collaborate and not just drop garbage on the front door.

lucideer 5mo ago
just to clarify: 1. my company also employs its fair share of folk that would fit into the so-called "idiot" category of my post - I just thought it was of note that I have encountered exceptions to this stereotype 2. I fully support what Ladybird is doing here & find it unfortunate that they have to. I didn't intend my post to criticise their move - my example is definitely the rare exception in a sea of unmaintainable garbage. I do think however that it was already a challenging prospect to manage garbage oss prs in the pre-llm era (see umpteen posts on maintainer burnout) & I wouldn't have faulted any open source project for doing what ladybird is doing even pre-llm.
zzzeek 5mo ago
yes. github has very minimal controls for PRs (either shut them off completely, or not at all) but through GH webhooks you can essentially script "auto-close" of PRs that dont have correct preliminary approval. it's time for there to be some really nice workflow tooling that people can plug into their GH repos that does this and other things.

isityettime 5mo ago

On this topic, "Open-Source Isn't About You": https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9 https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...