There is a kind of laughter around vibe coding now.
It starts when someone has built an app with AI and then meets JSON for the first time. It appears in screenshots of confused Reddit posts, broken auth flows, insecure databases, hallucinated APIs, and code that seems to work until someone asks a very ordinary engineering question.
Some of the laughter is understandable. Software can fail quietly. It can leak data, mislead users, or make a private problem public. If you build a tool that touches other people's lives, "I did not know" is not enough.
But ridicule is a poor form of safety.
It teaches almost nothing. It makes no AI assistant safer by default. It creates no review process, no better defaults, no warning before deployment. It only turns a new class of builders into people we feel allowed to dismiss.
And this dismissal matters, because many of these people are not building out of arrogance. They are building because something in their world needs repair.
Eliezer Yudkowsky once wrote:
"Power comes from having something to protect."1
That sentence is the cleanest way I know to describe the best of vibe coding.
A teacher wants a tool that fits her students. A journalist wants to compare documents without exposing sources. A kindergarten director wants a safer way to coordinate parents, staff, allergies, schedules, and emergencies. A small NGO wants to replace a spreadsheet that has quietly become an organizational risk. A volunteer group wants software that follows the way people actually help each other.
These people see problems from the inside. They know the texture of the work, the small frictions, the missing screen, the one button that would save an hour, the one form that should never have asked for that data in the first place.
That does not make their code safe.
It makes their perspective valuable.
One of the reasons Vibe Coding Space exists is PapoNox, an accessibility project for blind musicians. Not as a counterexample only, but as an origin story.
Petar's work on PapoNox began from a concrete accessibility problem: blind musicians should not have to reconstruct a complex visual interface element by element before they can work in professional creative software like Logic Pro. The deeper idea is intention-based access. A user should be able to express a musical or operational intention, and the system should translate that intention into a reliable, confirmable action.
That is not "just an app idea." It is lived knowledge becoming software design.
It showed us something important. Some software does not begin with a market gap. It begins with a person standing in front of a world that was not built for them and saying: this should be otherwise.
That is also why the label "vibe coder" is dangerous when it becomes too easy.
In How An Algorithm Feels From Inside, Yudkowsky writes:
"Because we don’t instinctively see our intuitions as “intuitions”, we just see them as the world."2
"Vibe coder" can feel like the world. Unserious. Overconfident. Nontechnical. Dangerous.
But this is an intuition pretending to be a category. It folds very different people into one shape: a founder exposing customer data, a teacher building a classroom prototype, a teenager learning faster than adults can track, a non-profit worker automating a fragile internal process, a professional developer using AI carelessly.
These are not the same person.
When the label prevents us from seeing the difference, it makes us worse at noticing what is actually happening.
The important line is not programmer versus non-programmer. It is whether the builder has the tools, habits, checks, and community needed to test what the software will do in the real world.
LessWrong already has a language for this. In Making Beliefs Pay Rent, Yudkowsky writes:
"Above all, don’t ask what to believe—ask what to anticipate."3
AI-built software should pay rent in anticipated experience too.
Not: does the demo look alive?
But: what happens when real people use it?
What happens when a user enters unexpected data? What happens when someone is not logged in? What happens when the database rule is wrong? What happens when a child uses the tool? What happens when an NGO stores donor information? What happens when AI-generated code silently assumes a business rule that is false?
The danger is not that ordinary people dare to build.
The danger is that the path from idea to deployment often skips the moment where the builder learns what the software means.
Responsibility is not located in one person only.
It sits between the builder, the AI assistant, the generated code, the platform defaults, the people affected by the tool, and the communities that decide whether a beginner is helped or humiliated.
That is why better tooling matters.
This does not absolve the builder. If you ship software, you have obligations. But it also does not let AI labs, toolmakers, platforms, educators, investors, or communities pretend the problem begins and ends with the naive user.
If we give people machines that turn ordinary language into deployable software, then a missing safety layer is not a side issue. It is part of the product.
There is another LessWrong sentence I want to keep, precisely because it is sharp enough to be misread. In Circular Altruism, Yudkowsky writes:
"The primary thing is to help others, whatever the means. So shut up and multiply!"4
At the top of a landing page, without context, this can sound cold. At the end of the argument, it means something better.
Stop performing concern.
Stop enjoying contempt.
Stop treating beginners as the enemy.
Do the practical work that reduces harm.
That is why we are building Vibe Coding Space.
It is meant to be a place between private prompting and public deployment. A place to build, check, show work honestly, ask for help, and find others through topic and project interest rather than algorithmic popularity.
The check should speak in ordinary language: security basics, data protection, possible EU AI Act relevance, legal and organizational risk, unclear assumptions, and next steps. It should not pretend to replace a professional audit. It should tell a builder what is probably okay, what is unclear, what needs expert review, and what should not be shipped yet.
The social layer matters too. No infinite scroll. No attention market disguised as community. No paid boosting that turns trust into advertising. Projects should be found through interests, tags, feedback, and usefulness.
Vibe coding is not only a new way to produce code. It is a new way for people to shape parts of the world with AI.
Through their ideas, preferences, decisions, courage, resilience, and local knowledge, people are turning what they see every day into working systems.
If we interpret them only as reckless amateurs, we will build exclusion. If we interpret them only as empowered creators, we will ignore risk. The better interpretation is harder:
They are new builders using AI to turn lived knowledge into working tools.
They need responsibility.
They need verification.
They need community.
They need tools that help them become careful before harm happens.
The future of AI-built software should be shaped by people who have something to protect, and by systems that help them protect it well.
So yes: shut up and multiply.
Disclosure: I am building Vibe Coding Space, a platform for AI-assisted builders to check, present, and improve their software with more safety, more accountability, and less algorithmic noise.