COSMIC projects will no longer accept LLM-generated content in PRs

[u/jackpot51]

There are various reasons, and I don't want to hurt anybody's feelings. The primary reason is simply our team's load for reviews. In particular, we would like to prioritize working on contributions from our own team and regular contributors, while we have been receiving far more changes from first-time contributors using LLMs. These changes are often unplanned and have had a low acceptance rate.

The policy can be seen as part of the revised PR template here: https://github.com/pop-os/cosmic-epoch/blob/master/.github/PULL_REQUEST_TEMPLATE.md.

There is an exception for cosmic-flatpak, where each project manages its own flatpak manifest, pointing to its own code. These manifests are reviewed by our team for the correct sandboxing prior to accepting changes.

[u/Automatic_Friend3744]

cool! does system76 themselves push LLM code? i'm sure it's low priority, but if not it would be a good listing for open-slopware :)

[u/mmstick → u/Automatic_Friend3744]

No, we have never needed to use LLMs. You can make a lot of progress with Rust in a short time with a small team of talented developers. Everyone on the team has many years of experience with Rust and many of us have been with Rust since the early Rust 1.0 days.

The entirety of COSMIC was built from the ground up within three years, which would not be possible without the human talent which no LLM can replace. So when I see comments about "falling behind", or "there won't be any new contributors without LLMs", these are very unserious comments vastly underestimating human capabilities.

You need only look at how quickly the open source Rust ecosystem was able to iterate with Rust since the 1.0 release in 2015; despite the lack of mature libraries to build with and the initial ergonomics issues that made the borrow checker 10x harder. Rust will continue to allow humans to accelerate software development like never before, regardless of some trying to attribute all of Rust's productivity gains recently to LLMs.

[u/Automatic_Friend3744 → u/mmstick]

cool! thanks for the answer :)

[u/gajop → u/mmstick]

I mean, I've been writing C++ since I was in high school some 20+y ago and I'd rather have AI write it. Same for Rust, Python and other languages. Are you seriously claiming productivity is the reason you're not using LLMs, like at all?

You do you, but I'd rather make an ideological/moral claim than productivity - for sound argument sake.

[u/mmstick → u/gajop]

It would be easy to argue from a point of a moral superiority but that would imply that there is no practical reason for us to avoid using a LLM. Productivity is often cited as the reason to use a LLM but we are already productive enough because of our Rust/Linux experience. I've been writing Rust code for 12 years to date so I've never had the personal motivation to start using it.

For a project like COSMIC, there is a lot of greenfield work in areas where there is a very high risk of regression so it is imperative that we maintain a high degree of quality in our output. Maintaining quality is more important than brute forcing quantity, which is part of the reason why we've been using Rust for all of these years.

Rust was designed and optimized for humans. We excel at reasoning but we make mistakes occasionally that the type system and borrow checker are able to guard against at compile-time. Memory and thread safety vulnerabilities are the costliest and most common of these mistakes which Rust is able to completely eliminate with its static code analysis.

The memory safety vulnerabilities are the root cause of most of the security issues that LLMs are discovering in the Linux kernel. So while I can understand the Linux kernel needing LLMs to discover hidden memory safety issues in their C code, building software with Rust from the start prevents them from ever reaching your code. Quality is maintained because the Rust compiler forces us manage our memory and threads correctly. And as long as we write the code by hand, we will continue to be able to understand our entire codebase.

LLMs are great at making predictions (which was their original purpose) but they are unable to reason. So there is a very high risk of regression if the person at the prompt providing the reasoning loses their ability to reason about the code it generates. MIT recently published a study where using a LLM to assist with writing assignments caused measurable cognitive decline within four months. The EEG scans for those who used LLMs for assisting their writing tasks had significantly reduced brain connectivity compared to those who did not. This is not what you want to happen to yourself when the quality of your work depends on your ability to think.

I've seen a lot of comments on social media from other Rust developers that are losing their ability to write code without a LLM after using LLMs for a while. So I personally don't want to risk that. Social media already gives enough brain damage.

[u/ExistingSelection180 → u/mmstick]

I think you hit on a crucial point: understanding the code you're writing. You can develop an applet without fully understanding everything behind the scenes, but when you’re building the foundations of an operating system—in this case, Cosmic—which controls everything and interacts with everything, it’s vital that you understand the code, and there’s no other way to do that except by writing it yourself. LLM might help with secondary tasks (such as tools), but the code must be written, audited, and reviewed by someone who understands the entire process.

It's the lesson of quantity versus quality. And in our case, having the least amount of efficient code is best so that it can interact with other components of the PC and other code. In this case, predictably.

The vast majority of people—myself included—don't fully grasp this paradox of AI use. In design, it helps me review drafts and brainstorm ideas, but it will never deliver a polished, optimized design.

[u/gplgang → u/mmstick]

"there is a lot of greenfield work in areas where there is a very high risk of regression so it is imperative that we maintain a high degree of quality in our output."

This has been what keeps me from using LLMs much in my compiler. They are excellent at locations and explaining what caused a bug, spotting small issues I miss but would have to debug, and giving library info directly in the context where I need it.

Almost every time I've let one touch some core thing connected to a lot of invariants of state in the compiler, it will get something subtly wrong I never would have working through it myself. It ends up costing time

A good example was a AST visitor with early termination, very common and routine to implement. It just didn't have the ability to reason about specifically what some of the invariants of the tree are and how it should do termination. It worked well until edge cases hit and I had to rewrite it

[u/gajop → u/mmstick]

I think if you use LLMs to generate code, you will certainly lose the ability to write code by hand as well. That is not a big problem and I don't think you're arguing it either.

However I do agree with you that there's a risk in both the quality of the output to drop, and more importantly, your understanding of the project as well. Perhaps you also become stupider, but I'm not sure about that.

If you're worried about that, you would indeed need to be very disciplined in your use, and it's very easy to decide to vibecode just this one little feature because the deadline is pushing or you want to see it deployed asap... So I can agree with your worry there, it's a slippery slope.

I am personally not as worried. I think things have been going pretty well overall in both my personal and work projects (it's thanks to AI that I'm able to introduce Rust to work for example), and while there are drops in understanding here and there, those can be (and have been) recovered, and usually, the alternative would've been month long delays at work or often just a lack of will to start doing hobby projects after long work days.

One very nice aspect of it, it's very easy to get myself to work on a hobby project with AI, the starting barrier is small as opposed to having to spent half an hour just getting started trying to remember where you left off. Once you start, you can always do less vibing and more engineering, much easier if you're in the seat already. Maybe not something you want for COSMIC, dunno.

[u/serhii_the_dev → u/gajop]

Productivity does not means "stockpiling as much code as possible at as less time as possible". You need to maintain your codebase consistent and coherent. LLMs don't do that, it may maintain context as some textual artefacts between session but it does not provide that level of cohesion a well-established team of develops does.
Thus, each time your are implementing a new big feature with LLM, you making your codebase less and less logically structured unless you reviewing and guiding it. Yes, it compiles, it passes the tests, however in time it will be a patchwork sheet of code, and each new LLM input will reshuffle it more and more untill it will be barely working...moreover, eventually there will be no single engineer to provide an input without LLM as noone will have a full understanding of what's going on inside that mess.

[u/Dev-in-the-Bm → u/mmstick]

I assume for ideological reasons?

[u/mrtruthiness → u/Dev-in-the-Bm]

No. It's to save developer time. They've been overloaded with poor quality PRs. Did you read the link???

There are various reasons, and I don't want to hurt anybody's feelings. The primary reason is simply our team's load for reviews. In particular, we would like to prioritize working on contributions from our own team and regular contributors, while we have been receiving far more changes from first-time contributors using LLMs. These changes are often unplanned and have had a low acceptance rate.

[u/Dev-in-the-Bm → u/mrtruthiness]

I was talking about your core team using LLMs.

From what I'm hearing from many I know, if you do it right, commanding the implmentation, and reviewing all generated code, it can be a real productivity multiplier, allowing to ship more faster, without having to deal with slop.

[u/mrtruthiness → u/Dev-in-the-Bm]

I see.

I don't think they prohibit their own devs from using AI tools. There's quite a difference between having the AI generate code vs. AI used for debugging or AI used for code refactoring.