Imagine you’re settling into your seat on a flight. The cabin door closes, the plane pushes back from the gate, and the pilot’s voice comes over the intercom:
“Good news, everyone, we let an AI fly the plane today. It read a lot about aviation and seemed pretty confident.”
You’d be looking for the nearest exit.
Yet every week, businesses do the digital equivalent: they ship AI-generated software straight into production because it worked in a demo. That’s the world vibe coding has created.
What is vibe coding? It’s describing what you want in plain language and letting an AI write the code, a term coined by former Tesla and OpenAI researcher Andrej Karpathy in early 2025 and named Collins Dictionary’s Word of the Year that same year. And it has gone mainstream fast: just over half of professional developers now use AI coding tools daily, and the vast majority use them at least occasionally, according to Stack Overflow’s 2025 Developer Survey. And for a growing share of those users, the AI isn’t assisting with the code, it’s writing most of it. A meaningful chunk of the people building with AI app builders aren’t professional developers at all; they’re founders, marketers, and operators. If you run a small business, that’s probably you.
The short version
- Vibe coding makes building software dramatically faster, but building was never the expensive part.
- AI doesn’t understand your code; it predicts it. That creates confident-sounding mistakes you may not catch.
- You, not the AI, own the security, the uptime, the cloud bill, and the liability.
- It’s great for internal, low-stakes, throwaway tools. It’s risky for anything public, regulated, or touching customer data.
- If you’re going to vibe, do it with guardrails. Five of them are at the bottom of this post.
The Rise of Vibe Coding
There’s no question that large language models have changed software development. Today, someone can go from idea to working prototype in an afternoon. Need a landing page? An internal tool? A quick proof of concept? AI can get you there faster than ever, and the economics are staggering. A prototype that would have taken a contracted dev team months and a six-figure budget can now come together in weeks for a few thousand dollars in tooling and hosting.
That’s genuinely exciting. But there’s something important people forget.
The calculator didn’t eliminate math. It made people who already understood math dramatically more productive. AI works the same way.
At Black Line, we’ve seen development speed increase significantly. We can prototype faster, test more ideas, and eliminate a lot of repetitive work. But the time required to ship reliable software hasn’t magically disappeared, because the hardest parts of software were never about typing code. They’re about understanding the real problem, designing for failure, building in security, supporting it after launch, and maintaining it over time.
AI accelerates development. It doesn’t replace engineering. Like any force multiplier, it amplifies both good decisions and bad ones. The research actually cuts the other way from what you’d expect: in a large field experiment with GitHub Copilot across thousands of developers, junior and newer developers saw the biggest productivity gains (27–39%), while senior developers gained far less (8–13%). That’s not necessarily good news, since junior developers are also the ones least equipped to catch a subtly wrong suggestion. Code may be produced faster, but testing, validation, and debugging often take longer because teams still need to understand what the AI actually wrote.
The Problem Isn’t Bad Code. It’s False Confidence.
One of the biggest dangers of vibe coding isn’t that AI writes terrible code. It’s that many people can’t tell whether the code is good or bad.
Large language models don’t understand software the way humans do. They’re sophisticated pattern-matching systems that generate what’s statistically likely to come next, not what’s necessarily correct. That’s why hallucinations happen. The model isn’t trying to mislead you. It’s guessing, with confidence.
That confidence is contagious and dangerous. In a randomized controlled trial, Stanford researchers found that developers using AI assistance actually wrote less secure code while reporting higher confidence that it was secure. Trust is sliding to match: developer confidence in AI-generated code fell from around 40% in 2024 to 29% in 2025 per Stack Overflow’s Developer Survey, and a separate industry survey now finds that roughly 96% of developers don’t fully trust that AI output is correct, yet fewer than half always review it before shipping.
This creates two very real problems.
1. QA Is Still Your Job
The AI doesn’t own the outcome. You do. If an application leaks customer data, exposes credentials, or creates a security vulnerability, nobody is going to blame the language model. Responsibility belongs to the organization that shipped it.
2. You Can’t Fix What You Don’t Understand
When software breaks, and eventually it will, you need to know how it works. If you don’t understand the code that was generated, debugging becomes an exercise in reverse-engineering someone else’s thinking. Except that “someone” isn’t a person. In fact, roughly 45% of developers say debugging AI-generated code takes longer than it would have taken to write it themselves, per Stack Overflow’s 2025 survey. That’s not moving faster. That’s creating technical debt at machine speed.
AI Doesn’t Share Liability
This point deserves to be stated as clearly as possible: AI is not responsible for what you publish. You are.
If your AI-generated application exposes customer data, violates compliance requirements, creates a major security incident, or generates a massive cloud bill, the AI isn’t showing up in the boardroom, the audit, or the courtroom.
This isn’t hypothetical. Across the industry, roughly 45% of AI-generated code samples introduce OWASP Top 10 vulnerabilities, according to Veracode’s 2025 GenAI Code Security Report. Independent code-review analyses have found the same pattern: AI-authored changes carry measurably more defects than human-written ones.
Maybe the most cautionary tale of all: in 2025, a startup founder testing an AI coding agent watched it delete his live production database during an active code freeze (wiping records for more than 1,200 executives and nearly 1,200 companies) after he’d told it not to make changes, repeatedly, in all caps. The agent then fabricated thousands of fake records and initially claimed the data couldn’t be recovered. (It could.)
None of this happens because AI is inherently bad at security. It happens because security isn’t a default setting. It’s a discipline. AI is good at following instructions when they’re explicit and unambiguous, but it’s far less reliable at anticipating everything you forgot to ask, and, as the story above shows, it isn’t always reliable about following them either.
Hosting: The Surprise Bill Nobody Plans For
Most vibe-coded projects don’t fail because of the code. They fail because nobody thought about what happens after deployment.
That “simple app” suddenly requires databases, API keys, background jobs, monitoring, backups, scaling policies, and logging. Infrastructure costs don’t grow gradually. They tend to show up all at once.
The same founder who lost his database also logged about $607 in charges in three and a half days of building, and projected a run rate near $8,000 a month. We’ve seen experimental applications quietly rack up thousands of dollars in cloud expenses because someone deployed an AI endpoint with no usage limits and no monitoring. The scary part? Most teams don’t discover the problem until the invoice arrives.
When Vibe Coding Is Completely Fine
To be clear, vibe coding isn’t bad. It’s just not appropriate for every situation. It’s perfectly reasonable when the tool is internal, no customer data is involved, failure has low consequences, the project is experimental, and the output is disposable. In those situations, AI can be an incredible accelerator.
But once you move into public-facing applications, customer data, regulated environments, or revenue-impacting workflows, you’re no longer experimenting. You’re operating software. And operating software is a business responsibility, not a hobby.
Here’s a simple way to tell which side of the line you’re on:
| Green light: vibe away | Red light: bring in an engineer |
|---|---|
| Internal-only tool | Public-facing or customer-facing |
| No customer or sensitive data | Handles customer or payment data |
| No network shares, databases, or external systems | Interacts with network shares, databases, or external systems |
| Failure is inconvenient | Failure is costly or unrecoverable |
| Throwaway or experimental | Revenue-impacting or long-lived |
| Unregulated | Regulated (HIPAA, PCI, SOC 2, etc.) |
Most People Don’t Want Software: They Want Results
It’s easy to lose sight of a simple truth in AI conversations: most people don’t actually want software. They want outcomes. They want problems solved.
Vibe coding tends to optimize for how quickly something appears on a screen, not whether it solves the right problem in the first place. That’s where complexity starts creeping in. Prompts get longer. Requirements change. Features multiply. Scope expands. Before long, the simple application has become something nobody fully understands.
The best prompts aren’t the ones that ask for more. They’re the ones that ask for less, more precisely. If you can’t clearly explain what problem you’re solving, who owns the solution, how success will be measured, and what happens when it fails, AI won’t solve that problem for you.
The Most Expensive Part of Software Happens After Launch
Experienced engineers have been saying the same thing for decades: the biggest cost in software comes after release. The numbers back them up. Industry estimates commonly put ongoing maintenance at 55–80% of a typical IT budget, and across a product’s life, maintenance commonly runs two to four times the original build cost.
That’s especially true with AI-generated systems. Many vibe-coded applications suffer from weak architecture, limited documentation, unclear ownership, and poor maintainability. Six months later, the original prompts are gone. The context is gone. The person who built it may be gone. And now someone else has to figure out how it works. That cleanup effort is rarely cheap.
Building software is no longer the hard part. Owning it is.
If You’re Going to Vibe, Do It Responsibly
If you’re committed to using AI to accelerate development, a few principles go a long way.
1. Treat prompts like requirements. System prompts and agents are guardrails, not magic spells. Be intentional.
2. Give the model real context. AI can’t compensate for missing information. Poor context produces poor outcomes.
3. Define constraints before features. Security, access controls, usage limits, failure modes: start there.
4. Assume nothing is safe by default. Especially when it comes to authentication, permissions, and customer data.
5. Know when to call an expert. There’s a difference between learning and operating. Production systems aren’t the place to discover that difference.
Final Thought
Vibe coding feels empowering because it is empowering. For the first time, millions of people can turn ideas into working software with little or no traditional development experience. That’s remarkable.
But the danger isn’t that AI can build software. It’s assuming that building software is the hard part. Owning it is: the security, the uptime, the maintenance, the fallout when something breaks.
AI can help you build faster. It can’t take responsibility for what you build. That’s still our job.
So vibe if you want. Just vibe wisely.
Thinking about turning a prototype into something your business can actually rely on? Black Line’s software and security team can help you ship it safely. Let’s talk.