Anyone else noticed the increase of Vibe coded plugins flooding the market?

[El°HYM]

I would say & maybe take closer a look at when this topic was originally posted. We already went past vibe coded or not and already reached the point; how much AI was involved, is it good, is it useful, is it secure to use; will there be any updates in the future?

For me it has become kind of hard to spot, or lets say also needs a closer look to really figure out whats going on. A few hints might be generic GUI, an AI generated Site and info text. Yet, then we been having these for some time now and certainly not all generic looking plugins are vibe coded. To be honest all of this kind of just made me letting go of picking up every new shiny or not so shiny plugin, or every decent looking freebie. Most of us will have enough of those by now anyway, I guess.

[noiseresearch]

How can one identify vibe coded software?

What are the telltale signs?

I think I can tell from the GUI of the product and the website of the developer. Quite often same-ish colours themes across different websites and products. And often the GUI seems unbalanced not well laid out. Making a good GUI is something AI can't cover that well or maybe plain lack of imagination on the vibe-coder side. Not sure. But yeah the GUI and website are my first indicators.

[jamcat]

First you have to define what "vibe coded" software is.

There is a very clear definition :

Vibe coding is a software development workflow where you describe your app, website, or feature in plain language.

It's well explained here :
https://www.ibm.com/think/topics/vibe-coding
https://en.wikipedia.org/wiki/Vibe_coding

And what percentage of the software has to have been described in plain language for it to qualify as vibe coded?

[noiseresearch]

First you have to define what "vibe coded" software is.

There is a very clear definition :

Vibe coding is a software development workflow where you describe your app, website, or feature in plain language.

It's well explained here :
https://www.ibm.com/think/topics/vibe-coding
https://en.wikipedia.org/wiki/Vibe_coding

And what percentage of the software has to have been described in plain language for it to qualify as vibe coded?

I do not think it's about any numbers. Let me quote a quote from that Wikipedia article

If an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding in my book—that's using an LLM as a typing assistant.

So if you are almost clueless about what you are coding and you just prompt till you have a running plugin that's not a good practice in my view.

[legendCNCD]

Can we have list of identified vibe coded plugins. That'll sort 'em out.

[Tiles]

Sort out what? AI assisted coding has long become real.

[kerfuffle]

On the KVR new products page, if a new developer you've never heard of releases 5 products at once, chances are they are vibecoded. Even if there are several weeks between releases. No human developer is that quick.

[Funky40]

How can one identify vibe coded software?

What are the telltale signs?

I think I can tell from the GUI .......

Similar to me. Mainly: the ever same type of too small sized fonts in ever same bigger boxes.

Then: Same colour schemes ( quite good ones in fact for my taste). Ever sameish knobs......just the whole visual appearance.

But to be fair, it is possible to just use vibe coding for the GUI itself. There are such guys.

[jamcat]

See, here’s the problem with all this “vibe-coding” panic: In most software companies bigger than one or two people, there is a Technical Lead or Lead Software Engineer. This person will design the software conceptually, develop algorithms, logic and data flow, and document features for the programmers to implement. A Lead Software Engineer may not even write a line of C++ code themselves, and might only “describe the software in plain language” to one or more code monkeys (programmers) to implement.

An algorithm, by the way, is a universal step-by-step description of a process. It is described in plain language. An algorithm is what gets turned into a C++ function or Java method by a coder.

So essentially, a vibe coder is a Lead Software Engineer, and the AI agent fills the role of the code monkey. AI coding tools are to the point where they are on par with a top-level programmer. And of course there have always been plenty of programmers writing code who are not top-level. Sorry, but that includes most indie developers.

So the issue with “vibe coders” really comes down to whether or not they actually have the background skills and discipline necessary to be a Lead Software Engineer and logically design a piece of software inside and out and then communicate it clearly and methodically, not whether or not they can write their own C++ code.

Side note: a Technical Lead or Lead Software Engineer will typically review the submitted code, though that’s probably less important when a human coder with human error isn’t involved. Plus, you could just as effectively direct the AI to review, refactor, and optimize the code for you.

More importantly, software needs rigorous testing. Not because of bad code so much as for unexpected, unforeseen, and unaddressed behavior in the design. First with unit testing, which AI can do, and later with hands on beta testing, which AI can’t, because AI doesn’t have hands. With AI assisted coding, more time should be spent testing than coding. That is one area of development that pure “vibe coders” without real-world software development experience may not fully grasp.

TLDR; the potential pitfalls of vibe coding isn’t going to be the code itself. That will be solid. It’s the soundness of the design and the thoroughness of the testing where things may fall apart. But these are the typical failings of inexperienced developers, not AI coding agents, and these pitfalls are neither exclusive to vibe coding nor an inevitable consequence of it.

[midi sentinel]

Don't forget to check domain registration dates. That tells you a story of its own.

[sandandpaint]

"And of course there have always been plenty of programmers writing code who are not top-level. Sorry, but that includes most indie developers."

I taught in the IT dept of one of the world's top 100 Universities, we normally sat around the middle, so these students came out of high school as 'good' students
About 10 % of the students were really great, next 20% or so were pretty good, next 20% still employable and I would not have employed the bottom half for anything involving coding. The best of those might cope with simple support roles with some supervision

There are far fewer good IT people than the public think. On the other hand basic coding is much simpler than the public think and much of it is incredibly standardised.

[Tiles]

Indeed

AI mainly hits the large middle of the skill distribution, meaning the kind of work that is highly standardisable and repeatable. The very strong engineers remain essential because they define the problems, shape the system design, and make the critical architectural decisions. At the lower end, roles become less relevant because those tasks are exactly the ones most easily automated.

In short, AI does not reduce the need for good developers. It reduces the demand for average-level implementation work.

There is a downside though, and I see this as a real danger for future developers. If AI takes over a large share of the low-level implementation work, developers may gradually lose touch with how systems actually behave under the hood. That missing hands-on experience can weaken intuition about performance, memory, concurrency, failure modes, and all the small but important details that only become obvious when you have implemented and debugged them yourself.

This also affects debugging skills. A lot of strong debugging ability comes from pattern recognition built through direct exposure to real implementation problems. If that exposure shrinks, developers may become more dependent on AI not just for writing code, but also for understanding what went wrong when something breaks.

Over time this can create a kind of abstraction gap: systems can still be built quickly, but the understanding of their internal mechanics becomes shallower. That is risky, because real-world software reliability often depends on being able to reason about exactly those lower layers that are no longer regularly seen.

So while AI raises productivity at the top, it also raises a structural question for the future: how do we preserve deep engineering intuition in a world where most of the implementation work is increasingly automated.

[jamcat]

In short, AI does not reduce the need for good developers. It reduces the demand for average-level implementation work.

Precisely. AI is eliminating entry-level “code monkey” positions. But the demand for software architects and designers is increasing. I think the reason for that is because AI coding has created more capacity for software development, so naturally we are going to need more people designing software to build.

There’s a lot of fear and loathing for AI out there right now, but I don’t think it’s going to end jobs at all. Quite the opposite. It’s just changing the future job descriptions.

[Tiles]

Indeed

AI mainly hits the large middle of the skill distribution, meaning the kind of work that is highly standardisable and repeatable. The very strong engineers remain essential because they define the problems, shape the system design, and make the critical architectural decisions. At the lower end, roles become less relevant because those tasks are exactly the ones most easily automated.

In short, AI does not reduce the need for good developers. It reduces the demand for average-level implementation work.

There is a downside though, and I see this as a real danger for future developers. If AI takes over a large share of the low-level implementation work, developers may gradually lose touch with how systems actually behave under the hood. That missing hands-on experience can weaken intuition about performance, memory, concurrency, failure modes, and all the small but important details that only become obvious when you have implemented and debugged them yourself.

This also affects debugging skills. A lot of strong debugging ability comes from pattern recognition built through direct exposure to real implementation problems. If that exposure shrinks, developers may become more dependent on AI not just for writing code, but also for understanding what went wrong when something breaks.

Over time this can create a kind of abstraction gap: systems can still be built quickly, but the understanding of their internal mechanics becomes shallower. That is risky, because real-world software reliability often depends on being able to reason about exactly those lower layers that are no longer regularly seen.

So while AI raises productivity at the top, it also raises a structural question for the future: how do we preserve deep engineering intuition in a world where most of the implementation work is increasingly automated.

That said, this is not new in principle. In the automotive industry, engineers also do not build entire cars themselves anymore. Work is highly abstracted and modular, yet deep system understanding is still required. The question is whether AI-driven abstraction stays as transparent and stable as traditional engineering layers.

[sandandpaint]

There’s a lot of fear and loathing for AI out there right now, but I don’t think it’s going to end jobs at all. Quite the opposite. It’s just changing the future job descriptions.

Our faculty head once said that most of our students were kids who previously would have got a job in 'the bank' but now elected to do IT because that would give them a nice stable job. The glory days of good money for being very average but in IT are over. Faculties will shrink a bit as those lower level students look for somewhere else that holds out good job prospects.
An historical example would be your average web designer - hardly anyone needs them now, no Uni teaches it anymore.
And with the car example - few workers are needed to make a car in a modern factory compared to just a few years ago - those jobs are gone

In the main the entire point of AI is to shed workers in every industry where that is possible. The economic problem that causes - a huge class of underemployed - will cause massive social disruption in countries that hate the idea of sharing