One of the open source projects I used to (many years ago, so I am not really affected anymore) has recently decided to allow AI contributions.
-
One of the open source projects I used to (many years ago, so I am not really affected anymore) has recently decided to allow AI contributions. One of their arguments is that they judge submissions on quality, not tools used.
Back when I was an active contributor (to the project and maintainer of some other parts of the surrounding ecosystem), I got a lot of submissions that were bad.
The thing is, I absolutely loved getting these because they always came from super-enthusiastic junior people. Reviewing them and giving feedback often too much longer than implementing the feature myself. The same was usually true for the next contribution too. But that shifted over time. After a few months, I started getting patches where I didn’t find anything beyond the cosmetic that I wanted to change.
Going back further, I was one of those people when I started contributing.
Measured as code contributions over the short term, maintainers working with submitters of poor-quality PRs is a waste of time. You’re taking time away from writing code to do something that produces code more slowly.
Measured over the long term, the results are very different. Far more code in that project and closely related parts of the ecosystem has been written by people who I mentored when they came along with some bad code than by me.
It’s never a waste of my time to turn an enthusiastic and incompetent contributor into an enthusiastic and competent contributor, it’s an absolutely critical part of building a healthy project. I wouldn’t have got nearly as much out of F/OSS on a personal level if I hadn’t encountered a lot of people with the same opinion when I was one of the enthusiastic and incompetent newcomers.
But LLMs are not like that. If I spend time reviewing LLM-generated code when it would have been faster to write it myself (which, to be clear, is the case on 100% of LLM-submitted PRs I’ve seen so far), then that’s just a time sink. It’s also taking away time I could be spending helping new contributors who want to actually improve, rather than just take the review comments, feed them into an opaque system, and give me back the results.
"no, but OUR LLM self improves!"
"actual self improvement or memories.md?"
"memories.md"
-
@david_chisnall
On the specific topic of "AI" and not just contributions to FOSS but education in general, I believe this is absolutely the crux of the matter. So incredibly short-sighted!@fred @david_chisnall I have read many metaphors for LLM commits and one I liked was that of building car-dependent cities. Sure, cars are faster than walking and useful for hauling stuff. The other cities are also building roads to boost commerce etc...
And after years or decades you notice that everything's a car-dependent hellhole. Kids get run over all the time and costs are externalised but it's hard to attribute it to a single decision in the past or a frameworks/embargo you didn't put up. -
@fred @david_chisnall I have read many metaphors for LLM commits and one I liked was that of building car-dependent cities. Sure, cars are faster than walking and useful for hauling stuff. The other cities are also building roads to boost commerce etc...
And after years or decades you notice that everything's a car-dependent hellhole. Kids get run over all the time and costs are externalised but it's hard to attribute it to a single decision in the past or a frameworks/embargo you didn't put up. -
@fred @david_chisnall I have read many metaphors for LLM commits and one I liked was that of building car-dependent cities. Sure, cars are faster than walking and useful for hauling stuff. The other cities are also building roads to boost commerce etc...
And after years or decades you notice that everything's a car-dependent hellhole. Kids get run over all the time and costs are externalised but it's hard to attribute it to a single decision in the past or a frameworks/embargo you didn't put up.@compfu @david_chisnall Yeah. In a similar vein, imagine allowing kids in schools to ride motorbikes or e-scooters during physical education classes. It should be obvious to all that it's just defeating the purpose of the whole thing.
Yet we keep hearing people advocating for LLMs in the classroom, generally under the absolutely infuriating pretense of "teaching the next gen to be AI-natives" or such inane bullshit. -
One of the open source projects I used to (many years ago, so I am not really affected anymore) has recently decided to allow AI contributions. One of their arguments is that they judge submissions on quality, not tools used.
Back when I was an active contributor (to the project and maintainer of some other parts of the surrounding ecosystem), I got a lot of submissions that were bad.
The thing is, I absolutely loved getting these because they always came from super-enthusiastic junior people. Reviewing them and giving feedback often too much longer than implementing the feature myself. The same was usually true for the next contribution too. But that shifted over time. After a few months, I started getting patches where I didn’t find anything beyond the cosmetic that I wanted to change.
Going back further, I was one of those people when I started contributing.
Measured as code contributions over the short term, maintainers working with submitters of poor-quality PRs is a waste of time. You’re taking time away from writing code to do something that produces code more slowly.
Measured over the long term, the results are very different. Far more code in that project and closely related parts of the ecosystem has been written by people who I mentored when they came along with some bad code than by me.
It’s never a waste of my time to turn an enthusiastic and incompetent contributor into an enthusiastic and competent contributor, it’s an absolutely critical part of building a healthy project. I wouldn’t have got nearly as much out of F/OSS on a personal level if I hadn’t encountered a lot of people with the same opinion when I was one of the enthusiastic and incompetent newcomers.
But LLMs are not like that. If I spend time reviewing LLM-generated code when it would have been faster to write it myself (which, to be clear, is the case on 100% of LLM-submitted PRs I’ve seen so far), then that’s just a time sink. It’s also taking away time I could be spending helping new contributors who want to actually improve, rather than just take the review comments, feed them into an opaque system, and give me back the results.
@david_chisnall I learned so much from people I have never met in person early on (e.g. while involved in dslinux.org). Eventually I met some people in person (Subversion and OpenBSD) at which point my rate of learning climbed up immensely.
Granted, once I met people in person I was (unknowingly) well on the way to get paid for some of the work I was doing creating freely redistributable code. But even when I started out at university and barely knew anything there were 12 year olds trying out dslinux who were younger and mindblown learning they could use their DS as a small Linux computer (before smartphones were everywhere) who would learn some things from me, and who ended up going down similar paths.
The importance of mutual learning never disappeared for me even when it became a paid job. Mutual learning has always been what made FOSS a good deal. Learning how to design things. Learning how to work in a distributed team with mostly intrinsically motivated members with very little top-down direction, if any. Learning useful coding idioms and which idioms to avoid. Learning how these ad-hoc communities can operate well and what can cause them harm. It all becomes meaningless unpaid labour without learning things like this.
I have never asked an LLM for anything in my life, and I feel fine. I am not going to let them change this for me.
-
One of the open source projects I used to (many years ago, so I am not really affected anymore) has recently decided to allow AI contributions. One of their arguments is that they judge submissions on quality, not tools used.
Back when I was an active contributor (to the project and maintainer of some other parts of the surrounding ecosystem), I got a lot of submissions that were bad.
The thing is, I absolutely loved getting these because they always came from super-enthusiastic junior people. Reviewing them and giving feedback often too much longer than implementing the feature myself. The same was usually true for the next contribution too. But that shifted over time. After a few months, I started getting patches where I didn’t find anything beyond the cosmetic that I wanted to change.
Going back further, I was one of those people when I started contributing.
Measured as code contributions over the short term, maintainers working with submitters of poor-quality PRs is a waste of time. You’re taking time away from writing code to do something that produces code more slowly.
Measured over the long term, the results are very different. Far more code in that project and closely related parts of the ecosystem has been written by people who I mentored when they came along with some bad code than by me.
It’s never a waste of my time to turn an enthusiastic and incompetent contributor into an enthusiastic and competent contributor, it’s an absolutely critical part of building a healthy project. I wouldn’t have got nearly as much out of F/OSS on a personal level if I hadn’t encountered a lot of people with the same opinion when I was one of the enthusiastic and incompetent newcomers.
But LLMs are not like that. If I spend time reviewing LLM-generated code when it would have been faster to write it myself (which, to be clear, is the case on 100% of LLM-submitted PRs I’ve seen so far), then that’s just a time sink. It’s also taking away time I could be spending helping new contributors who want to actually improve, rather than just take the review comments, feed them into an opaque system, and give me back the results.
@david_chisnall I use LLMs (kind of a work requirement at this point, but I use them for some of my OSS stuff, too, particularly for security audits), but I won't accept PRs made by LLMs. If I'm going to be reviewing LLM-generated code, which is verbose, often lacks a sense of intention, and is just generally hard to read, I'd rather drive the LLM myself. I don't want someone else's slop, I want my own. At least I know what I find most annoying about them and can make it behave better.
So, if someone with no experience in the codebase can implement something with an LLM, then I can pretty much always implement it with an LLM and review that implementation faster than I could review the PR from a stranger, so I just don't want the PR from the stranger. They can make a feature request.
Which, as you note, basically chops off the junior dev pipeline, and that seems bad.
-
@compfu @david_chisnall Yeah. In a similar vein, imagine allowing kids in schools to ride motorbikes or e-scooters during physical education classes. It should be obvious to all that it's just defeating the purpose of the whole thing.
Yet we keep hearing people advocating for LLMs in the classroom, generally under the absolutely infuriating pretense of "teaching the next gen to be AI-natives" or such inane bullshit.@compfu @david_chisnall The other typical argument for that is the claim that "It'll bring equal opportunities to disadvantaged children who will get their own personal AI tutor", which is such an utterly cynical and finely veiled distraction from the ongoing de-funding of the public school system that it literally makes me sick.
Kids with parents who have either enough free time to help them or money to pay for a tutor will be fine, while the others will be left having to rely on chatGPT to explain them how trigonometry works, while they have less and less time with their underpayed and overworked teachers ("those OpenAI subscriptions don't come cheap, you know!"...)
-
One of the open source projects I used to (many years ago, so I am not really affected anymore) has recently decided to allow AI contributions. One of their arguments is that they judge submissions on quality, not tools used.
Back when I was an active contributor (to the project and maintainer of some other parts of the surrounding ecosystem), I got a lot of submissions that were bad.
The thing is, I absolutely loved getting these because they always came from super-enthusiastic junior people. Reviewing them and giving feedback often too much longer than implementing the feature myself. The same was usually true for the next contribution too. But that shifted over time. After a few months, I started getting patches where I didn’t find anything beyond the cosmetic that I wanted to change.
Going back further, I was one of those people when I started contributing.
Measured as code contributions over the short term, maintainers working with submitters of poor-quality PRs is a waste of time. You’re taking time away from writing code to do something that produces code more slowly.
Measured over the long term, the results are very different. Far more code in that project and closely related parts of the ecosystem has been written by people who I mentored when they came along with some bad code than by me.
It’s never a waste of my time to turn an enthusiastic and incompetent contributor into an enthusiastic and competent contributor, it’s an absolutely critical part of building a healthy project. I wouldn’t have got nearly as much out of F/OSS on a personal level if I hadn’t encountered a lot of people with the same opinion when I was one of the enthusiastic and incompetent newcomers.
But LLMs are not like that. If I spend time reviewing LLM-generated code when it would have been faster to write it myself (which, to be clear, is the case on 100% of LLM-submitted PRs I’ve seen so far), then that’s just a time sink. It’s also taking away time I could be spending helping new contributors who want to actually improve, rather than just take the review comments, feed them into an opaque system, and give me back the results.
@david_chisnall you can still make a difference by reviewing bad code from junior developers. The problem is bad AI-generated code from un-experienced junior developers. You first need to learn to walk before you can run. However, I know a lot of experienced developers who actually love to use AI for coding and they can generate good stuff. Excluding them from OSS is a waste of experience and resources.
-
One of the open source projects I used to (many years ago, so I am not really affected anymore) has recently decided to allow AI contributions. One of their arguments is that they judge submissions on quality, not tools used.
Back when I was an active contributor (to the project and maintainer of some other parts of the surrounding ecosystem), I got a lot of submissions that were bad.
The thing is, I absolutely loved getting these because they always came from super-enthusiastic junior people. Reviewing them and giving feedback often too much longer than implementing the feature myself. The same was usually true for the next contribution too. But that shifted over time. After a few months, I started getting patches where I didn’t find anything beyond the cosmetic that I wanted to change.
Going back further, I was one of those people when I started contributing.
Measured as code contributions over the short term, maintainers working with submitters of poor-quality PRs is a waste of time. You’re taking time away from writing code to do something that produces code more slowly.
Measured over the long term, the results are very different. Far more code in that project and closely related parts of the ecosystem has been written by people who I mentored when they came along with some bad code than by me.
It’s never a waste of my time to turn an enthusiastic and incompetent contributor into an enthusiastic and competent contributor, it’s an absolutely critical part of building a healthy project. I wouldn’t have got nearly as much out of F/OSS on a personal level if I hadn’t encountered a lot of people with the same opinion when I was one of the enthusiastic and incompetent newcomers.
But LLMs are not like that. If I spend time reviewing LLM-generated code when it would have been faster to write it myself (which, to be clear, is the case on 100% of LLM-submitted PRs I’ve seen so far), then that’s just a time sink. It’s also taking away time I could be spending helping new contributors who want to actually improve, rather than just take the review comments, feed them into an opaque system, and give me back the results.
-
One of the open source projects I used to (many years ago, so I am not really affected anymore) has recently decided to allow AI contributions. One of their arguments is that they judge submissions on quality, not tools used.
Back when I was an active contributor (to the project and maintainer of some other parts of the surrounding ecosystem), I got a lot of submissions that were bad.
The thing is, I absolutely loved getting these because they always came from super-enthusiastic junior people. Reviewing them and giving feedback often too much longer than implementing the feature myself. The same was usually true for the next contribution too. But that shifted over time. After a few months, I started getting patches where I didn’t find anything beyond the cosmetic that I wanted to change.
Going back further, I was one of those people when I started contributing.
Measured as code contributions over the short term, maintainers working with submitters of poor-quality PRs is a waste of time. You’re taking time away from writing code to do something that produces code more slowly.
Measured over the long term, the results are very different. Far more code in that project and closely related parts of the ecosystem has been written by people who I mentored when they came along with some bad code than by me.
It’s never a waste of my time to turn an enthusiastic and incompetent contributor into an enthusiastic and competent contributor, it’s an absolutely critical part of building a healthy project. I wouldn’t have got nearly as much out of F/OSS on a personal level if I hadn’t encountered a lot of people with the same opinion when I was one of the enthusiastic and incompetent newcomers.
But LLMs are not like that. If I spend time reviewing LLM-generated code when it would have been faster to write it myself (which, to be clear, is the case on 100% of LLM-submitted PRs I’ve seen so far), then that’s just a time sink. It’s also taking away time I could be spending helping new contributors who want to actually improve, rather than just take the review comments, feed them into an opaque system, and give me back the results.
@david_chisnall The problem remain the same since the beginning. Industrials aims to produce fast and cheap, whatever as far as they can sold.
Add some magic, because creating a software is magic for most.
IA make their dreams true.
Furthermore, we are into an hype, like quantum few years ago, kisses to IBM :-).
Where is my quantumic knife ? -
One of the open source projects I used to (many years ago, so I am not really affected anymore) has recently decided to allow AI contributions. One of their arguments is that they judge submissions on quality, not tools used.
Back when I was an active contributor (to the project and maintainer of some other parts of the surrounding ecosystem), I got a lot of submissions that were bad.
The thing is, I absolutely loved getting these because they always came from super-enthusiastic junior people. Reviewing them and giving feedback often too much longer than implementing the feature myself. The same was usually true for the next contribution too. But that shifted over time. After a few months, I started getting patches where I didn’t find anything beyond the cosmetic that I wanted to change.
Going back further, I was one of those people when I started contributing.
Measured as code contributions over the short term, maintainers working with submitters of poor-quality PRs is a waste of time. You’re taking time away from writing code to do something that produces code more slowly.
Measured over the long term, the results are very different. Far more code in that project and closely related parts of the ecosystem has been written by people who I mentored when they came along with some bad code than by me.
It’s never a waste of my time to turn an enthusiastic and incompetent contributor into an enthusiastic and competent contributor, it’s an absolutely critical part of building a healthy project. I wouldn’t have got nearly as much out of F/OSS on a personal level if I hadn’t encountered a lot of people with the same opinion when I was one of the enthusiastic and incompetent newcomers.
But LLMs are not like that. If I spend time reviewing LLM-generated code when it would have been faster to write it myself (which, to be clear, is the case on 100% of LLM-submitted PRs I’ve seen so far), then that’s just a time sink. It’s also taking away time I could be spending helping new contributors who want to actually improve, rather than just take the review comments, feed them into an opaque system, and give me back the results.
@david_chisnall I was listening to conspiracy theorist Bob Wilson talking about "F is for Fake", in which an art forger confessed to forging far more famous paintings than he had been accused of - including many that had been verified as real by art critics. The rhetoric goes back and forth a bit, but the punchline is "since there is no consensus on whether this is a real Picasso, the only way to attach worth to it is by how much you like it."
-
@david_chisnall
On the specific topic of "AI" and not just contributions to FOSS but education in general, I believe this is absolutely the crux of the matter. So incredibly short-sighted!@fred
id say this exact thing is the long play in the "ai" businessthey want a subscription 4 intelligence and the only way 2 get us 2 pay is by makin us dumb first
-
@fred
id say this exact thing is the long play in the "ai" businessthey want a subscription 4 intelligence and the only way 2 get us 2 pay is by makin us dumb first
@44 well yeah. Sam Altman said exactly that, in so many words: "We see a future where intelligence is a utility, like electricity or water, and people buy it from us on a meter"
We're sooo past even the "Bond villain" caricature stage... ¯\_(ツ)_/¯
-
@44 well yeah. Sam Altman said exactly that, in so many words: "We see a future where intelligence is a utility, like electricity or water, and people buy it from us on a meter"
We're sooo past even the "Bond villain" caricature stage... ¯\_(ツ)_/¯
@44 I mean this is complete and utter bullshit, of course. A blatant scam that will never amount to jack shit.
But it is indeed the official "play" (or at least it was that particular time he said it. Who knows what it is this week??) -
One of the open source projects I used to (many years ago, so I am not really affected anymore) has recently decided to allow AI contributions. One of their arguments is that they judge submissions on quality, not tools used.
Back when I was an active contributor (to the project and maintainer of some other parts of the surrounding ecosystem), I got a lot of submissions that were bad.
The thing is, I absolutely loved getting these because they always came from super-enthusiastic junior people. Reviewing them and giving feedback often too much longer than implementing the feature myself. The same was usually true for the next contribution too. But that shifted over time. After a few months, I started getting patches where I didn’t find anything beyond the cosmetic that I wanted to change.
Going back further, I was one of those people when I started contributing.
Measured as code contributions over the short term, maintainers working with submitters of poor-quality PRs is a waste of time. You’re taking time away from writing code to do something that produces code more slowly.
Measured over the long term, the results are very different. Far more code in that project and closely related parts of the ecosystem has been written by people who I mentored when they came along with some bad code than by me.
It’s never a waste of my time to turn an enthusiastic and incompetent contributor into an enthusiastic and competent contributor, it’s an absolutely critical part of building a healthy project. I wouldn’t have got nearly as much out of F/OSS on a personal level if I hadn’t encountered a lot of people with the same opinion when I was one of the enthusiastic and incompetent newcomers.
But LLMs are not like that. If I spend time reviewing LLM-generated code when it would have been faster to write it myself (which, to be clear, is the case on 100% of LLM-submitted PRs I’ve seen so far), then that’s just a time sink. It’s also taking away time I could be spending helping new contributors who want to actually improve, rather than just take the review comments, feed them into an opaque system, and give me back the results.
@david_chisnall This is why I think a good middle ground for project owners who want to use LLMs themselves is to still ban the tool for anyone but regular contributors.
-
One of the open source projects I used to (many years ago, so I am not really affected anymore) has recently decided to allow AI contributions. One of their arguments is that they judge submissions on quality, not tools used.
Back when I was an active contributor (to the project and maintainer of some other parts of the surrounding ecosystem), I got a lot of submissions that were bad.
The thing is, I absolutely loved getting these because they always came from super-enthusiastic junior people. Reviewing them and giving feedback often too much longer than implementing the feature myself. The same was usually true for the next contribution too. But that shifted over time. After a few months, I started getting patches where I didn’t find anything beyond the cosmetic that I wanted to change.
Going back further, I was one of those people when I started contributing.
Measured as code contributions over the short term, maintainers working with submitters of poor-quality PRs is a waste of time. You’re taking time away from writing code to do something that produces code more slowly.
Measured over the long term, the results are very different. Far more code in that project and closely related parts of the ecosystem has been written by people who I mentored when they came along with some bad code than by me.
It’s never a waste of my time to turn an enthusiastic and incompetent contributor into an enthusiastic and competent contributor, it’s an absolutely critical part of building a healthy project. I wouldn’t have got nearly as much out of F/OSS on a personal level if I hadn’t encountered a lot of people with the same opinion when I was one of the enthusiastic and incompetent newcomers.
But LLMs are not like that. If I spend time reviewing LLM-generated code when it would have been faster to write it myself (which, to be clear, is the case on 100% of LLM-submitted PRs I’ve seen so far), then that’s just a time sink. It’s also taking away time I could be spending helping new contributors who want to actually improve, rather than just take the review comments, feed them into an opaque system, and give me back the results.
@david_chisnall LLM code needs even more checking, as in my experience it's not uncommon to find security violations in it, and once or twice malware. LLMs can create code, but they are dumb as a rock.
-
P pelle@veganism.social shared this topic
