Writing software by interacting with a model has become the norm. You describe what you want, working code appears, and you deploy it. The speed is real, and I won't argue with that.
The problem is something else: working code and secure code are not the same thing, and a model optimizes the former.
What a Model Gives You by Default
When you request "an admin panel," the result usually includes authentication. Technically. In practice, I've seen things like this:
if (!authHeader || !authHeader.includes('Bearer')) {
return unauthorized()
}
That doesn't validate anything. Any header containing the word "Bearer" passes. The code seems secure, passes a quick check, and leaves the door open.
The pattern repeats itself with variations:
-
Tokens that are
base64(email)instead of a signature. Anyone can create them. -
"Setup" or "fix" endpoints that reset credentials without prompting, created to start the project and never deleted.
-
Secrets with default values —
process.env.SECRET || 'dev-secret'— that in production sign real sessions with a public string. -
Drafts accessible by their URL because the query never filtered by state.
None of these are exotic bugs. They are reasonable shortcuts used during development, which no one ever looked at again.
Why it happens
It's not that the model is sloppy. It's that you asked it to work, not to survive.
An endpoint that resets the admin password is exactly what you need on day one. The model provides it. What it doesn't tell you is that this endpoint must be terminated before the site goes online, because that part wasn't in the query.
And when you ask "fix the authentication error," the model fixes the error. It doesn't audit the other seven routes.
What to Do
Ask about the attacker, not the function. "What can someone without a session do against this endpoint?" produces very different answers than "Does the login work?"
Inventory endpoints periodically. Listing each route and answering who can call it takes ten minutes and uncovers what accumulated without anyone deciding to do so.
Be wary of things called setup, fix, debug, or test. They are scaffolding. If they remain in production, they are an attack surface.
Check dependencies. An outdated framework can accumulate dozens of known vulnerabilities, including remote code execution. A patch update usually closes them without breaking anything.
Let secrets fail loudly. If an environment variable is missing, it's better for the application not to start than to use a default value that someone can read on GitHub.
What Doesn't Change
The speed of vibe coding is genuine and shouldn't be sacrificed. But security doesn't just emerge from a smooth conversation: you have to explicitly ask for it, and you have to look again.
The interesting thing is that the same model who wrote the shortcut usually finds it when you ask the right questions. The tool isn't the problem. The question is.