Vibe coders, they don't think you can build safe products. The best conversations came from people who disagree: opposing views are a gold mine for value and finding common ground. Keep building, shipping and learning. https://x.com/i/article/2111722766017708032
Vibe coding is a slur. Prove them wrong.
There's a story doing the rounds on this app. A coffee chain CEO vibe-coded an internal dashboard for his 132 stores, and the sensitive data ended up sitting in the source code of the login screen. The comments are exactly what you'd expect. Laughing. This is why vibe coders will never build real products, they say.
I've heard this song before. They don't believe you can build safe, secure products. They think you aren't capable. They think the tools you're using will never be enough to build an actual product. And now they have a word for you.
First, what it actually means
Andrej Karpathy coined "vibe coding" in February 2025, and his definition was specific: you describe what you want, the AI writes the code, and you fully give in to the vibes. You don't read the diffs. You paste the error back until it runs. It was a confession, not an insult. A way to play.
Then the word escaped its definition. Now anyone who builds with AI gets called a vibe coder, whether they read every line or not. A term for a lazy habit got stretched into a label for millions of people learning to build. That's how a description becomes a slur: when it stops describing what you do and starts dismissing who you are.
The slur
Peter Steinberger, the guy who built OpenClaw, one of the most capable AI agents out there, said it plainly on OpenAI's Builders Unscripted: "I think vibe coding is a slur." His point is that the term implies what you do is easy. It isn't. It's a skill, like guitar. You don't sit at a piano once, sound bad, and declare the piano trash. He has been saying it for a while, and he said it again this month.
Andrew Ng has called the term "unfortunate". Developers everywhere are writing that "vibe coder" has become a way to dismiss anyone building with AI, no matter how carefully they work.
That's the tell. The word was never about the code. It's about gatekeeping.
The democratisation of technology
Here's what is actually happening while they argue in the comments. Every generation gets one tool that moves the fence. The printing press did it for words. The internet did it for distribution. The smartphone did it for media: a kid with a phone could suddenly reach more people than a TV station. AI is doing it for software.
The barrier was never intelligence. It was access. Access to a computer-science degree, to a team, to capital, to ten years of syntax drilled into your hands. That barrier is falling in real time. Karpathy saw it coming before he ever coined the term. Back in January 2023 he tweeted: "The hottest new programming language is English." He meant it literally, and he said this new paradigm could expand the number of programmers on earth to 1.5 billion people.
Sam Altman has a betting pool with his CEO friends on which year produces the first one-person billion-dollar company. One person. Whether or not it happens, the fact that serious people are betting on it tells you what the tools now make possible.
That is why the slur exists. Nobody gatekeeps something that doesn't matter. They aren't laughing because the tools don't work. They're laughing because the tools work, and the moat they spent a decade digging is filling in. The revolution is not coming. It's here, it's in your browser tab, and it does not care what they call you.
The things we used to lose sleep over
Here's the part the comments skip. A lot of what made traditional engineering hard was never the code. It was everything around the code: the servers, the patching, the certificates, the secrets, the protection at the edge, the scanning. A team had to own all of it, and every piece was another way to get breached.
Platforms like Lovable, Replit and ChatGPT Sites now take a large share of that work off your plate. Not all of it, a large share. I made this argument in the comments, and here is what their own documentation says they handle.
Lovable
Lovable runs a Quick scan automatically every time you publish. It checks your database access rules, including tables with no row-level security, known vulnerabilities in your dependencies, and any MCP server your app exposes without authentication. The Deep scan goes through your whole codebase for access control flaws, open endpoints, injection, leaked secrets, payment tampering and weak authentication.
Paste an API key into the chat and Lovable detects it, then guides you to store it in Secrets and call the service from server-side code instead of the browser. Secrets are encrypted at rest and kept out of logs and interfaces.
Sources: docs.lovable.dev/features/security and lovable.dev/security
Replit
Replit's documentation spells it out as a shared responsibility model. Replit owns the infrastructure published apps run on, including maintenance and platform vulnerability patching, protection against DDoS and application-layer attacks at the edge, and encryption in transit and at rest. You still own reviewing the code, choosing who can see and edit your app, and describing the business logic.
On top of that, Replit says every customer gets their own isolated Google Cloud project, development and production databases are separate, and passwords and API keys are never exposed to your code or the AI. Security Agent scans your app before you deploy, and Auto-Protect watches published apps for newly disclosed vulnerabilities, prepares a patch and sends you a link to apply it.
Sources: docs.replit.com/features/security/shared-responsibility-model and replit.com/security
ChatGPT Sites
OpenAI describes ChatGPT Sites as ChatGPT building the site and handling the code and hosting. You describe what you want, review the preview and publish. Some guardrails come built in: in Enterprise workspaces public publishing is off by default until an admin turns it on, and Sites that use connected apps run on each visitor's own accounts and existing permissions. One caution straight from the docs: every deployment URL is a production URL, so save a version and review it before you deploy.
Sources: help.openai.com/en/articles/20001339-creating-and-using-chatgpt-sites and learn.chatgpt.com/training/walkthroughs/build-a-shareable-site
The old checklist, crossed off
In traditional engineering, you or your team had to:
- Provision and maintain servers, and patch the platform underneath your app
- Set up encryption for data in transit and at rest
- Put DDoS and application-layer protection in front of the app
- Keep API keys and passwords out of the code and out of the logs
- Watch for newly disclosed vulnerabilities in your dependencies and ship the patch
- Run a security review before every release
Between them, the platforms above say they cover each of these, or put it one click away. That is a huge amount of weight off a person building alone, and it is exactly why people can now spend their attention on the product, the customer and the problem.
Be clear about what the platforms say themselves. Lovable's docs say the scans help but cannot guarantee complete security and that you remain responsible for your app. Replit's model says the same about reviewing code and deciding who gets access. That is the deal. They take the plumbing. You own the product.
Let's be honest about traditional software engineering
Traditional software engineering gave us code review, threat modelling, testing, least privilege. Good things. Learn them. Respect them.
Traditional software engineering also gave us Equifax. Not vibe coded. Certified engineers, proper process, whole security teams, and the personal data of 147 million people walked out the door because nobody patched a known vulnerability. The biggest breaches in history were built the old way, with standups and sprint planning.
The old way was never a guarantee. It was just slower at failing.
And the gatekeepers learned the same way you will: by shipping broken things and getting woken up when they fell over. Nobody handed them wisdom. They earned it in production. So will you. You'll just earn it faster, because your tools let you ship and learn at a speed they never had.
Where they're right
Security is not only code. Your app can be clean and still get hurt in deployment: open databases, lazy network rules, keys in the wrong place. The AI won't architect your network for you unless you ask it to. A security professional made that point in the comments, and he is right.
He went further. The platforms' scans are good, he said, but they are less than 5% of the job. He has seen Lovable sites with databases reachable from the front end and no protection on them, and an internal company platform that should have sat behind a VPN. Take that seriously. Read your scan results instead of clicking past them. Ask the AI to lock down the database, and ask it again.
And if you paste errors back and forth until "it works" without understanding any of it, you are building a house of cards. They are right about that guy. Don't be that guy. The difference between a joke and a builder is not the tool. It's whether you own what you ship.
They are right about the law too. This morning Bumfluffski took the conversation from security into compliance. His point: if you understand POPIA, and you have ever been called in to fix a data breach, the "the platform handles it" take is a dangerous one.
Then he gave the simplest example. In South Africa it is illegal to collect Google Analytics data if a visitor has not accepted cookies. It has not been fully enforced, but the penalties run up to R10 million in fines and ten years in jail. Not for the developer. For the website owner.
His estimate: nine out of ten South African websites are not compliant, and when numbers get that big, someone gets made an example of. And that was before every person with a Claude subscription started shipping new sites.
He is right, and the law is the law. But hear what that actually means. A wave of new builders needs guides, auditors and fixers. That is not a reason to stop building. That is a market. My reply to him:
His answer this morning: he is not trying to demean anyone. He writes, consults and does pro bono work because AI makes dreams more accessible to people who never had the means to afford them. That is the conversation worth having. Educate and encourage, do not demean.
They're arguing with a version of AI from six months ago. Lovable runs security scans on what you build. Ask Opus 5.5 to build a feature and it flags issues and security risks as it goes. The frontier models get better at security every few months. The jokes haven't been updated. The tools have.
The prompt pack
Steal these. Run them before you ship anything. The first one I got from @ShudufhadzoRSA, and it catches more than your ego wants it to.
1. "Run a security audit on this repo." Then: "Fix all audit findings, and instruct me what to do when I'm needed."
1. "Before you write any code, give me a threat model for this app. Who attacks it, what do they want, where are we weakest?"
1. "Find every secret, API key and credential in this codebase and move them into environment variables. Then tell me how to set them in production."
1. "Attack my authentication and user roles. Assume the user is hostile. Show me what breaks."
1. "Audit my dependencies for known vulnerabilities and pin the versions."
1. "Review my deployment: database access, network rules, backups. What would you lock down first?"
1. "Review this code like a senior engineer who does not like me. Be brutal."
1. "Write the tests a senior engineer would demand before merging this."
I'm speaking to you
I'm speaking to you. The idea executor. The internal tool creator, hacking together the thing your company should have built years ago. The shipper. The one with a notes app full of ideas and a laptop that opens at 11pm when the house goes quiet.
Every builder you admire started as a person with an idea nobody believed in. The only difference now is that the distance between your idea and a working product has never been shorter. You don't need permission. You don't need a co-founder who can code, or a degree, or an investor. You need a problem you care about and the stubbornness to see it through.
You are fortunate. You're building with ever-evolving tools that give you speed and an edge nobody had five years ago. Use it. Go build that idea. Let nobody stop you. Go learn the lessons the hard way, the same way they did, except you get to learn them at ten times the speed.
A year from now there will be people who used these tools to change their lives, and people who spent the year arguing in the comments about what to call them. Be the first group.
They'll keep laughing. You'll keep shipping. Prove them wrong.