GrapheneOS imposes a set of restrictions on how generative AI can be used in our project and community. It isn't forbidden but rather we imposed rules based on actual issues.

Posts made in our forum, chat rooms, issue tracker and the rest of our project must be written by humans. There's an exception from this rule for translation and accessibility features. That means commit messages, pull request messages, bug reports and feature requests are expected to be written by humans, not a machine.

We largely disallow making posts entirely based on AI model output. For example, we get a lot of forum threads from people with concerns based on AI model output and will typically provide a quick answer followed by locking the thread and then eventually removing it.

It isn't permitted to submit pull requests or issue reports created by an AI model without fully understanding it. It's fully allowed to file issues found by an AI model if there's a human who understands it and writes the report.

We do not want issue reports entirely generated by an AI model or which were written by a human and passed through an AI model to provide analysis. It's usually incredibly inaccurate and we would greatly prefer the user's explanation of what's wrong. We want a description of what happened, a crash traceback if one is available and optionally a subset of logs emailed to logs@grapheneos.org if people are comfortable doing that after triggering the crash or another issue. We sometimes request it.

It can sometimes be useful to analyze an issue with an AI model but it usually isn't. It also definitely isn't useful to do it with a free or cheap model available without either paying for it or running it on very expensive hardware. In general, users do not have access to anything useful to analyze it. We don't want people to keep converting their issue reports into slop. We want what a user pasted into the AI model interface rather than what an AI model produced as output from that.

Frontier models are very good at finding bugs but it requires an experienced developer to babysit it and extract the useful portion of the output. Important bugs are often found but mixed in with a bunch of low quality output. The details on the issue and especially proposals to fix it are often wrong. It's still very useful and finds many real issues. The volume of real vulnerabilities being found this way in Linux, Chromium, Firefox, Postfix and countless other projects is quite scary.

It isn't a good idea for people to point a model at an open source project and then start submitting bug reports to it. People need to be able to confirm the issues themselves with relatively high confidence before reporting it. It's okay to make some mistakes but it should not be the majority of what's reported. We do want people to report these kinds of security bugs to us but the signal to noise ratio is far too low right now. Even frontier models spew out contrived nonsense and fabrications.

We want people to report very serious Android Open Source Project security bugs to us but we can't handle a lot of minor issues. We don't generally need Chromium security bugs reported to us because they handle those far more quickly and have a far better system for releasing it. Linux kernel security bug reports are useful if they refused to fix it (arm64 kASLR) or it didn't get backported to the LTS. GKI LTS being behind the LTS is a separate problem we'll be addressing ourselves again soon.

We have high standards for code being merged into GrapheneOS, especially for code in critically important parts of the project. Most of the changes made to the OS are to critically important parts of the code. It takes a long time to get features to meet our standards. There's usually a lot of back and forth review with many improvements requirements for anything significant. External contributors shouldn't try to take on major features without talking to us and planning that out with us first.

Going from having a working implementation of a feature to code we can merge often takes a long time. It can take months or even more than a year. It doesn't always work out. Sometimes we decide a feature ended up being too invasive or risky for other reasons and don't want to include it. We'll often do rewrites. Contributors need a full understanding of what they've submitted and need to be prepared to make substantial changes including fully rewriting it multiple times. AI slop isn't accepted.

We don't forbid using AI models for writing code but pull requests largely created that way will typically be rejected or skipped due to not meeting our requirements. It needs to be well written code which appears to be regular code written by a human regardless of the level of AI assistance involved in making it. It should not look like AI generated code. We do want to know if AI models are being used and how they're being used rather than people using it but not telling us they're using it.

GrapheneOS is based on projects heavily using AI including the Linux kernel. Cellebrite, NSO and other exploit developers are using it to exploit these projects. They currently have a major advantage thanks to AI which will likely be turned into a major disadvantage over the long term. It's getting a huge backlog of bugs fixed and creating enormous pressure to make systemic improvements.

Here's what Debian adopted, which is a similar idea but much more permissive:

https://www.debian.org/vote/2026/vote_002#texte

@GrapheneOS if this policy keeps up I'm going to have to stop recommending graphene to people the same way Debian is no longer safe for casual users. You're throwing out your base audience. This sucks and you know it.

@bekkaboo Linux itself is heavily using AI models. Therefore, every Linux distribution moving to recent kernel versions is heavily built on top of using AI models. Creating a Linux distribution not heavily using it would require a hard fork of the Linux kernel and many other projects.

It's unclear what would be accomplished by banning AI for a tiny portion of the code while continuing to use Linux, AOSP, Chromium and hundreds of other projects heavily using it. We'd still be benefiting from it.

@GrapheneOS
> Creating a Linux distribution not heavily using it would require a hard fork of the Linux kernel and many other projects.

The pitfalls of using LLMs are well known and documented. Hard forking everything would probably be for the best really. Leaning into it, out of pear pressure is really the bad move here (unless you think there's more to it than "pear pressure")

@zm We're using it to raise the quality of our code. Our current usage for the core OS is entirely for extra passes of code review and to find issues in our existing code. We began doing it after receiving a bunch of valid reports from external contributors of issues found with AI models. Several issues we fixed due to external contributors scanning our code with AI were serious issues including crashes and bypasses for protections. A lot of that was reviewed by over a dozen people already.

@zm Our Camera app was originally written in Java with the Android Views framework. It was ported to Kotlin years ago using Android Studio which was a non-AI machine translation. It has never been idiomatic Kotlin. It was written by a junior developer and we didn't apply strict enough code review or standards due to lack of resources.

It's ridiculous to portray experienced developers overhauling the app with everything going through a lot of review as writing slop because one uses AI tools.

@zm Our initial Camera app needed to meet the bar of being better than AOSP Camera which was horrible and the codebase was a huge mess. It succeeded in providing that and has been a decent camera app since then.

Camera needs a massive overhaul to meet our much higher current quality standards for the user interface, features and especially code quality.

We're doing the same for the incredibly outdated AOSP apps. Those are being nearly entirely overhauled with far higher quality code.

@GrapheneOS
I still think you have to look at what this means from a cultural perspective.

Even if this is all true (i.e. you were getting amazing quality output from LLMs), it doesn't answer for all of the negative externalities of AI use (just look at why Codeberg banned it). You have for the most part called balls and strikes on a lot of the controversy and misconceptions surrounding this project and other similar projects.

It's given you a good enough reputation to get the user base you have and even land you in the news because of how secure it is. AI companies on the other hand have a terrible reputation and many people are jumping ship to something like GrapheneOS because of AI (and how it's being forced on their users)

If you can understand the reasons that people want to use GrapheneOS then you'll understand why people don't want you to allow AI use in this project. None of the technical challenges you're facing will even matter if your users can't trust you

@GrapheneOS
> It's ridiculous to portray experienced developers overhauling the app with everything going through a lot of review as writing slop because one uses AI tools.

To my previous point, even if you feel that they're not writing slop because of AI use. They still are, because of the reputation they have of being used for that purpose (even among the best developers). Historical precedence shows that using AI over time will de-skill and you'll just vibe code eventually

@GrapheneOS
If you're looking for inspiration or feel like people are demanding the impossible, look at @elementary

This is OS development without AI.

@zm @elementary It's a Linux distribution based on Ubuntu. Linux and Canonical are both heavily using AI. Debian is permitting using AI with fewer restrictions and oversight than we impose.

They're not working on anything similar to we are or in a similar space to us. They do not have to defend against what we do.

Basing a project on other projects which are using AI is not avoiding using AI. Banning it for the downstream work is a tiny fraction of the OS.

@GrapheneOS @zm @elementary
>Basing a project on other projects which are using AI is not avoiding using AI. Banning it for the downstream work is a tiny fraction of the OS.

This sort of false dichotomy only serves to push folks to surrender any agency they have. I've never agreed with every aspect of every decision of the projects my work relies on, what a ludicrous claim! Y'all literally criticize Google's choices regularly, but you claim to operate differently and to a higher degree of quality within your project.

That is the reasonable and realistic level of agency anyone expects from a project.

The real stress from this situation is idk what to switch to from gos... Might just finally have to resort to a dumb phone if Android's "most secure" OS is this thick...

Side note, stop acting like you need AI to effectively operate in SWE. You don't, and if you just can't resist it then say that and drop it. Honestly if it was some offline model strictly being used for security reviews I wouldnt care that much, but watching y'all immediately start paying money to some of the most evil corps in the world, then have a meltdown when people are understandably concerned is enough to finally push me away.

GrapheneOS and DigitalOcean in 1 day... Gonna be doing a lot of infrastructure work here for a while 😭

@MonKaiju @zm @elementary We're doing the direct opposite of reducing quality. It's helping us catch things we're missing in our own code review. A couple of our newly hired app developers using it themselves is also going well and they're doing a high quality overhaul of the badly aged AOSP apps. That includes fixing long term latent vulnerabilities in apps like AOSP Messaging which we didn't know were there before.

Plenty of people already attacked us for using Pixels or AOSP due to Google.