The Trust Cost of Creation: Vibe Coding Without Blowing Yourself Up

Collins picked "vibe coding" as its 2025 Word of the Year, and honestly, that tracks. Building software by chatting with an AI has gone from novelty to default in about eighteen months. The wild part isn't the speed. It's who's doing it. Marketers, founders, ops people, domain experts who never wrote a line of code in their lives now make up roughly 63% of vibe coders. The wall between "person with an idea" and "person shipping an app" has basically fallen over.

Which is great. It's also where the trouble starts.

The thing nobody wants to talk about

Studies put the rate of security vulnerabilities in AI-generated code somewhere between 40 and 45%. Pick whichever end of that range comforts you, it's still a coin flip on whether your weekend project is quietly leaking something it shouldn't.

The reason is structural, not malicious. Large language models are trained to make the thing work. They optimize for "this runs and does what the prompt asked," not "this handles a crafted payload from a stranger on the internet." Best practices, threat modeling, the boring defensive stuff. That's not what the loss function rewards.

For people buying vibe-coded tools, this is the real problem. App directories are flooded with weekend projects that may or may not be maintained, may or may not be safe, and there's no easy signal for which is which. For people building them, it means a safety mindset isn't optional anymore. It's how you avoid shipping something that becomes someone else's problem.

Here's how I'd think about it.

1. Treat the AI's output like a draft, not a decision

The shift you want to make is from vibe coding (the AI says it works, ship it) to AI-assisted engineering (the AI drafts, you review). The difference matters because these agents can take real action (file system writes, API calls, deployments), and "I didn't read the code" is not a defense.

A few habits that help:

• Don't deploy what you haven't tested. Functional testing is table stakes. Read the security-relevant bits even if you have to ask the AI to explain them back to you.
• Learn to spot the obvious smells. You don't need to be a security engineer to notice that your API endpoint has no authentication, or that your app trusts user input it really shouldn't. Pattern recognition gets you most of the way.
• Plan for the day after launch. Errors will happen. If your app has no logging, no error handling, no way to find out something broke, you're going to find out from a user, and they're going to be unhappy.

2. Your dev environment is part of the attack surface

When you let an AI agent loose in your codebase (Cursor, Claude Code, Bolt, whatever), you're handing it real access to real things. Treat that accordingly.

• Keep secrets out of prompts. API keys, credentials, proprietary logic. None of it belongs pasted into a chat window. Workspace context can leak. Researchers recently found hundreds of exposed instances of an AI coding assistant leaking keys and credentials. That's not a hypothetical.
• Watch what your tools are doing. You don't need an enterprise observability stack, but you should know which files your agent can read, which commands it can run, and which network calls it's making.
• Scope permissions tightly. The agent that's helping you refactor a React component does not need access to your production database. Sandbox it. Give it the minimum it needs.

3. Be honest about what you built and how

A trustworthy ecosystem needs trustworthy signals, and right now those signals barely exist. As a maker, you can help by being upfront:

• Welcome the vetting. Directories and platforms that actually review submissions are doing makers a favor. "Reviewed and verified" beats "uploaded last Tuesday" every time.
• Say what you used. Naming the AI tools and models in your stack lets users assess risk on their own terms. It costs you nothing and buys you credibility.
• Think about the second-order stuff. Privacy. Data handling. What happens to user data if you stop maintaining this. The maker who's already thought about these questions stands out from the maker who hasn't.

---

Vibe coding isn't going away. It's how a lot of software is going to get built from here on out. Maybe most of it. The people who do it well are the ones who pair the speed of AI generation with the skepticism of an engineer who's been burned before. Move fast, ship things, but read the diff.