The need for secure-by-default vibe coding

2 mattpal 2 6/11/2025, 3:17:54 PM mattpalmer.io ↗

Comments (2)

mattpal · 18h ago
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.

https://x.com/mattppal/status/1928106325613105370

codingdave · 17h ago
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.