If you hired an intern or spent 10 nights yourself you could also have added a FLAC player to your imaginary app. Making bad product decisions is not inherent to the use of LLMs, and whether adding a useless feature is a waste of development effort has always been subject to discussion.
Extra features don’t necessarily make your app slower and heavier on RAM, that issue has been solved by the concept of dynamic loading - 40 years ago.
It would be the genetic fallacy to reject all AI generated plugins purely because they were written by AI. Being AI generated may have previously been a decent heuristic for being slop but with models improving it can become increasingly difficult to tell the difference between human and AI output. If the concern is quality/security then I think that it would be safer to assume all code is unsafe until it is reviewed by some kind of crowdsourced peer review system.
I’ve read through everything here and can see both sides. I think it’s good, but at the same time bad, that people can simply create plugins here and post them, even if they contain “potential” security vulnerabilities that could compromise a Discourse installation.
A bit off-topic.
There’s another forum software provider (WoltLab) that has a plugin store, for example. Before any release, plugins and themes are reviewed by the team. Maybe that would be an idea to implement something similar here. However, the question always arises of who would do the reviewing, and I can imagine that this would require a significant investment of time and personnel.
I can with 100% confidence say thats absolute not a viable idea, for us to review every third party plugin and theme. (Or at least, not manually by a human)
It has been interesting to see everybody’s own takes on why this transparency may be important, both on moral and security grounds. Personally, I don’t care if something was made by a software engineer of 30 years who has been doing Ruby since the dawn of time or by little Timmy with zero coding experience. If it is 100% slop-coded[1], I won’t be using it, that would be hypocritical of me. I understand why it is popular but it’s just not something I will be getting behind. If these models were trained ethically and weren’t causing component shortages along with an epidemic on AI-generated media, my sentiment towards these models might be less negative, but that is not the world we live in.
Security concerns for plugins globally are also valid and not limited to “this was made by AI”. That is a hard problem to tackle and is out of scope for this topic though, this topic is merely a suggestion to require tags on fully LLM-generated assets.
“vibe-coding” or “agentic development” are words I refuse to use ↩︎
I still don’t see the problem this is trying to solve. Can anyone give me an example of a vibe coded plugin that was slop, insecure or a performance hog? One that should have never been advertised here because it was total crap and a waste of everyone’s time?
And if there actually are examples, are they enough to be a problem?
Sounds to me like it would about as useful to have some kind of self-certified checklist for themes: how much testing have you done, are you ready to receive reports on quality and security, will you be responsive to feedback.
Or indeed, what is your development process, in no more than three sentences.
The truth-value of the responses won’t be worth much, but the difference between themes which are self-certified and those which are not might be a signal worth something, to the person thinking of installing the thing.
I for one, never vibe-code any application, project or software I make. I use AI chats for bouncing off ideas, or clarification, but never the full project. More manual, definitely, but at least I know what I’m doing and not blindly entrusting it to another entity.
But I have seen AI-supported coding grown a lot over the last few months. It did originate as poorly-written or laced with vulnerabilities, perhaps, but I would say it has improved tons since then. The vibe-coded designs are still pretty recognizable (gradients, borders, emojis, etc), even in some plugins I’ve seen on Meta. But what’s important is that the author shared it for their own interests, and the interests of the community. Not for someone to stomp it down and labelled as ‘slop’, but because they have found genuine success in that plugin and want to share it for other forums out there who seek to obtain the same functionality.
I see your point on ethical concerns of AI, but that seems geared towards AI in general, like companies slicing up books, mass water and electric usage, etc. You mention:
But how does that correlate to the use of AI-made plugins or TCs? If you don’t like AI, sure, don’t use it. But the programming landscape as changed dramatically with AI’s introduction, and so things like plugins and TCs will too. Will you stop using Discourse entirely now, knowing that some code was help written by AI? I wouldn’t, because I know there’s still people behind it.
So will it still be accurate to call it ‘slop-coded’ and boycott the use of the term ‘vibe-coding’ (personally, I see no issues with the latter phrase)? Perhaps not. Is it too harsh? Yes. As much as I think you would dislike this, sometimes we have to adapt. Does that mean I will now make AI-generated TCs and share them? For me, no. But does that mean I will view it as a alternative, not to be shunned or looked down on? Yes. And I’m trying not to. So I hope you can too.
Just sharing a curated article related to this topic:
Trail of Bits argues AI agents are most useful in audits for building custom tooling, not just finding bugs. In a Miden zkVM audit, they used Claude and Codex to create an LSP server, decompiler, static analyzer, and Lean model, uncovering a high-severity signature-forgery bug and 95 Lean proofs that caught two subtle issues.
Because agents make ambitious side projects cheap, the economics of audits have shifted toward tool-driven reviews that can secure complex systems far more thoroughly than before.
i use ai to assist me in developing my plugins and components. use them at your own risk but i won’t be labeling them with any disclaimer or tag, no different than Discourse core does. i control the agents, review the code (sometimes with another agent or llm set of eyes to help), and test them. you’re free to not use them, but i’ve more often seen poor code written entirely by a human than by ai.
Indeed, I think the traditional approach to knowing the quality of something is to check the reputation of the entity which made the thing. Personal reputation works well, when a person is active in open source. Generally, if someone has previously done good work and been responsive, they will continue to do so.
You still need to do the leg work. Even when using LLMs to create deterministic tools you need to verify that these tools indeed perform the correct actions, and not just do something which statistically is often right. Using LLMs to create deterministic tools is better than just prompting LLMs with markdown files hoping the result will be the same (still legally and ethically problematic). However, if that deterministic tool is blindly maintained with LLMs the new releases have the risk over losing its deterministic behavior over time.
As Snyk showed In their VulnBench report, auditing with LLMs is not really reliable:
Using AI agents to write Discourse themes seems really appropriate to me.
That would be great. It might also be worth figuring out the ideal setup for someone who doesn’t have a strong programming background. I’m guessing it would be something like an AI agent with access to a development Discourse instance and a good skills file. That and some kind of automated security review.
Of course, Sam and the team are the undisputed authority and can correct me if I’m wrong, but after much experimentation on my part and happy to give something back in return, I’ve learned over the past few months that Discourse Vibe and good use of the harness is what is suggested and by far the ideal situation to start with.
It is also possible to work with certain tests on Github or even using Discourse Container, but the development capacity is limited, especially for those less experienced like in my case.
It is possible to ‘vibe’ code for Discourse using AI and one just has to verify or delegate the final verification before presenting the work done or using it on production.
For my part, I am not technically qualified to review code, but I am enough to direct functionalities, how and where to adapt them, and ask about what specifically generate or polish so I imagine someone will come and openly contribute to the security and reliability (human review always) of the code so that it can be used by the entire community. Not only in Meta but Discourse in general. It has always been my goal, from my initial prompt.
Years ago I thought I would not have been able to even direct an AI to make the code for me. And today, with the caveats and legitimate controversy that exists regarding this, it is a reality.
