We've also now started a discussion for the appcenter submission process if we'll allow submissions to our flatpak remote that are known to contain LLM-generated code
https://github.com/elementary/appcenter-reviews/discussions/647
Post
We've also now started a discussion for the appcenter submission process if we'll allow submissions to our flatpak remote that are known to contain LLM-generated code
https://github.com/elementary/appcenter-reviews/discussions/647
@danirabbit fortunately this is going to keep happening and we are going to have to figure it out as a community how to deal with it. It's going to be a crises.
@sri Yeah I fucking hate it here dude
Honestly I don’t like this at all. If you want to learn to write apps please ask for mentorship and join our community there’s lot of people willing to help. But I can’t help but feel like this is a waste of my time because you’re not learning anything this way. It feels gross
I also feel like we need something in appstream so that people in the App Store can know an app was made with an LLM and avoid it
@danirabbit should the Linux kernel itself be included? https://lwn.net/Articles/1026558/
@vincent that’s not a crisis I have the experience or influence to solve
@danirabbit i'll be the @alatiera in this discussion and advocate for just banning anything touched by an LLM
@diegoe Yeah I’ve started a conversation in our discord about if we want to accept this at all in AppCenter, but based on Flathub being typically pretty permissive and probably not willing to kick out big name apps who are now vibe coding, I think we still need some kind of disclosure in appstream. Like I can’t see Flathub delisting Bitwarden etc
Bitwarden is vibe-coded now!?
@mirlo I’ve heard both Bitwarden and KeyPassX have LLM code in them now ☹️ It’s fucking everywhere
Feel free to throw your acks here: https://github.com/ximion/appstream/issues/744
We've also now started a discussion for the appcenter submission process if we'll allow submissions to our flatpak remote that are known to contain LLM-generated code
https://github.com/elementary/appcenter-reviews/discussions/647
I hope you take a strict #NoAI policy. You'll have to block things like KeePassXC, Calibre, and Fluxer (three apps that break my heart).
@terminaltilt We already don’t accept non-GTK apps in our Flatpak remote 😊 this wouldn’t have any impact on apps available from Flathub for example
@danirabbit I'd bet some of the discussion will drift toward "it doesn't matter if it's LLM-generated or not, it matters if it's quality code".
I disagree with that, though. I mean - by all means, reject crappy apps if they're crappy apps, but IMO there are other reasons to reject LLM-heavy projects.
One - if it's vibe-coded/LLM-heavy crap, I am not confident that the maintainer really knows what's in their own app. That has long-term implications.
Two - if it's LLM-heavy, what happens when the price of tokens shoots up in a few years / the maintainer's favorite plagiarism machine shuts down?
Three - why crowd out human-written apps / code with slop? Let people who want LLM crud distribute it themselves.
Sorry that you have to spend some of your limited time on Earth wrestling with all that.
@jzb @danirabbit
I largely agree with point one, just with a caveat being that someone can be competent with AI tools can also understand good code review practices even if it's not going to be obvious to an non developer.
On point 2 if "developers" who rely on AI can no longer maintain their code due to enshitfication, the end result is no different then legit developers that deprecate their code in other ways.
As for point 3, slop is slop. It's better to aim policies to reduce slop vs a blanket ban on AI.
I am not holding a firm view on AI use as it's too early to access it's long term impact. I'm only commenting because it is a pressing issue and it's easy to think emotionally then logically on this subject so counter arguments are a necessity.
@danirabbit was also thinking that but couldn't decide between suggesting a freeform "ai disclosure" or an OARS-like approach so we can list 'code', 'translations', 'branding'...
@GeopJr Yeah that's an interesting point. Being able to build a "nutrition label" would be kind of cool. Can you leave a comment here: https://github.com/ximion/appstream/issues/744 ? Otherwise I'll quote you :)
@danirabbit I'll comment!
@GeopJr appreciate you!