Pop!_OS bans AI-generated code from much of its codebase

zzzeek

banning AI from PRs because you're swamped with too many low quality PRs, definitely. We pretty much are doing this with SQLAlchemy. If I'm going to have a small fix or improvement coded by an LLM (which I do all the time), I want to prompt the LLM directly, rather than having someone trying to pad their resume forward my communications onto their LLM via PRs. What's the point of that?

ItsMattyG

I don't see how this will survive the attacker/defender gap as ls get increasingly good at cyber security and finding 0 days... but maybe it's an obscure enough is it doesn't matter?

lkramer

I had a PR in flight that got closed because of this. I had an issue with passwords in the network applet for the VPN and had used Claude to help me identify and then come up with a fix. I did spend a lot time handcrafting and making sure the quality was good, but I respect their decision and no hard feelings, but as someone who have struggled to find time and opportunity to contribute to open source it was a small set back.

brink

I also have found that AI has not lived up to many of its promises and have dialed back what AI gets control of. My projects were turning into unmaintainable messes. The people who say coding is solved aren't paying attention.

holoduke

Doing that will put you put of the market. I am certain of that.

VCFundedGenYer

Thank god. Tired of these orgs blindly and stupidly allowing them (Debian, cough).

sdcfgy

Same trouble we have. Some clever person says to use AI agents for code review. 100kloc commit got flagged through on Friday. Taking this week off. Not my circus. Faith is the problem. Extraordinary claims must stand up to scrutiny. They do not.

mahboi

I still wanna see what Slop OS looks like. Go full AI spam making a Linux distro from the kernel up.

sippingabonedry

Completely performative. You build your OS atop thousands of open source packages, many of which contain AI generated code. Are you going to audit them one by one and remove offending packages? What about the ones you won't remove because the OS would be irreparably broken?

winrid

I wonder if the issue is mostly the code or the AI written PRs and people using AI to talk to the maintainers. I personally just ban anyone doing the latter, I don't want to talk to opus more than I already do lol

whatsThisBtn4

Well this project is dead then. I have a hard time knowing if anti AI is a mental illness or propaganda coming out of China. Unironically. Separately, why would anyone use a Debian based desktop OS? Your $11 Amazon mouse won't work. An Nvidia card won't work. Just use Fedora.

onesandofgrain

As they should. If you can tell it's AI, it shouldnt be part of any codebase.

teekert

"... many of the AI contributions were not planned and showed little understanding of the software architecture. So the team wants to "prioritize working on contributions from our own team and regular contributors."" Sounds reasonable, even to avid LLM users, I suppose. You have to draw a line. This line is too simplistic, but it'll work, for now.

yegle

This would just push people to maintain their own fork. If I already have an agent to investigate and fix a bug and able to send a PR, the added cost of maintaining a local fork is minimum. In fact I've start doing that myself. Sending PR and convincing the maintainer why the fix is necessary is just too much effort.

YuechenLi

Ok, this may be controversial, but LLM code tokens aren't free, and I run out of my weekly allowance pretty regularly just from doing some fairly heavy projects, so I don't understand why somebody would ever want to spend their own money to make bad PRs on purpose, and I like to assume good intentions from people unless proven otherwise, which means a near blanket ban for LLM authored code for these big open source projects just seemed a bit extreme to me, when the core issue seemed to be that review process/policy should change with the times. For example, I was helping work on an open-source game engine earlier this year with a longstanding text rendering bug dating back to around 2021 that prevents the engine from being production ready, which the community and myself have developed extensive workaround for. So, one day I've finally said enough and got Claude to debug it. It took Claude 10 minutes to find the bug, it was 3 lines of code change in the renderer (yes, three). So, I wrote up the regression tests, documented the bug and opened up a PR for the fix, thinking it'll get merged in like less than a week and then we can all move on. The maintainers received it fairly well on the PR, but the PR sat there for nearly 6 months, unmerged, until it finally closed from a bad squash upstream. I'm pretty sure the bug is still there too. And as a side note, I would be ecstatic if someone wants to contribute to my Github projects with their AI.

northstar702

there is an ongoing thread here on a similar topic from an AWS expert (former AWS CTO) "Apparently, AI doesn't lead to positive results in all software development teams. Customers are asking me whether they should slow down the adoption of AI in their teams. How do you respond to that? Yes? No? " https://www.linkedin.com/feed/update/urn:li:activity:7510679... Feels like part of it is a learning habit, getting proficient in use of the tools (AI agents) themselves, and better workflow around it, but it remains AI is not perfect yet?

cagey

I had a PR closed because of this, one that fixes something that, had it not been fixed (by Claude, based on me noticing and clarifying the failure mode and verifying the fix), would have led me to abandon at least COSMIC, if not the distro. But this has me wondering how COSMIC, which had reached 1.x before I started using it, can mature, and whether I'll remain. I started on Pop!_OS with its COSMIC-less 22.04 version; I chose it as a fairly popular distro having Ubuntu stability while offering a leading-edge kernel. Point being, COSMIC was never the draw for me, and I held off upgrading to 24.04 for a LONG time out of concerns about bugs & stability; eventually 22.04 started experiencing ibus-related problems that forced my hand. Since I am (a) not knowledgeable in Rust, nor (b) conversant in the protocol at the core of this bug, I would never have had the gumption or time to understand and fix the bug. And since the PR is closed, it seems unlikely to even serve as a bug report. In the meantime, others have experienced this bug and are waiting for the maintainers to notice and fix it. I'll just continue to run my fork (so far it has been no burden at all) while I (slowly) decide what direction to take.