I'm not sure that it is practical to make vibe coding secure enough by default to be called secure by default. You could hang linters of the process and use the results to refine your LLM prompts (perhaps even in an automated manner to an extent), but that'll never be perfect. The LLMs people are using were trained with public code, and that public code has many security issues that may be repeated by the LLM along with the good stuff, and new classes of problem pop up regularly so you have to keep those linters up-to-date which somehow avoid false positives that might cause them to flag decent code and accidentally cause a reprompt in a way that makes it worse.
Vibe coding is just outsourcing, just not directly to other humans, or like giving tasks to an enthusiastic but somewhat bumbling junior dev —¹ you have to verify the results for security issues, style matters, and just to make sure it actually works, whether you have pushed the task to a local human, a remote human, or an environment munching LLM, before using it.
--------
[1] Oh no! An em-dash! Am I an AI and nobody has told me?!
Disclaimer: I work in Developer Relations at Replit.
I'm sharing this because it highlights a critical gap in how we're supporting the next generation of developers.
AI-powered coding tools have opened programming to countless people who might never have touched code otherwise—vibe coders are bringing fresh perspectives and solving real problems.
But we're not setting them up for success when it comes to security. Many of these developers don't have traditional CS backgrounds that would flag potential vulnerabilities.
They're learning to build by doing, which is powerful, but they need tools and platforms that guide them toward secure practices by default.
This isn't about limiting creativity or slowing down the "build something cool" energy that makes this space so exciting. It's about building guardrails and educational resources that help vibe coders develop secure coding intuition alongside their technical skills.
We have an opportunity to make security accessible and automatic for this growing community of builders.
While the core point is correct, and I am not arguing against it in the slightest... the concept of "secure-by-default" seems implausible because different systems have different requirements for what needs to be secure in the first place. I'm sure you could put in a scan that gives a warning that tells people if there is exposed PII, but beyond that basic level, how would a tool know the intent of any data access?
The goalpost should probably be set closer to automated communication of what data is accessible to what users and roles, which lets the users decide whether or not the observable results of a security scan do or do not match their intent.
Vibe coding is just outsourcing, just not directly to other humans, or like giving tasks to an enthusiastic but somewhat bumbling junior dev —¹ you have to verify the results for security issues, style matters, and just to make sure it actually works, whether you have pushed the task to a local human, a remote human, or an environment munching LLM, before using it.
--------
[1] Oh no! An em-dash! Am I an AI and nobody has told me?!