Your Vibe-Coded App Is Rolling Up Everything You Own

Part 1 of a series on the dos, don'ts, and dangers of vibe coding.

There's a video game called Katamari Damacy where you push a sticky ball around and everything it touches gets stuck to it. You start with thumbtacks and end up rolling entire buildings into the ball. It's delightful in a game. It's what I keep finding when someone asks me to look at their vibe-coded app, and there it's a lot less delightful.

Here's how it goes. Someone vibe codes one genuinely cool application. It works. And then: oh, I can do this. I can do that. Connect it to the customer records. Let it read the shared drive. Wire it into the accounting system while we're at it. Days and weeks later — not months, I've watched the timeline — this one cool app has become a ball with everything stuck to it, and nobody can tell you exactly what's inside anymore.

For anybody who thinks about how data is managed for a living, that's a nightmare. And I want to explain why, using two stories from systems I was actually asked to inspect.

We used to have people whose job was to worry about this

Before AI came along, companies had DBAs managing their databases. They had chief information officers. There were humans whose entire job was to know where the data lived, who could touch it, and what would happen if something went wrong.

Now it feels like we're throwing caution to the wind. The AI will solve all our problems, so forget all of that. But here's the thing — the AI part doesn't change the question at all. I keep using this example: suppose you'd hired a whole crew of magical dwarfs to do all this work for you. Tireless, brilliant, fast. Would you put your crown jewels — everything you have — into a single pile for them to work from? No. You wouldn't. The competence of the workers was never the reason you kept the jewels separated.

And no, calling the pile a "data lake" doesn't fix it. We keep inventing terms, and somehow if something has an industry-specific name it feels legitimate and safe. It's still a pile.

The system that followed instructions and leaked anyway

My favorite recent example. I was asked to peek at a vibe-coded system whose author had, to their credit, explicitly instructed the AI to be very, very secure and to test everything. And at first I was mildly surprised and genuinely pleased: it was using Google Secret Manager. The secrets weren't sitting on the server. Someone had done it right, I thought.

Then I kept reading. Moments into the code, the application downloads every single secret from Secret Manager and saves them to a file — a generally readable file, sitting in the application's own directory.

It performed the ritual of security and then undid it in the next breath. Every box on the checklist looked checked. The vault was real. The secrets just also lived in a plaintext file next to the app.

The leak that wasn't in the system — it was in the people

The second story is subtler, and honestly it worries me more.

There was a system holding some basic customer data. Nothing alarming on paper. But over time, people had been copying sensitive information about those customers into it — because it was convenient, because the field was right there. Banking details, that kind of thing, tucked into description fields where nobody was looking for it.

On its own, that system wasn't particularly exposed. It was fine, more or less, for years. Then the AI got connected to it. The AI did exactly what it was supposed to do: it read everything, understood everything, and pulled all of that quietly accumulated sensitive data into the general pool — where it was now searchable, summarizable, and available to anything else the AI touched.

I showed the owner. The response was "no, that isn't possible." Then they looked at the data. "I think we were making a mistake."

That's the danger nobody warns you about. The AI doesn't just access the data you think is there. It surfaces the data your people have been quietly stuffing into convenient corners for years. Your data inventory isn't what your schema says. It's what your humans actually did.

That thing you built isn't a portal

Then there's the "portal." Somebody vibe codes a customer-facing app, hosts it on the internet, puts a thin veil of authentication in front of it, and points it directly at the backend system — the one holding everything. And this gets called a portal.

In my world, that word means something close to the opposite. A portal is a front end that holds the minimum data required to serve the customer, with that data segmented so that compromising the server doesn't hand over the store. Maybe an attacker gets in-flight data. They don't get everybody's records, because everybody's records aren't there, and what is there is individually protected. The idea is reducing the blast radius — not wiring the public internet straight into the thing that has keys to the kingdom.

And blast radius isn't abstract. For a small company, the bad day looks like data compromise, ransomware, the whole familiar list — except now it's your customers' banking details that were hiding in a description field.

What doing it right actually looks like

None of this is new security thinking. It's the old thinking, applied to a new tool.

First, a data inventory. You need to know what you're putting in before you connect anything to it. It doesn't matter how nice a system we build if the routing numbers and credit cards are hiding inside the account description field. Find out what's really in there — not what's supposed to be in there.

Second, scope it down. Does the system need all of the data? It should generally have only as much as it needs, and picking that minimum takes real thought. In higher-risk situations, sometimes all the AI needs is a description or an index of the data — a way to know it exists — and the actual records get fetched separately, at the moment they're needed, not parked in the pool.

Third, consider physical segmentation. Storage is cheap now. If you're struggling to keep data separated inside one vibe-coded system, giving each customer or each team their own database — a space there is simply no breaking out of — is not a stupid solution. The system isn't arbitrating access; the wall is real. Whether it's worth the hassle depends on the risk. Plenty of environments don't much care if employees can see each other's stuff as long as they can't change it. Other environments have genuinely sensitive data or competing teams, and there, relying on the system to keep things separate — especially when the system itself was vibe coded — might not be enough. Think of someone with a severe peanut allergy. You don't rely on everyone else's carefulness with the shared plates. You get your own plate. Software has its own plates too.

Leaves, branches, and the trunk

Here's the frame I'd offer for deciding where vibe coding belongs at all.

Picture your business systems as a tree. If your sensitivity to risk is high and your ability to inspect the system is low, you should only be building leaves. A tool that summarizes a report. Something that categorizes documents. If a leaf breaks, you lose a leaf. What you shouldn't be building is branches or the trunk — the customer-facing front end, the thing wired into the core data — because when something breaks there, it takes real weight down with it.

If you do know what you're doing — and plenty of software companies that write software for a living use these tools at various levels — the rule still holds: the deeper into the system it goes, the more scrutiny it requires. In some core parts, it's almost nonsensical to lean on AI for the code at all, because writing the code was never the hard part there. The work is human review and discussion.

This is just the risk-reward evaluation business owners already make many times a day about everything else. What's the value, what's the potential damage, does the second exceed the first, and how much supervision does it get. Software shouldn't be exempt from a question you're already good at asking.

"But the AI told me it was secure"

A system cannot vouch for itself, and that isn't magically disproven by an AI telling you so. In the world of security, people require evidence. Show me how it's secure. Point me to the code, point me to the architecture, explain it, and let me verify. If verifying it makes you uncomfortable — if you can't inspect it and it can't prove itself — then it's time to get somebody's help. "The AI said so" is not evidence. It's the system grading its own homework.

And yes, I run a custom software company, so you're entitled to some skepticism about my motives here. Honestly, though: the folks who vibe code successfully probably weren't going to be our clients anyway, and I'm fine with that. Some of my favorite conversations lately start with someone who vibe coded something, understood their problem far more deeply because of it, and brought us the result as a working requirements document — "can you build the real version of this?" That saves enormous cost, because so much of custom software is just extracting what the customer actually wants. Working with the AI first is genuinely great.

What I'm pushing back on is widespread usage without domain knowledge — because none of these magical tools eliminate the need for it.

So before you connect one more thing to the ball: stop and take inventory. Find out what's actually in your pile — not what's supposed to be there, what's there. Then ask, for each system, whether you're building a leaf or grafting onto the trunk. If you can't inspect it, keep it in the leaves.