Before AI, I had basic programming skills. Most of my (limited) experience was centered around building basic websites. One of the first personal projects I built with AI was a Code Coach that helped me improve my coding skills. I was not a professional developer by any means, and I still wouldn't claim to be a developer post-AI either.
When I managed a team, it was important to me that I was a little good at all the things my team was responsible for. I knew enough about every expert's domain to ask good questions and trust their judgment. Just enough to engage. Not enough to do the work myself.
AI has made all of us a little good at a lot of things. Vibe coding has made one of those things, building software, trivially easy. Anyone can ship something now. I've come to think of myself as a manager again when I work with AI. My job is to set direction, evaluate what comes back, and decide what's good enough to keep. That's manager work. But the expert team member who'd catch what the AI got wrong is no longer in the room.
If you don't have the literacy to spot what's missing yourself, no one does.
Sometimes I do feel like I am missing out, or I should be doing more. A few weeks back, I read about an experienced CEO who vibe-coded a production-ready app over the course of a few weeks in between meetings. I couldn't help thinking: If he can do that, why am I not?
That app was pulled less than 24 hours after it launched. It couldn't handle the user load. In the end, a more experienced software engineer had to rebuild it from scratch.
The companies whose entire product is vibe coding don't have this figured out either.
Lovable, one of the most prominent vibe-coding platforms, had three security incidents in a row last year. The incidents exposed source code, database credentials, and tens of thousands of user records, with one vulnerability sitting unpatched for forty-eight days after it was reported. And in at least one case the underlying issue wasn't a bug: it was a default setting on the platform. Apps people built on Lovable were leaking customer data because the way Lovable configured things out of the box made that the path of least resistance.
The platforms can't be your security backstop. They're still figuring this out at the same time as the people using them.
The audience test
You don't have to stop vibe coding. I haven't. But before you build anything, ask who the artifact is for. The answer puts the build in one of three places.
Delete first. AI made building software so cheap that the obvious question got skipped: does this thing need to exist? A workflow you can describe in two paragraphs probably doesn't need an app. A spreadsheet and a recurring calendar block beats a tool you have to maintain.
For yourself, vibe-code with discipline. I keep a Friday experimentation slot. This is where I can vibe-code whatever I want, no expectations. It deals with the FOMO. It also keeps my sense of what vibe coding is from going stale, because the tools change month to month.
Always apply the principles from the lethal trifecta and destruction pieces. This is still your best bet for taking security into your own hands.
If you want to scale, buy or hire. The moment the artifact serves customers and sensitive data lives inside it, that's where you bring in a professional or pay for a product whose team has already done the work you can't see.
Five things to do this week
1. Inventory what you've vibe-coded. Apps, scripts, automations, internal tools. Focus on the ones still in active use. If you built it and never used it, straight to the delete pile.
2. For each item still in use, mark who depends on it. Just you? Your team? People outside your org? The further removed they are from you, the higher the expert-work threshold gets.
3. Apply the security series audits to each one. Trifecta check (private data + untrusted content + external comms) and destruction check (backups outside the blast radius, scoped reach, prompts as advisory not enforcing).
4. Look for the delete-or-buy candidates. If you are surviving without it, delete. For what you are still using, consider if there's an off-the-shelf service that does 80% of what you need. Consider the price of a subscription vs. the time you are spending on updates and maintenance on your vibe-coded solution.
5. Schedule time for experimentation. A single contained block to experiment without committing to anything. This might look like a few hours once per week. If you have a team and the bandwidth, it could also be a one week hackathon once per quarter to experiment without expectations.