Timestamps:
00:00 Intro
00:36 Sponsor: TuxCare
01:46 KDE’s AI policy
06:42 Existing AI policies
10:06 Going further on AI
12:58 My stance on AI
17:05 FOSS projects: yes or no to AI?
28:02 Sponsor: Tuxedo Computer
Timestamps:
00:00 Intro
00:36 Sponsor: TuxCare
01:46 KDE’s AI policy
06:42 Existing AI policies
10:06 Going further on AI
12:58 My stance on AI
17:05 FOSS projects: yes or no to AI?
28:02 Sponsor: Tuxedo Computer
The KDE AI policy is pretty explicit about AI code contributions should have the same quality level as non-AI. So the tech debt concern is a nothing.
And there is no dependency risk, you can trivially switch from Claude to opencode w/ self hosted models, the AI companies have literally no moat to lock developers in. Its also entirely optional to use AI.
Environmental concerns are valid, but tech debt and dependency are silly arguments.
Sounds like a PR nightmare of AI tech debt to me. You’re participating in the Shareen effect of the AI slop world.
Feel free to explain how “no change in acceptable quality” generates tech debt.
Wtf is a shareen effect?
The top result is some missionary story https://www.mnnonline.org/news/shareens-story-a-divine-domino-effect/
I’m not talking about vendor lock-in, I’m talking about a system that has destroyed the training path for juniors, and the fact that as developers lean on AI more their skills atrophy and they become dependent on that workflow (regardless of provider), and their ability to introspect a code base decreases because they had less time learning it during the build-out phase.
You can be mad about that, but it has nothing to do with KDE.
Sure, it’s an everywhere problem. But it would be nice to see more projects having strong preventative policies.
I think it is more important to leave people the freedom to decide for themselves. It’s not an opensource project’s place to tell its contributers how to work as long as the contribution fits their requirements. No one’s opinion is worth more than the other one’s.
“Individual freedom” as a primary driver over the last decades/centuries is what’s got the USA into the state it’s in now. I’d rather focus on something that contributes to the collective good.
Except that the KDE contributors would be directly supporting it financially and giving it training data.
Also directly financially supporting technofascists and oligarchs.
Also directly financially supporting the destruction of the environment, stealing of water and electricity from the poor, bribary of politicians both local and international, and destruction of communities.
LLMs run by corporations are terrible and toxic, with very few exceptions. We also can’t have a good faith argument and not acknowledge that the overwhelming majority of devs use those corporate datacenter models and not locally run models powered by home/company solar panels.
The training path still exists, its just up to developers just need to take it.
And script kiddies have always existed and contributed to OS. There has never been a “you must be this clever/qualified/awesome to contribute” bar.
If anything, AI may actually raise the bar for some developers…
This is bar none the dumbest take I’ve heard about AI yet.
Have you read some of the absolute garbage that open source developers have put out? Not every developer is a code genius, there are some complete cowboys out there.
AI may not make you or I better, but for some people, it definitely does make them much more capable, even if they aren’t still at the level that we’d prefer.
It kind of doesn’t though, if only for the fact that companies aren’t hiring juniors anymore because they just put their former workloads on everyone else because AI
Thats a concern in the corporate world, but open source has been built on generations of enthusiasts learning as they go. If they managed to learn and develop their skills 20years ago without AI, then they can still do that today.
My most successful project is a python and later rust project that I started long before I ever touched either language professionally.
This was an issue in the computer science field well before LLMs, though (like in many areas) they did pour gas on the fire.
TBH I think it’s more of an issue for paid software. Manpower and burnout is the bottleneck for FOSS projects, and contributions are largely thankless, hence I think amongst the people who do contribute, there will be more of an interest in truly learning the codebase.
Multiple FOSS projects have been complaining over the last year or so that they are getting swamped with LLM-generate PRs that are often low-quality, but still require a similar amount of time to review. LLMs are shifting extremely lited FOSS core maintainer capacity away from development and into time-wasting code reviews with a high rejection rate.
Well, yes, and that’s exactly what the KDE policy is addressing. They’re saying “we are going to reject vibecoded PRs, unconditionally; so don’t bother submitting them.”
The biggest contributor to the backlash of the proposed policy was the additional aspect explicitly not requiring AI used in a PR to be disclosed, regardless of its quality (and which is unrelated to the ability to quickly reject obvious slop PRs).