Last month, at a roundtable with technology leaders, one of them shared an incident that had occurred on their team. An employee who wasn’t a developer, trying to make everyone’s week a little easier, used AI to build a small reporting tool. It automated a process the team had been doing manually. The tool worked. So they deployed it, and their staff started using it.
What nobody realized was that the useful tool was exposing the company’s customer database, including sensitive information, to anyone who happened to find the URL. Nothing about it looked wrong from the outside. The data was just sitting there, one link away from a serious situation.
This is a clear example of what worries me about these tools: Claude Code, Codex, Cursor, CoPilot, Antigravity, etc. They’re powerful, and they put capability in the hands of people who never had it before. In the right hands, it’s a gift. However, a person without the experience to know what they’re building can create something that works while unintentionally creating risk. Nobody in that story set out to expose customer data. They set out to save the team a few hours. Somewhere along the way, the tool became a public system that held customer data, and nothing about how it was built or deployed would ever have surfaced that fact. They caught it by luck.
Over the past year, I’ve watched vibe coding cross from throwaway prototypes into business-critical and public-facing systems. The pitfalls that come with that are something leaders need to pay close attention to.
These tools have become so good that a working result that used to take an expert weeks now comes together in hours. All it takes is one person describing what they want. And the results are persuasive: when something runs and looks finished, it’s easy to assume it is safe and secure.
Large Language Models (“LLM”) are very good at combining strings of text, and source code is ultimately just text. A convincing result is exactly what an LLM (text-prediction engine) produces, and it’s what persuades people these tools have good judgment. They don’t. Because the outputs look convincing, many people assume that critical thinking went into them. Others know better and take the shortcut anyway, outsourcing their judgment to the machine. Both paths end in the same place. Our job, as the people using these tools, is to provide the experience and the judgment ourselves. Handing that to the machine is an invitation to serious problems.
When someone is vibe coding, the agent builds from whatever information it is given, and what it’s handed is rarely the full picture of your business, your data, and the systems everything connects to. And frequently, no one is inspecting what comes back.
Another recent example is a project dashboard someone built. It worked well, but it was vibe-coded. It was written so the API key that gave the dashboard access to its data (think of it as the password) was exposed in the browser, sitting in the page’s source code for anyone who looked. Nothing in normal use would ever surface it. In this case, a security review caught it before the dashboard was deployed. Many vibe-coded tools never get that review.
Meanwhile, the same AI tools that give employees this power are also making it easier for attackers to find and exploit weak code. Building got cheaper, and so did attacking.
Keeping vibe-coded tools on internal servers isn’t the safe harbor it feels like. Insecure code within your network can become a doorway to everything else it can access.
When one of these tools fails, it fails as a business problem. Customer data ends up in the open, or access is granted far more widely than anyone intended. Increasingly, the result is ransomware, where an insecure tool gives an attacker a way in, and the company is locked out of its own systems until someone pays. Regulatory fallout and loss of customer trust come later, costing much more than the tool could have possibly saved.
The line I draw, after watching this play out with clients and inside my own company: vibe coding is for proof-of-concept work and validating ideas. That’s it. Anything connected to your infrastructure or your data, anything customers or the public can reach, shouldn’t be vibe-coded by someone without the expertise to deliver a secure solution. The security risk is too great for a softer position.
I’m not arguing against speed. In an earlier article in this series, I made the case for startup mode, for speed and a bias toward action, and I stand by it. But taking on risk you can’t quantify, and calling it speed, isn’t good business.
Simon Willison draws a similar line: a personal tool, where a bug only hurts you, go ahead and vibe-code it. Software for other people needs a higher bar. I’d add one caution: at work, a tool is rarely as personal as it feels. The moment a script reads from a customer database, the risk is shared, not personal.
Suppose you get lucky on security. There’s a second bill that comes due.
Another leader shared what happened after he spent months vibe-coding a digital product. It launched, and he was adding paying clients at a nice pace. Then the trouble crept in. Each new feature was harder to add than the last, and bug fixes started breaking things somewhere else. Scaling got harder too, right as more clients came on. Under the hood, there was no foundation, just old code layered on old code, much of it no longer even used. The product had become unmaintainable, and the only fix was a rebuild from scratch. The quick win cost him twice. His clients paid too, in bugs and downtime, and some of that trust didn’t come back.
His case fits the pattern. An agent often doesn’t build within a framework unless someone gives it one. It adds whatever code is needed to get the next thing working, and each feature gets tangled with the last.
Engineers call this spaghetti code. Left unchecked, AI produces it at an astounding pace. And it compounds. Every feature and every fix adds to the tangle, so each change costs more than the one before. Eventually you reach the point where even a small bug fix is a gamble, and there’s only one real option left. Rebuild.
All of this comes down to an audit you can run this week against everything your team has already built with AI.
Five questions, security first:
Can anyone outside your team reach it?
Can it touch sensitive data, think customer, employee, or financial?
Is it connected to other systems (credentials, APIs, your network)?
Would you know if it were compromised?
Is the business quietly depending on it?
Any yes means it’s past vibe coding, and beyond what a non-developer can safely own.
Agentic tools can and should safely accelerate the development of great software. However, it helps to separate two different ways of building with AI that are often lumped together, and they shouldn’t be.
This is where someone describes what they want, an agent writes the code, and they iterate based on what feels right. This puts building software within everyone’s reach, and most people using this approach don’t have a background in software development. They may never look at the code itself, and many couldn’t evaluate it if they did. The mechanics matter less than what’s missing. Nobody in the loop is asking whether the code is correct, secure, or maintainable. The software is judged entirely by its behavior, and behavior is what these tools are best at making look good.
Context engineering is a general term for a more thoughtful and structured approach. Agents are still used to write most of the code, but they work within guardrails a person built first. Before any code exists, there’s a spec that people debated, business rules and security requirements written down, and a clear definition of done. Once the code is written, humans review it before it ships, and a named person owns the result. The difference is everything around the quality of the code.
The reality is that these models are eager to please. They will do things you didn’t ask for, and they fill every gap in your instructions with a guess, usually not the choice you’d have made. Left alone, an agent will wander off your path and invent its own.
Start by writing a specification defining what to build. This gives the agent the full picture before it writes any code: what the software must do, what it must never do, what data it can and cannot touch, and what done looks like.
Think of it like a kitchen remodel. Tell a contractor “build me a kitchen,” and you’ll get one, shaped by a hundred decisions you never had a voice in. Hand them the designs first, the fixtures and appliances, where the plumbing runs, which walls are load-bearing, and you get the kitchen you actually wanted.
These specs are living documents, reviewed and kept up to date as the software evolves. For a significant feature, I can spend multiple days on nothing but the specification and the guardrails before any code is written. The building itself goes faster than it ever has. Most of the time now goes into the thinking.
Defining success criteria matters just as much. A spec plus explicit success criteria keeps an agent on track and provides clear guidelines to check against. Without them, done is whatever the agent decides it is.
Human review stays a checkpoint. Code ships when the people responsible agree it’s ready. An agent can write the code, but it can’t be accountable for it. Anytime you build something with AI and put it into the world, you own it, and you’re responsible for what it does.
The employee from the opening story is an asset. People with that kind of initiative are exactly the kind of people I want on my team. What failed was everything around them; nobody had given them guardrails or a safe path to build. Our job as leaders is to provide that path.
Part of ownership is knowing when something has moved past what a non-developer with a vibe-coding tool can safely produce. That’s the signal to bring in engineering discipline, whether you staff it internally or find a partner.
These tools produce output polished enough to pass for judgment. It isn’t judgment. Don’t outsource yours to an agent, and the same goes for ownership. Both stay where they’ve always been, with you and your team.
So the question I’d leave you with: do you actually know which of the things your team has built with AI are still prototypes, and which ones the business is now depending on? Somewhere in your company, someone helpful has probably already built one. The company in the opening story found theirs by luck. You don’t have to.
* There are many ways to successfully build software using agents. For this article, I am choosing context engineering. The other approaches are outside the scope of this article.
AI From the Inside is a series exploring the realities of leading a company through AI transformation. Drawing on 20+ years of building a digital consultancy, Nerdery’s CEO and founder, Michael Schmidt shares firsthand accounts of navigating this shift both internally and alongside our clients. These articles move past the hype to focus on the practical challenges of aligning technology, operations, and people.
Related articles
Automation follows instructions. Generative AI creates content. Agentic AI makes decisions but not alone. The goal isn’t to replace your
If you have been running AI pilots for the past 12 months and struggling to get them into production, then
MINNEAPOLIS, MN, 04/21/2026 — Nerdery announced today that it has received the 2026 Google Cloud Partner of the Year Award
Start building your digital ecosystem