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.
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.
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.
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.
1) more reliance on systems to track reputation across projects. I'm sure Microsoft, in the form of GitHub, will love to sell you a partial fix to the same problems it so enthusiastically helped to create. But there are the familiar problems of surveillance, identity theft, office politics, and system-gaming, and it doesn't on its own offer an onramp for new players.
2) in-person coding tests at the same Pearson test centres where people take most of their Cisco (and accounting, and ...) exams today. Not as expensive or inconvenient as you might think, but not the cheapest and easiest, and it certainly has the same concerns re. surveillance and identity theft
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.
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.
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.
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.
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.
> I’m pointing out what I believe to be ridiculous gatekeeping.
I am not gatekeeping. I am stating that we collectively exist in a professional caste and that will go away or lose influence if you let it do so. Other professional castes do this exact same brain exercise and that is why they have protections in place.
> Some people try to cling to their specializations and cry “class warfare” when threatened.
I'll be blunt and just state that I am post money and not remotely threatened by this stuff anymore. I am observing that software engineering as a profession is blindly giving away a ridiculous amount of leverage in the world - in the form of dollars and influence, the value of their labor - and more crucially doing it to themselves.
I will be fine whichever way this shakes out, and I don't really have a dog in this fight short of having spent decent time in the OSS space and finding it sad what it is turning in to.
It's not meant to be taken negatively, and is purely a term that I was choosing to represent "hey, you all need to consider better coordinating/representing/holding the line as a group".
I consider this mode of thinking selfish and anti-progress. It’s pretty much exactly what Americans decry about unions.
If you consider a union to be a "bad thing" then we are likely going to talk past each other for eternity.
I am fortunate that software has paid me well to work on problems I am enthusiastic about solving. I understand that a lot of people on e.g. the Ford assembly line are not there because they want to make excellent cars, they’re there because they need a job. I acknowledge that I have no idea what it’s like to structure one’s life and priorities this way; it is just completely alien to me to align oneself with the task rather than the mission. And I believe that task-identification mindset is why we hear about resistance to electrification because EVs require fewer assembly steps, or Teamsters cutting power cables at trade shows if the vendor dares to plug in a TV themselves.
Software developers should not ossify. Nowhere have I said that LLMs as a tool - used by those in this profession! - should be shunned. I was pointing out that people being totally okay with those outside our profession, those without the necessary skillsets, directly doing our work not only devalues our work.
What is sad about oss? What is it turning into? I will say far before ai came in oss was a few arms deep in the techfluqncer culture where motivations were driven by gh stars and follow counts rather than a genuine interest. Or maybe what was a genuine interest became twisted as the culture changed.
I do care, it's why I commented what I commented. ;P
I already acknowledged that "caste" is an incorrect word choice and I could've done better there, but my core point remains unchanged.
Who claimed that?
That was the context:
"Fwiw, a non-technical employee in my workplace has begun submitting ai-generated prs to internal repos I maintain & they're of excellent quality, "
Well, that's already the case because you cant just call yourself an engineer and start signing off on projects. It's a legally protected title in a lot of places. You need a professional license, and can face legal liability for your decisions.
Software engineering is not engineering. Software craftmanship or even architecture would be a more accurate term. There are no devs that will go to prison if what they produce has, say, a major vulnerability. That alone disqualifies it from being engineering. There's no licensure, there's no liability, so already software development is not gatekept in any way like other engineering disciplines.
I mean, just go into an aerospace engineering office and say you want to move fast and break things, you'll get laughed out of the room.
No idea what you mean by class solidarity. There are only two; the capital owning class, and then everyone else (the working class). Most devs are working class just like everyone else.
Unless you're proposing that software should be gatekept to the level of other engineering disciplines?
This was part of the implication of my point, yes.
> No idea what you mean by class solidarity. There are only two; the capital owning class, and then everyone else (the working class). Most devs are working class just like everyone else.
Yes, albeit a highly compensated portion of the working class. Software engineers should protect their own field a bit more.
> Unless you're proposing that software should be gatekept to the level of other engineering disciplines?
I do not like or want to use the term "gatekeeping" here, but yes, I think that software engineering should be held to a higher standard. You can't have it both ways.
The only problem in your theory is that none of those things has anything to do with "engineering".
You're arguing that a surgeon who removes a burst appendix in a hygienic environment isn't "practicing medicine" if they aren't licensed to do that in the jurisdiction where it happens. You'd have to be insane to believe that.
Engineering means solving problems. A license is a license. They're unrelated concepts.
Firstly: class solidarity. The apparent death of (or at least notable decline in) class solidarity is popularly lumped upon software engineers because they're relatively highly paid, but it's equally as absent in newly created positions (mainly within the IT sector) at all salary levels. There's been a concerted effort to erode class awareness in the private sector for the past 40+ years & it's been effective across all sectors, mostly in newly created job categories without pre-existing union culture. It's in no way specific to software engineering as a role nor to high salary positions.
Secondly: ai & llms. Currently these technologies are monopolised by corporate entities, with models generally being far too inefficient to democratise, so it's obviously tempting to conflate their very existence with their owners, but if you're singling out ai usage as some kind of affordance to the capitalist class you're missing the woods for the trees. You need to separate ownership from existence/usage.
Yes, I agree. We are, however, on a site and in a thread that is dedicated to the role of software engineering, so I don't really care about the wider discussion at the moment.
My sole input here is that software engineering has not protected itself as a field, and it will now pay the price for that.
& my point in raising that this is not an issue that's unique to software engineering is to argue that the demons you're proposing software engineers protect themselves from are distractions from the root cause. You're proposing software engineers need to protect themselves from something that's specific to their field when the problem is holistic.
I have not said it's specific to their field. I've just been specifically commenting on that field.
(The lack of solidarity is perhaps specific to the field)
It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM contribution, attitude of 'I care about building while others lose time in details', refusal to engage with potential flaws, and so on.
It is surprisingly different to what I'm used to from senior devs, which behave like they always suspect their own work is flawed and half assed. Like impostor syndrome was reversed.
- Receive a huge vibecoded PR for complicated new feature.
- Complain that this needs some design doc to figure out the right approach first.
- Author says no need for design doc, easier to have vibed implementation and discuss the concrete code instead of abstract document.
- I disagree (obviously), but review the PR with feedback along the lines: this entire approach is flawed, throw this out and start over.
- Author gets defensive, says "but this is already working and ready, let's just merge".
- I tell them there is no chance in hell this is getting merged. They go sulk to their manager that I'm not interested in helping them launch.
I think that's probably the key - sounds like you are at a place that rewards "launches" and not long term maintenance and so you are ruining their KPOs or promo packet or whatever.
The original post sums it pretty well, such big output inherently meant big effort, which was a proxy for good faith. Now that's gone.
I never trust my own code. And one of the motivations of trying to be fluent with my editor, is to be able to quickly look at it when a bug is reported. I also don’t trust another person with their description of their code. Any surprise, and I’m looking at the source if it’s a available.
It's 100% an issue with the people with submitting these PRs. So, if someone has a history of having no issue with breaking project rules (let alone being arrogant about it), it should be a massive red flag about the person for any possible employer or future collaborator checking their profile, etc.
Why people are wilfully destroying their own reputation like that is beyond me. It's infinitely better to have no activity at all on your profile than to create a track record of bad behaviour.
There's no other correct fix - why do you care which pen I used to write it?
Why is it surprising that some people who expect results without spending any effort also feel entitled to receiving gratitude without putting in any thought?
(And the whole "miffed AI wrote a shitpost" thing)
I don't think that follows. They expect things to improve, they do something about it and might (unreasonably) be frustrated by what they think is a policy that stands in the way of quicker progress. The first part is certain, the second part less so, and the third is just speculation.
It's clear that open source project are struggling to understand what is going on and coming up with plans – like everyone else – but clearly there are better and worse ways to proceed in this new world, if popularity, adoption and progress are things you want to focus on.
I would be more sympathetic if they actually spent meaningful time on these contributions and could maybe see an argument for wanting their work to be given due consideration (lots of caveats here), but from what I’ve seen that’s the exception rather than the rule with a lot of these case.
If a feature and ignored, it can forked to provide more value to the users.
If unaccepted bugfixes, the maintainers are just silly. They need to be forked off.
Only stoneagers would say that they are better than a good AI.
I guess I am a stoneager.
As an AI-cynic I am much more interested in learning how AI solves my problems (of which I have many), not how it can revolutionise programming. How about it revolutionises me not experiencing task paralysis first.
> Only stoneagers would say that they are better than a good AI.
projection? lack of confidence in your own abilities? why make such a sweeping statement
My point is that with AI, where the actual code generation is easy, there's little value in community PR contributions anymore.
I am only a bit above average and I clearly still write better code than a good AI.
The only question left in my mind, alas, is whether that is enough to earn a living.
I mean: it is clear that in every domain except for programming, a talented XYZer can do better than an appropriate LLM trained to do XYZ (except perhaps in some absolutely exhausting pattern recognition tasks).
So I am not sure why we see our own field as different. A sort of inverted Gell-Mann amnesia?
Fork away. If you want to put in the meaningful effort required to maintain and improve upon a project as significant as Godot, and feel that AI is a mechanism you want in order to do so, go for it. Clearly, the maintainers don't feel that that's the best approach to create the product they want to create, and they are not required to accede to the sense of entitlement of the community.
Nowadays it's even more trivial.
And a community is more of a burden than an advantage nowadays. Users are ok, but a community not so. See python, perl, ruby, node and countless others.