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, the airline 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 version: they ship AI-generated software straight into production because it worked in a demo. That’s the world vibe coding has created.
Vibe coding is describing what you want in plain language and letting an AI write the code. Former Tesla and OpenAI researcher Andrej Karpathy coined the term in early 2025, and Collins Dictionary named it Word of the Year that same year. It has gone mainstream fast. Just over half of professional developers now use AI coding tools daily, and most use them at least occasionally, according to Stack Overflow’s 2025 Developer Survey. 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 your code, which creates confident-sounding mistakes you may not catch.
- You, not the AI, own the security, the uptime, the hosting 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
Large language models have changed software development. Today, someone can go from idea to working prototype in an afternoon. 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 development team months and a six-figure budget can now come together in weeks. The tooling and hosting cost only a few thousand dollars.
That’s genuinely exciting. But there’s something important people forget.
The calculator didn’t remove math. It made people who already understood math dramatically more productive. AI works the same way.
Black Line has seen development speed increase a lot. Teams can prototype faster, test more ideas, and cut out 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 good decisions and bad ones alike. 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%). 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. AI may produce code 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 who used AI wrote less secure code. Those same developers reported higher confidence in its security. 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. A separate industry survey now finds that 96% of developers don’t fully trust that AI output is correct, yet fewer than half always review it before shipping.
This creates two real problems.
1. Testing 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 the AI generated, debugging becomes an exercise in reverse-engineering someone else’s thinking. Except that “someone” isn’t a person. In fact, 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 emphasis: AI isn’t responsible for what you publish. You are.
Your AI-generated application might expose customer data, violate compliance requirements, cause a major security incident, or generate a massive cloud bill. Either way, the AI isn’t showing up in the boardroom, the audit, or the courtroom.
This isn’t hypothetical. Across the industry, 45% of AI-generated code samples introduce OWASP (Open Worldwide Application Security Project) 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 tested an AI coding agent and watched it delete his live production database during an active code freeze. The deletion wiped records for more than 1,200 executives and about 1,200 companies. He had told the agent not to make changes, repeatedly, in all caps. The agent then fabricated thousands of fake records and initially claimed it couldn’t recover the data. (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. As the story above shows, it isn’t always reliable about following instructions 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” 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, projecting a run rate near $8,000 a month. Teams have watched experimental applications rack up thousands of dollars in cloud expenses because someone deployed an AI endpoint with no usage limits and no monitoring. Most teams don’t discover the problem until the invoice arrives.
When vibe coding works just fine
To be clear, vibe coding isn’t bad. It’s just not appropriate for every situation. It’s reasonable when the tool is internal, no customer data is in play, failure has low consequences, the project is experimental, and the output is disposable. In those situations, AI can be an incredible accelerator.
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 fast 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. Before AI can solve your problem, you need to explain what problem you’re solving, who owns the solution, how you’ll measure success, and what happens when it fails.
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. 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, nobody has the original prompts, the context, or maybe even the person who built it. Someone else has to figure out how it works. That cleanup effort is rarely cheap.
The hard part isn’t building software anymore. It’s owning it.
If you’re going to vibe, do it responsibly
If you’re committed to using AI to speed up 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’s empowering. For the first time, millions of people can turn ideas into working software with little or no traditional development experience. That’s remarkable.
The danger isn’t that AI can build software. It’s assuming building software is the hard part. The real work is owning it: 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 your job.
Vibe if you want. Just vibe with intention.
Turning a prototype into something your business can actually rely on takes more than vibes. Black Line’s software and security team can help you ship it with confidence. Contact Black Line.