With the meteoric rise of AI-assisted development, I'd like to propose a "truth in advertising" addition to Community Applications: a voluntary disclosure field indicating the level of AI involvement in a plugin's development.

The Problem

AI-generated or heavily AI-assisted projects tend to share a recognizable pattern of failure:

1. Shallow author understanding; The author may not fully grasp the underlying code, making debugging, edge-case handling, and meaningful updates difficult or impossible.

2. Low author investment; When a plugin takes hours instead of weeks to build, the emotional and intellectual investment is often proportionally smaller and leads to abandoned projects when issues arise.

3. False confidence; AI-generated code can look polished and well-structured while containing subtle logic errors, security gaps, or hardcoded assumptions that only surface in real-world use.

4. Support black holes; When users file issues, authors who don't deeply understand their own code often can't diagnose problems, leaving threads unanswered.

The Proposal

Add an optional field to the CA plugin manifest that authors can self-report. Something like an ai_involvement field with a handful of defined values:

• none - No AI tools used

• assisted - AI used for autocomplete, boilerplate, or minor suggestions

• review - AI used to review, refactor, or improve human-written code

• significant - Substantial portions generated by AI, reviewed by author

• primary - AI was the primary author, human provided direction and testing

This would show up as a small badge or label on the CA plugin card, similar to how donation links or support URLs are surfaced today.

r/Selfhosted has implemented a similar policy and currently allows AI-generated projects to be submitted on Friday's only.

What This Is NOT

This isn't a ban or a quality judgment. AI-assisted projects aren't inherently bad and plenty of great tools have been built with AI help by authors who genuinely understand what they're shipping. Conversely not all human generated content is perfect or without flaw either. Many plugins over the years before AI have crashed the WebUI or caused data integrity issues. This is just about giving users enough context to make an informed choice. A professional, homelabber, or even a new user picking between two plugins deserves to know which one was built over three years of iteration and which was scaffolded and published in an hour.

//EDIT

It's been informed to me that r/Selfhosted often relies on other metrics beyond the self identification. Including showing how long a developer has been interacting with the community / supporting their plugins is a more relevant metric than "look this established developer used AI, must be slop". The more meaningful signal might be developer track record. How long have they been active in the community? How consistently do they respond to issues and push updates? Do they show up when things break? That kind of history is arguably a better indicator of plugin quality than any single flag, AI-related or otherwise. This starts to open the door to something like a developer trust or plugin review system, where instead of making a judgment call based on a snapshot of how something was built, users and the community can see a longer-term picture of how a developer is viewed by the community. I'm not initially solid on that type of system since Unraid is a small community and review bombing would be a trivial thing to sway or create an impact on.

I don't think that has to replace the AI disclosure idea, both can coexist. One gives you a quick data point at install time, the other gives you the fuller context behind it.

Edited March 30Mar 30 by DiscoverIt
added defense of AI, added another approach to end goal, fixed to r/Selfhosted

There’s nothing stopping people from disclosing AI involvement now but they choose not to.

As much as I support this system you have proposed, you are still relying on people being honest and telling the truth.

At the end of the day, it comes down to the user to research developers and browse support forums and installing at their own risk because there is no verification process on plugins or containers (I think?).

What would be helpful is some security guidelines or fundamentals clearly documented somewhere for those wishing to completely vibe code to review and adhere to, or have AI adhere to. It could also be used as a learning tool for those just starting out. I know @mstrhakr has started a plugin guide and I’ve found myself reviewing that from time to time because it saves me endless hours searching forum posts for key words.

If not build on a guideline, I do think some sort of review panel with Community Devs, or higher, should exist as a “slop or not” and security check for all plugins, not just those flagged as AI influenced. This would benefit many aspects of the community but unfortunately it is asking Developers+ to commit spare time that they may not have.

Also, I remember reading somewhere that the Community Developer user class on the forums isn’t just handed out, that’s only given to those developers that have shown to support a good product and I think it should stay that way.

I think if we were able to build a proper guideline (building on what @mstrhakr has already built maybe?) highlighting the important aspects of development and make it visible and easy to access, this would definitely help new and potentially existing developers. Again, the issue being that it’s going to take up someone’s free time.

AI isn’t a quality signal. It’s just another tool. As someone who’s been writing code long before AI-assisted development, I’ve seen this exact discussion come up many times over the years just with different tools each time.

We’ve gone through code generators, heavy Stack Overflow copy/paste, frameworks that hide complexity, boilerplate scaffolding tools, even entire plugin ecosystems where people shipped code they didn’t fully understand. None of that guaranteed quality and neither does avoiding those tools. It’s the same thing with AI. A developer who doesn’t understand what they’re shipping will produce fragile software whether they used AI or not. And someone who does understand their code can use AI to move faster without sacrificing quality.

So the things that actually matter haven’t changed: understanding the code, taking ownership, supporting what you ship, and building experience over time. Not the tools.

Labeling projects based on “AI involvement” risks creating a false sense of confidence. A “none” label doesn’t mean the code is good or safe, and a “primary” label doesn’t automatically make it bad.

By that same logic, we might as well start adding badges for which editor or tools were used whether something was written in Notepad, Visual Studio, or anything else. But we’ve never treated those as indicators of quality, because they aren’t.

They’re just tools.If the goal is to help users make better decisions, track record is a much stronger signal:

1. how long someone has been active

2. how they respond to issues

3. how often they ship updates

4. whether they show up when things break

That’s the kind of context that actually tells you what to expect.

At the end of the day, tools don’t ship software. Developers do.

alot of my stuff is "assisted" more for grammar/spell check.

On 4/1/2026 at 1:09 PM, Lazaros Chalkidis said:

AI isn’t a quality signal. It’s just another tool. As someone who’s been writing code long before AI-assisted development, I’ve seen this exact discussion come up many times over the years just with different tools each time.

We’ve gone through code generators, heavy Stack Overflow copy/paste, frameworks that hide complexity, boilerplate scaffolding tools, even entire plugin ecosystems where people shipped code they didn’t fully understand. None of that guaranteed quality and neither does avoiding those tools. It’s the same thing with AI. A developer who doesn’t understand what they’re shipping will produce fragile software whether they used AI or not. And someone who does understand their code can use AI to move faster without sacrificing quality.

So the things that actually matter haven’t changed: understanding the code, taking ownership, supporting what you ship, and building experience over time. Not the tools.

Labeling projects based on “AI involvement” risks creating a false sense of confidence. A “none” label doesn’t mean the code is good or safe, and a “primary” label doesn’t automatically make it bad.

By that same logic, we might as well start adding badges for which editor or tools were used whether something was written in Notepad, Visual Studio, or anything else. But we’ve never treated those as indicators of quality, because they aren’t.

They’re just tools.If the goal is to help users make better decisions, track record is a much stronger signal:

1. how long someone has been active

2. how they respond to issues

3. how often they ship updates

4. whether they show up when things break

That’s the kind of context that actually tells you what to expect.

At the end of the day, tools don’t ship software. Developers do.

I agree with this take. I don't think that disclosure is the holy grail open-source projects make it out to be. What it does is give maintainers a shallow mechanism to weed out obviously unqualified pull requests without needing to waste their time or creating friction among the other contributors. I don't think this approach translates well to an application store ecosystem, at least not without the issues mentioned above. At the end of the day, disclosure works only as long as people actually disclose something - but in my experience the worst code is usually the one that's not disclosed.

I agree with the premise, but not the solution.

IMO, better to introduce reputation/reviews for developers in CA, and promote these devs and their work above others.

Devs producing crap, AI assisted or otherwise will develop poor/negative reputation, new devs can be labelled as such while building rep, while LT can promote "trusted devs" including it own team.
This should mean the community can regulate and thus promote quality developers.

Similar system could be brought in for containers, but obviously there are a few more factors to take into consideration there.