Your CFO Just Shipped Code. Nobody Knows What’s In It.
The Hidden Risks of Vibe-Coded Apps and Invisible Tech Debt

A true story Aaron Mitchell shared on the Software Leaders Uncensored podcast, lightly anonymized. A CFO — a person who has never written a line of code in his life, who by his own cheerful admission “couldn’t spell HTML” — built a beautiful internal dashboard. Revenue, renewals, metrics, all of it, live and polished. He did it by vibe coding with an LLM. It works, it looks great, and the finance team uses it every day. Then someone asked him a simple question: do you know what open source this thing pulled in to work? His answer: “Hell no. I have no idea.”
That exchange is funny until you sit with it. Now multiply that one dashboard across every employee at every company who is building apps this way — the sales ops manager automating a workflow, the marketer spinning up a landing page, the analyst wiring together an internal tool. That is the picture of enterprise software in 2026, and it should make every security leader sit up straight.
The bill hasn’t come due yet
Here’s the uncomfortable part. Right now, everything works. The dashboards load. The internal tools do their job. The vibe-coded apps are fresh, their dependencies are current, and nothing has broken. That’s exactly what early-stage tech debt looks like — it’s invisible precisely because it’s new.
We are accruing a mountain of it, and we haven’t paid a cent on the balance yet. Fast-forward a year or two and the collectors start showing up. You’ll have systems that were vibe coded by people who’ve since moved on, running on open source nobody catalogued, doing work the business now depends on — and no one will fully understand how any of it functions. The components those models pulled in will have aged. Some will have gone end-of-life. A few will have known CVEs. And the person who could explain the architecture left eight months ago. It’s going to get ugly, not because AI-assisted development is bad, but because we adopted the productivity and skipped the accounting.
The security leader’s nightmare
Put yourself in the seat of a CISO. Your CFO doesn’t know what’s running inside the tool he built. If the CFO doesn’t know, you definitely don’t know. And if you don’t know what your CFO is running, you certainly don’t know what everyone else across the company is running either. The attack surface didn’t just grow — it grew in places you can’t see, created by people who were never trained to think about dependencies, licensing, or patching.
The data backs up the instinct. BlackDuck’s research found that 74% of companies are knowingly in violation of their own stated AI policies. Read that again: not unknowingly — knowingly. Security leaders wrote the policies, watched people ignore them, and accepted it, because the productivity gains from AI are too tempting to wait around for an approval queue. Policy on paper and behavior in practice have fully diverged.
We’ve been here before, in a smaller way. A few years ago it was “shadow IT” — employees bringing personal phones and laptops into the building, syncing sensitive data to who-knows-where. We eventually got a handle on it with device management and clear policy. Now everyone is a developer, and the problem is an order of magnitude larger and harder to corral. It’s shadow IT with a compiler.
Why this is the opposite of “engineers aren’t needed”
There’s a popular narrative that AI means companies won’t need software engineers anymore. The CFO’s dashboard is, ironically, the cleanest argument against it. Yes, AI delivers real efficiencies, and yes, the engineering job looks very different than it did a year ago. But the moment non-engineers start shipping production code without understanding what’s inside it — the dependencies, the vulnerabilities, the licensing obligations, the lifecycle of every component the model quietly imported — you don’t get a world with no engineers. You get a world that desperately needs them.
Without engineering oversight, you architect your way into a hairball of problems you can’t see and can’t unwind. Software engineering isn’t going away; it’s becoming the discipline that keeps the rest of the company from accumulating invisible risk. The value shifts from typing code to governing it — reviewing what gets shipped, owning what runs in production, and maintaining the dependency layer the whole organization now sits on.
What to do before the collectors arrive
You don’t fix this by banning AI tools — that ship has sailed, and the 74% number proves the bans don’t hold anyway. You fix it by adding the oversight layer that vibe coding skips. Get visibility first: every team needs an honest, current inventory of what’s actually running in the apps people have built, including the open source dependencies that came along for the ride. Establish ownership: every production system needs a human accountable for it, especially the ones that were vibe coded by someone who has since left. And cover what’s gone end-of-life: a surprising amount of what these models pull in is older, unsupported open source, and when you find it you need a path to a secured, maintained version that doesn’t require halting the roadmap to rip and replace.
The companies that come through this cleanly won’t be the ones that moved slowest. They’ll be the ones that paired AI’s speed with the engineering discipline to know what they shipped. The dashboard is great. Knowing what’s inside it is greater.
Hear the full story from Aaron Mitchell on the Software Leaders Uncensored podcast.
Resources
View All Articles


