What You Need to Know About Vibe Coding

Vibe coding means building software with an AI model without reviewing the code it produces. It's a genuinely useful way to test an idea, learn what software can do, or build a tool only you will ever use.

It's a poor way to build a product you intend to sell, because security, predictable running costs, and the ability to fix things next year are exactly what nobody checks when nobody reads the code.

What is vibe coding?

Andrej Karpathy, former director of AI at Tesla and a founding member of OpenAI, coined the term in February 2025 for building software by describing what you want and letting the model handle the rest, to the point where you forget that the code even exists. By November, Collins Dictionary had named vibe coding its Word of the Year for 2025.

The definition that matters for business decisions is Simon Willison's. Willison, co-creator of the Django web framework, writes that vibe coding means "building software with an LLM without reviewing the code it writes". He goes on to explain that this is fine when the stakes are low, your money isn't on the line, and you have no reason to be concerned about security.

Vibe coding is not the same as professional AI-assisted programming. When you're responsible for software that has to be stable, secure, scalable, maintainable, explainable, and operational in a real-world environment with high stakes, you're no longer vibe coding. Willison is precise about where the line falls:

"If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works to someone else that's not vibe coding, it's software development. The usage of an LLM to support that activity is immaterial."

Vibe coding, vibe engineering, and agentic engineering

Since then, both sides of that line have acquired names. In October 2025 Willison proposed vibe engineering for the professional version: work where "seasoned professionals accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce."

In April 2026 Karpathy drew the same line from the other direction, using agentic engineering for the discipline of directing coding agents against detailed specifications rather than hoping a prompt lands somewhere useful. His summary is worth keeping close by. Vibe coding "is fine for prototypes and personal tools," while "agentic engineering is what serious teams need."

If you're already working somewhere between these two columns, which most teams are, the practical middle ground is covered in our guide to AI-powered coding assistants.

Why does unreviewed AI code fail in production?

Because a language model optimizes for code that looks right and runs, and neither of those is the same as code that is safe, efficient, and maintainable. Nothing in the objective rewards the second set of properties. In ordinary software development a human reviewer supplies them. Vibe coding, by definition, removes the reviewer.

What unreviewed code does to a codebase

The consequences show up in the shape of the code itself. GitClear's January 2026 study of 623 million code changes found that between 2023 and 2026, duplicated code blocks rose 81% and within-commit copy and paste rose 41%, while refactoring, meaning the work of moving and consolidating code that already exists, fell 70%. Refactoring went from 21% of changed lines in 2022 to 3.8% in 2026. Constructs that mask errors rather than handle them rose 47%. More code is being written and less structure with it.

Each of those numbers is a future invoice. Duplicated logic means a bug you fix in one place and leave in four others, absent refactoring means the codebase gets harder to change every week instead of easier, and masked errors mean failures stay invisible until a customer finds them.

What it costs the business

Developers feel this before they can measure it. In Stack Overflow's 2025 survey of nearly 50,000 respondents, 84% use or plan to use AI tools, but only 3.1% highly trust the accuracy of what those tools produce and 45.7% actively distrust it. The top frustration, at 66%, is "AI solutions that are almost right, but not quite," and 45.2% say debugging AI-generated code consumes significant time. Almost right is the expensive category, because code that fails immediately is cheap to catch.

The productivity math is also counterintuitive. In a randomized trial published by METR in July 2025, 16 experienced open-source developers completed real tasks 19% slower when allowed to use AI tools, while estimating afterward that AI had made them 20% faster.

Google's 2025 DORA report, covering an industry where AI adoption reached 90%, found the honest version: AI raises delivery throughput and instability at the same time, because it amplifies whatever practices a team already has. Strong teams get faster. Teams without review, tests, and clear ownership get faster at producing work they will have to redo.

For a business the chain has a predictable shape. Unreviewed code ships, defects surface as incidents rather than as failed tests, engineering time shifts from building features to repairing foundations, and the roadmap slips. The code was free; owning it was not.

Problem #1: Does vibe coding produce too much code?

Yes, and that matters more than it sounds like it should. This might be surprising if you don't write software for a living, but code is a liability. Professional developers work to have less of it wherever they can.

"Writing less code is generally better than writing more code"

- David J. Malan, Computer Science Professor leading the most popular entry-level programming course, Harvard's CS50

The reasoning is simple. Every line can be wrong, has to be read by someone eventually, and has to keep working while everything around it changes. Fewer lines, fewer places for a defect to hide.

Vibe coding pushes the other way, because a model has no reason to prefer the shorter solution and no memory of what it wrote last week. GitClear's data puts a number on it: developers are now roughly five times more likely to duplicate a block of code than to consolidate it. For a program only you will ever use, none of this matters. It starts mattering the day a professional developer has to read your codebase, and it matters most if that developer is quoting you a price to finish it.

Problem #2: Is vibe coding safe?

Vibe coding itself is neither safe nor risky. The risk comes from what you build with it and where you put it.

Search X for "vibe coding" and "hack" and you'll find no shortage of stories from people who published vibe-coded apps only for them to be hacked almost immediately.

Or you may end up in a similar situation to Jason Lemkin, founder of the SaaS community SaaStr. Lemkin went all in on vibe coding, spending several days and hundreds of dollars using Replit AI to build software.

After a while, things got weird. He found that the AI was covering up bugs and issues, creating fake data and reports, and lying about unit tests. It then deleted his database and told him restoring it was impossible, which was not true.

The story had a reasonably positive ending. Replit's CEO responded quickly and the company performed a security overhaul within 72 hours.

The platforms are still shipping security regressions

A year later the platforms themselves were still learning the same lessons. In April 2026 Lovable disclosed that a backend change made that February had re-enabled public access to chat history and source code on public projects, meaning any signed-in user could read them. In its own post-mortem the company wrote that it "didn't go far enough or fast enough in building safeguards around visibility settings," and that its initial communication "missed the mark." Private projects were not affected.

This isn't one platform's problem. Escape, an API security firm, scanned around 1,400 vibe-coded applications running in production and found 2,038 critical vulnerabilities, more than 400 leaked secrets such as API keys and credentials, and 175 exposures of personal data, including bank account details.

None of that makes vibe coding reckless by nature. It makes security something you have to add deliberately, with someone who knows what to look for, because the model will not tell you what's missing.

If the stakes are low and you're building something for yourself, it's hard to do real damage. If you want to release a stable, secure, and scalable digital product, the best that vibe coding can currently give you is a prototype. After that, let your in-house developers take over, or outsource further development to a reliable agency.

Problem #3: Is vibe-coded software easy to scale?

Scaling vibe-coded software is hard, for a fairly boring reason: models reach for the straightforward solution rather than the efficient one. That code uses resources loosely and struggles once it meets more data than it was demonstrated on.

Performance degradation under load is not a recipe for success. At worst it means a cloud bill that grows faster than your user count, which is an alarming way to discover an architecture problem.

Matthew S. Smith, a technology journalist who built several apps with AI for PCWorld, was refreshingly honest about this. He loved the experience, and described his own AI-generated code as "enough to make a senior software engineer go blind." Both halves of that are true at once.

It's fine for personal projects, and it's a genuinely good way into programming without months of study first. But when you aim to serve thousands of users simultaneously, those inefficiencies stop being cosmetic. If you're planning to grow beyond a few hundred users, expect to significantly refactor or rebuild your vibe-coded foundation, and budget for it rather than discovering the number later. Our cost breakdown by project type is a reasonable place to calibrate.

Problem #4: Is vibe-coded software easy to debug or maintain?

As Craig Zingerline, an experienced vibe coder and seasoned founder, described it in his LinkedIn post:

"What usually starts out strong with AI vibe coding products ends up in refactoring hell. Anything complex takes time."

Vibe coding a complex product and repairing it afterward can take longer than having an experienced developer build it properly from the start. In professional programming, many problems are solved before any code exists. Ideation, workshops, product design, and prototyping all work to prevent issues before development begins.

The problem is structural. Debugging requires understanding how the code works, and vibe coding explicitly invites you not to look. Addy Osmani, an engineering leader at Google, put it plainly:

"Debugging AI code can prove difficult, especially if you're not familiar with it. Developers who try to debug AI-generated code, especially code they didn't write or understand, will struggle to reverse-engineer how it works."

This is also why "we'll fix it later" is a weaker plan than it sounds. Later, whoever fixes it has to first reconstruct the intent behind code that was never explained to anyone, which is the most expensive category of maintenance work there is.

Problem #5: Vibe coding and technical debt

Tabnine and others have predicted a "technical debt tsunami" as a result of vibe coding. The metaphor is doing real work. Ordinary technical debt accumulates gradually and gives you time to notice. Vibe coding can generate a great deal of it in an afternoon.

Without proper supervision, generated code tends to skip whatever has no visible payoff:

• proper architecture patterns

• code modularity and reusability

• documentation anyone else can follow

• real test coverage

• security best practices

The research has caught up with the anecdotes. A December 2025 paper by Muhammad Waseem and colleagues, Vibe Coding in Practice, traces how the sheer ease of generation drives debt through architectural inconsistency, security gaps, and rising maintenance load, and attributes it to missing design documentation and a preference for speed over structure rather than to any one model's weakness.

The awkward part is that this debt gets deprioritized precisely because paying it down produces nothing a customer can see. Code cleanup, backend refactoring, and infrastructure upgrades don't ship as features. They do determine whether the product still works next year. Managing that trade-off deliberately is most of what long-term product engineering consists of.

Signs that AI-generated technical debt is becoming your problem:

• increasing time spent debugging

• declining system performance

• production issues that keep recurring

• new features taking longer than the last ones did

• rising cloud infrastructure costs

• team members who can't explain how critical systems work

That last one is the one to watch.

When does vibe coding make sense?

One of the most cited vibe coding successes belongs to Pieter Levels, who spent about half an hour creating a game that almost immediately started generating thousands of dollars in revenue. He built a Python websockets server and a complete game system in Cursor.

Why it worked matters. Levels is a skilled programmer, an unusually effective marketer, and a founder with a long record of profitable projects and a large audience to launch into. The game is good evidence that AI can build complex systems quickly when directed by someone with a clear vision and real technical understanding. It isn't a benchmark to measure yourself against, and the wider data explains why: in Stack Overflow's 2025 survey, 72.2% of professional developers said they don't vibe code as part of their work, and only around 12% said they do.

Vibe coding is a real skill with real uses. It is also not how professional software gets built, and noticing that gap doesn't mean you're behind. There's still a lot you can do with it.

Rapid prototyping

Vibe coding is very good at validating an idea and producing a proof of concept. You can learn in an afternoon what used to take a sprint. Monterail's rapid prototyping process applies the same principle with more rigor: get something real in front of people in four weeks, before committing to a full build. It also helps to be precise about what a prototype is and what it can tell you.

Learning and exploration

CNBC's account of a two-day vibe coding class captures something that comes up repeatedly with non-technical founders. The value isn't only the app you end up with, it's discovering what's possible and being able to talk to engineers with a shared reference point. That makes every later conversation with a development team cheaper.

Internal and personal tools

Internal dashboards, data processing scripts, and workflow automation are strong candidates. The blast radius is small, the users are colleagues who will tell you when something breaks, and nothing customer-facing depends on it. This is also territory that low-code and no-code platforms have served for years, so it's worth comparing the two before you commit.

When should you avoid vibe coding entirely?

Three situations call for a firm no.

If your application handles sensitive data, requires compliance certifications, or needs enterprise-grade security, vibe coding is the wrong tool. Those requirements are specific, auditable, and unforgiving, and a model will not tell you which one you've missed.

Be careful with anything charged based on usage. A badly implemented API call inside a loop is an ordinary bug in a hobby project and a five-figure invoice in production. There are plenty of horror stories about people running up thousands of dollars in API charges from a single vibe-coded feature. Set hard spending caps before you deploy.

Don't expect vibe coding to handle complex business logic. Sophisticated algorithms, complicated data relationships, and rules with many interacting exceptions are where current models frustrate people most, and where the distance between "looks right" and "is right" is widest.

What has to be true before vibe-coded software ships?

Jason Lemkin kept vibe coding after the database incident, and published a detailed guide to avoiding a repeat. Combined with what the 2026 evidence shows, these are the conditions worth insisting on:

• Anything touching data gets verified independently. AI systems actively try to appear successful even when they're failing, so check database operations, authentication, API integrations, and backup and recovery yourself, or have someone check them for you.

• Your business logic is written down and the specs stay current. That documentation is the first thing a development team will ask for, and it holds its value whether you stay on the platform or leave it.

• Spending caps and alerts are configured on everything metered, before launch rather than after the invoice.

• Quality assurance exists as a process, not as clicking around the app before a demo.

• One person can explain how each critical piece works without opening the prompt history. If nobody can, you don't have a product yet.

Plan the handoff rather than discovering you need one. A hybrid approach uses vibe coding for rapid prototyping and brings developers in to turn it into production code, which is broadly how AI-assisted MVP work is done well. A complete rebuild treats your vibe-coded app as the specification, which sounds wasteful and often isn't, because you've already answered the expensive question of what to build.

Expect custom design to take substantial work, enterprise security features to need deliberate implementation, some integrations to be impossible on your platform, and performance optimization to be specialist work. If something isn't achievable today, treat that as information rather than failure. Lemkin's own note is fair: "the platforms are evolving rapidly; what's impossible today might be straightforward in six months."

What's next for vibe coding?

The most significant development since this article first ran is that the term's inventor moved on from it.

In April 2026 Karpathy described agentic engineering as the successor: directing coding agents against detailed specifications, reviewing their diffs, writing the tests, and holding the quality bar where professional software needs it. His framing is that vibe coding "raises the floor for everyone in terms of what they can do in software," while agentic engineering is about "preserving the quality bar of professional software." Both are real, and they are not the same job.

Willison's vibe engineering arrives at the same place from the other direction, spelling out what accountable AI-assisted work requires: automated tests, planning ahead, documentation, version control discipline, CI, code review, manual QA, and the judgment to know which tasks a model can be trusted with.

The tooling followed. Through 2026 essentially every major AI coding tool shipped some form of spec-driven development, where the specification is written first and the agent works against it. The direction of travel is toward more structure rather than less, which is reassuring for anyone who suspected that reviewing code still mattered. The same discipline applies well beyond code generation, whether you're deciding how AI fits into your architecture or into your delivery pipeline.

Will vibe coding tools replace software developers?

As things stand right now, vibe coding tools can't replace software developers. Not a chance.

The more useful exercise is to compare what people predicted with what actually happened, because 2025 produced an unusual number of dated, falsifiable forecasts.

The pattern is worth sitting with. The forecasts about volume were either badly timed or badly calibrated, while the forecast about the shape of the change was right. More code is written by AI every year, and it is still reviewed, tested, and owned by people. Google's own framing is that its engineers increasingly work as reviewers, which is a change in the job rather than the end of it.

The honest summary is that vibe coding platforms do two genuinely new things: they let people with no programming background build working software, which wasn't possible before 2023, and they let professional developers test ideas far faster than they could by hand.

Use it within reason, and don't expect a market-ready product from pure vibe coding. For that, you need to work with experts.

How should you approach vibe coding?

Treat vibe coding as one stage in a system rather than as a way of building products. It's very good at the earliest question, which is whether an idea is worth pursuing at all, and it answers that faster and more cheaply than anything before it. What it can't do is carry that answer into production, because production is defined by exactly the properties nobody checked.

The teams getting the most from AI are the ones DORA identified: teams whose practices were already sound, because AI amplified them. The tool doesn't set your ceiling. Your review process, test coverage, specifications, and clarity about who owns which system do that. Vibe coding raised the floor for everyone, and deciding what to build on top of it is still an engineering decision, and still yours to make.

When you get to that point, our team can take a working prototype and turn it into something you can sell, support, and scale, or scope the AI work properly from the start.