Two weeks into January and I've already lost count of how many people have shown me something they built over the holidays. A CRM for a gym. A booking tool for a side business. An internal dashboard that talks to a company's customer data. None of these people are engineers by trade. All of them have a working, deployed, database backed app.
A year ago that sentence would have sounded like a stretch. In January 2025 the phrase "vibe coding" didn't exist yet, Andrej Karpathy wouldn't coin it until February 2. Base44 had only just launched. Cursor was popular among developers but hadn't crossed over into a household name outside that group. A non-technical person shipping a real backend in a weekend was still mostly theoretical.
By November, Collins English Dictionary named "vibe coding" its Word of the Year. That's not a marketing stat. That's a dictionary publisher looking at what people actually searched and said all year and deciding it mattered enough to define. Something shifted in those eleven months, and it wasn't only that the tools got better. It's that the number of people building production software with a real database behind it went from some developers to basically anyone with an idea.
What that year actually contained
I went back through what actually happened in 2025 instead of trusting my memory of it, and it's a heavier list than I remembered.
Three things that actually happened last year
- May 2025: a row level security flaw in Lovable built apps left more than 170 live projects exposed, 303 vulnerable endpoints across roughly 1,600 scanned.
- July 2025: Wiz reported an authentication bypass in Base44, the same platform Wix had just paid 80 million dollars for, that let anyone register into any private app using nothing but a public app ID.
- July 2025: a founder watched an AI coding agent delete his production database mid freeze, then give him an inaccurate recovery story.
None of that made the tools bad. It made them fast. Fast enough that the gap between having an idea and having a live database with real user data in it collapsed to an afternoon, for people who had never had to think about who else can read that database.
The part that doesn't show up in a demo
Here's the thing I keep coming back to. Every one of those incidents started as a working app. Someone built it, tested it, showed it to people, and it did exactly what they wanted. Nobody set out to leave a database open. It just wasn't on the list of things they thought to check, because the tool never told them to check it, and there was no first day at a job where someone walked them through what row level security even means.
That's the actual shift I'm sitting with this week. AI coding tools didn't make building dangerous. They took a skill that used to gatekeep who got to build software, writing the code, and left a second skill completely untouched: knowing what to lock down once it's built. One got automated. The other is still entirely manual, and almost nobody building right now has ever been taught it.
I don't think the fix is scarier than the problem. Most of what got exploited last year traces back to two or three checks: who can read this table, does this endpoint verify who's asking, is a secret sitting in code that's about to go public. None of that requires learning to program. It requires deciding, once, that those questions get asked before the app goes live, not after someone else finds the answer for you.
I don't have a January incident to point to yet. This year is still young. But if last year is any guide, the incidents aren't the anomaly. They're the lagging indicator. Somewhere right now a database is going live with a default policy nobody looked at twice, on an ordinary afternoon, built by someone genuinely proud of what they just shipped. That's not a reason to slow down. It's just the one line item that deserves the same five minutes as picking a color scheme.