Vibecoding and Security: What Leaders Need to Know About Teams Building With AI
AI Knowledge Disparity: Leaders face challenges as team members outpace them in AI tools and capabilities.
Vibecoding Explained: Non-technical workers create functional tools via prompting, bridging idea execution gaps.
Security Concerns: Unmanaged vibecoding tools pose data handling and exposure risks, particularly PII vulnerabilities.
Cost Implications: Unoptimized use of AI tools may lead to unexpected expenses and financial risks.
Scalability Issues: Successful vibecoded tools require professional oversight to ensure scalability and reliability.
Let's be honest: we're all in different places when it comes to AI. And for leaders, this can be unsettling — more than ever, direct reports are surpassing their managers in AI knowledge and enablement, moving fast, and often breaking things.
While many organizations are encouraging open exploration of AI tools, vibecoding — the next phase of AI enablement for many non-technical employees — is an adventure that comes with varying degrees of risk, depending on what you're building, who you're building it for, and what data is being stored and used.
This is becoming especially prevalent on project management and operations teams, where building proprietary tools is often the obvious answer to process needs — and with AI coding agents, it's never been easier to greenlight.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
To help us understand what to watch out for when teams start building, I brought in Tim Fisher, DPM's VP of AI, to give us the rundown. This article is for anyone who has received the "Hey boss, look at this cool thing I built with Claude!" — we hope it helps.
First, What Is Vibecoding? And Why Is It Actually Valuable?
For the purposes of this article, vibecoding means coding through prompting — specifically by someone who is non-technical. This is distinct from a software developer using a tool like GitHub Copilot, where the human still brings meaningful technical knowledge to the work. We're talking about the CFO, the ops coordinator, the project manager who has never written a line of code and is now shipping functional tools using nothing but natural language prompts.
And Fisher's opening take might surprise you: he's genuinely enthusiastic about it. "I love the idea of people who cannot code being able to now have a way to get the thing they want out of their brain into a form that everyone can see and play with and use," he says. "It's a way to communicate that didn't exist before." He frames it less as a technical capability and more as a new communication medium — one that closes the gap between vision and execution for people who've always had ideas but lacked the technical vocabulary to express them.
Vibecoding is a way to communicate that didn’t exist before.
"It's a little bit like the challenges people experience when working with design teams," Fisher explains. "I can't draw a stick figure. And so, when I want to communicate to someone something visual, I am so happy that there are tools now to let me explain something in lots of well-thought-out words, which I am good at, and get something out at the other end that somebody else who does know how to design goes, 'Oh, I know what you're after now.'"
For leaders, this reframe matters. The impulse to shut it down entirely misses what's genuinely useful here: vibecoding can accelerate alignment, surface ideas faster, and give non-technical team members a new way to contribute. The question isn't whether to allow it. It's whether you understand what happens after the tool gets built.
Where the Value Stops — And the Risk Begins
Fisher is careful to separate the "communication" phase of vibecoding from what tends to follow it — and that's where his tone shifts. "I think that the value of it probably stops there most of the time," he says. "It is a much better way to communicate ideas and direction. But what we find is that some things can happen after that that become more than 'Hey, look, I've communicated an idea to you, we're now sharing a language.' And that's where it gets frightening."
The problem isn't the prompting. It's the deployment. It's the moment a prototype becomes a tool that real people use, that stores real data, that runs in the background on real infrastructure — and the person who built it still doesn't know what's happening under the hood.
The Security Vulnerabilities Leaders Should Know About
PII and Data Handling
The most intuitive risk for most leaders will be around personally identifiable information (PII). Fisher uses a concrete example to illustrate where the ceiling sits: "I think the ceiling on complexity would be right before the ingestion of employee or client data into a system that regurgitates that data to other people. That’s when you run into PII issues."
I think the ceiling on complexity would be right before the ingestion of employee or client data into a system that regurgitates that data to other people.
The risk scales with the sensitivity of the data and the audience who can access it — and on ops and project management teams, that data often includes client information, employee records, compensation data, or contact details that carry real legal exposure.
Runaway Costs and Token Usage
One risk that catches many leaders off guard has nothing to do with data and everything to do with dollars. Fisher describes a scenario that is more common than most people realize: "Let’s say someone accidentally directs an agent coder in the wrong direction that results in it creating a loop that runs all the time, constantly racking up an expensive fee. And, before you know it, a project that’s supposed to be $5,000 costs $50,000 because they didn't know what was going on under the hood and assumed that the agentic coder would catch that."
Non-technical builders are also less likely to optimize for token usage in general, which means costs can accumulate quietly and quickly. Without visibility into the infrastructure their tools are running on, your team members may not realize there's a problem until the bill arrives.
API Keys and Information Security
This is where Fisher gets into the territory that keeps security teams up at night. The scenario he describes is a textbook example of what goes wrong when someone knows just enough to be dangerous: "One common mistake is when someone knows just enough to know and articulate that they need an API key to make something happen. They provide the key in a prompt, and it doesn't get stored in a secret location – it just gets dumped in a file or written directly into the script. Then somebody posts the code to GitHub, maybe they forget to make it private, and now that API key can be abused by anyone willing to do something nefarious like racking up a $100K token bill.”
It's easy to read that scenario and think it requires a long chain of mistakes. Fisher pushes back on that instinct: "It sounds like there's this long string of unlikely things to happen, but it's not unlikely at all. It's actually extraordinarily common, especially for non-technical people.”
Perhaps the most alarming risk Fisher raises is one that even experienced developers have fallen into. "I've heard horror stories about experienced developers dropping the entire codebase of a business into an agent coder and tweaking something, and then the entire codebase getting exposed to another company completely within the bounds of law." If experienced developers can make this mistake, the risk profile for a non-technical employee building quickly and without oversight is considerably higher.
The Scalability Problem — What Happens When It Actually Works
One of the trickier conversations for leaders is what to do when a vibecoded tool genuinely solves a problem, and people start relying on it. The success case can quietly become a liability. Fisher is clear about the structural issue: "Generally speaking, all vibe-coded projects are not scalable, mostly because you are not asking the agent to consider scaling. Non-developers probably don't even ask for things like error handling. If you don't understand the places where errors do happen, you don't know enough to ensure that the agent is catching those and dealing with them appropriately."
Generally speaking, all vibe-coded projects are not scalable, mostly because you are not asking the agent to consider scaling.
The accountability gap becomes most visible under pressure. "What tends to happen is somebody will vibe code something, and then it works, but is this person 24/7 tech support for this product?" For delivery and operations leaders, this is the moment where a well-intentioned internal tool becomes an organizational risk — because the more teams rely on it, the more likely it is to break or need constant tech support.
Fisher's recommendation for tools that gain traction is a clean handoff: "If you build something that people rely on, it needs to become more than just a vibecoded project; it needs to be absorbed by the people that do this professionally and know things that you don't even know to ask."
What Leaders Can Do — Practical Guardrails
None of this means the answer is a blanket prohibition. Fisher is consistent on this point — the value of vibecoding for non-technical people is real, but it lives in a specific lane. "The value of these tools for non-coders is to be able to shortcut things like alignment around an idea and get past the 'is this going to work?' phase," he says. The prototype phase, the communication phase, the "is this even worth building?" phase — that's where vibecoding shines, and where the risk is still manageable.
For leaders, the practical playbook looks something like this: encourage vibecoding as a prototyping and communication tool, and establish a clear threshold at which a tool gets reviewed by someone with technical expertise before it goes into wider use. Having these conversations with your team — so they understand the risks and know their options — is what separates a culture of smart AI exploration from one that's just moving fast and hoping for the best.
The goal isn't to be the leader who says no. It's to be the leader who makes sure the team knows what they're getting into — so when someone does build something great, it can actually go somewhere.
Want more insights like these? Sign up for a free DPM account to hear from more experts like these.