Requesting a clearly-defined NO LLM Policy

[lanerussell]

Hello,

I'd like to talk about your AI policy. Below are some reasons why using AI can result in poorer code quality:

Poor Code Quality

Vibe coding / agentic workflows result in poorer code quality, and relaxed oversight practices. These effects may be compounded by the common practice of using additional LLM-based tooling to provide code-reviews.

• How I Dropped Our Production Database and Now Pay 10% More for AWS
• Claude Tested Everything Except the One Thing That Mattered (AI agent refuses to follow explicit instructions to test createPost() in increasingly erratic ways)
• Amazon calls engineers for a “deep dive” internal meeting to discuss “GenAI”-related outages
• GitClear has released reports in 2024 and 2025 indicating a worsening of key code quality metrics correlating with increased LLM adoption.

Deskilling

There is increasing evidence to show that LLMs negatively impact developers' coding abilities:

• Brains show less activity when completing tasks with LLMs compared to completing tasks with search or completing tasks without digital help.
• Developers who use early-2025 LLMs reported higher subjective performance, but were measured to have lower objective performance. This gap between subjective and objective performance was considered notable.
• In an Anthropic study, learners using LLMs demonstrated lower learning rates on average compared to learners not using LLMs.
• A recent study uses the term "cognitive surrender" to describe the way humans tend to offload key critical thinking skills onto LLMs, even when the output is wrong.
• There are anecdotal reports of LLM users forgetting how to code.
• A paper entitled "AI Assistance Reduces Persistence and Hurts Independent Performance" from April 2026 by academics from MIT, Oxford, UCLA, and Carnegie Mellon showed alarming evidence that performing a variety of tasks with the help of AI for only 10 minutes causes "inpaired unassisted performance and reduced persistence". The researchers noted that "although AI assistance improves performance in the short-term, people perform significantly worse without AI and are more likely to give up"; they also pointed out that "these findings are particularly concerning because persistence is foundational to skill acquisition and is one of the strongest predictors of long-term learning".

Infosec risks

LLM usage results in massive security holes.

• Meta Security Researcher's AI Agent Accidentally Deleted Her Emails
• Moltbook's "vibe-coded" breach is the future of security failures
• In a study evaluating over 500k code samples, LLM-generated code was found to contain more high-risk security vulnerabilities than human-generated code
• LLMs make up package names, making them vulnerable to incorporating malicious code in "slopsquatting" attacks (Arxiv study)

What You Can Do

I'd like to kindly suggest implementing a strict "No AI" policy. This can also help with what seems to be larger and larger influxes of low quality drive-by PRs by AI agents.

You can find other projects that have taken steps to say no to AI here:
https://noai.starlightnet.work/list.html

For a specific policy, I can recommend the following policies for inspiration:

• wafrn's Contributring Doc

• Loupe's Use of Generative AI Policy

Like many others, I have relied on Matrix/Element services for private communication with friends and family. I hope to see continued dedication to robust encryption and privacy supported by reliable tools.

Thank you for your contributions to open and safe messaging.

[bxdxnn]

As I've said in the previous issue:

OK, if Element forbids LLMs, will you please contribute all of the future code/bug fixes/features that would be done by the Element developers and the community with the help of LLM?

Right now, we see a lot of contributions coming from the community with the help of LLMs, no matter if it was vibecoding or simple questions/reviews using agents. Would you consider Element of "better quality" if we revert everything that was done with the help of LLM?

Element has a very strict review process regarding the code quality and the UI/UX. It doesn't matter if you've used AI or not, the work you're submitting must be of the expected quality.

The articles that you've linked are examples of a very blind vibecoding, and such outages or catastrophic regressions because of vibecoding are very unlikely in FOSS where the code can be seen by everyone in the world. The "Meta Security Researcher" is also a very ridiculuos situation where a person that was appointed to do the "AI safety" at Meta can't even do basic things like having an execution permission control and queues a "Stop don't do anything" prompt instead of just typing the /stop command.

This is also very biased towards a single "no LLMs" view: why you haven't considered and linked numerous articles about the benefits of agentic LLMs, or at least relying to some common sense? For example, there's a lot of routine/boring processes in software development that would be a perfect job for the LLM agents.

[lanerussell]

My main intent is to start a discussion here that will lead to a clear policy being published on the use of LLMs in Element/Matrix, whatever that policy may look like. I've presented some of the concerns surrounding code quality when using LLMs. Perhaps others could discuss the questionable legality of the training data scraped by LLMs, or whether code generated by LLMs can be legally copyleft- (or otherwise) licensed. Concerns around environmental impacts, ethical implications, etc.

I'm sure others will have constructive feedback about the possible benefits of LLM use. As I said, the main thing that would be great to see come out of this discussion is a clear policy.

[Susurrus]

The current policy allows them (as it doesn't explicitly state they're banned), that should be clear. Generally policies things are a restriction, they don't explicitly allow, as it works like this for many projects. It sounds like you want them to be banned. I don't personally do, but I don't know what productive discussion is possible here: the devs already said they're fine with it as-is.

[bxdxnn]

element-hq/element-x-ios#5625 and other PRs fixes this issue.