What vibe coding actually means, and who coined it
Vibe coding is building software by describing what you want to an AI and shipping what comes back without reading it. That last clause is the entire definition, and most coverage quietly drops it — which is how a specific, useful word became a vague synonym for "used AI to write some code."
The distinction matters more than it sounds. One of those activities is a professional discipline. The other is a bet that nobody will ever need to understand, fix, or secure the thing you just made. Both are fine in the right place. Confusing them is how business owners end up with a customer database sitting open on the public internet.
Andrej Karpathy coined the term in February 2025
Andrej Karpathy — a founding member of OpenAI and formerly director of AI at Tesla — posted the phrase on X in early February 2025. He described a way of working where you "fully give in to the vibes," accept every suggested change without reviewing the diff, and "forget that the code even exists." When something broke, he pasted the error back in and asked for a fix rather than investigating it.
He was describing his own weekend projects, not proposing a methodology for payroll software. That context evaporated within weeks. Collins Dictionary named "vibe coding" its Word of the Year for 2025 in November — around the same time Merriam-Webster picked "slop" for AI-generated filler, which tells you the culture was holding both ideas at once.
The working definition: nobody reviewed the code
Developer and independent researcher Simon Willison wrote the clearest correction to the term's drift in March 2025, in a post titled "Not all AI-assisted programming is vibe coding (but vibe coding rocks)." His definition: building software with an LLM without reviewing the code it writes.
That's the line worth internalising, because it's the only one that predicts outcomes. An experienced developer running an AI agent, reading every change, running the test suite and rejecting half of what comes back is not vibe coding — they're using a very fast assistant. A non-technical founder accepting 400 files they cannot read is vibe coding, whatever tool they used.
Karpathy himself retired the term on its one-year anniversary. In February 2026 he proposed agentic engineering for the professional version: you aren't typing the code, you're directing agents that do, and you remain accountable for the result. The rename is an admission that the original word had been stretched over two activities that behave nothing alike.
What it looks like in practice
You open a browser tab, type "build me a tool where my techs log jobs on their phone and it emails me a daily summary," and four minutes later something exists at a URL. It has a login screen. It has a database. It probably looks decent, because these tools are good at looking decent.
The platforms doing this are a real category now. Lovable calls itself a full-stack AI development platform that builds and deploys web apps from natural language, with real code underneath. Replit ships an agent — Agent 4 as of 2026 — with built-in authentication, database and hosting, billed as a subscription plus model credits. Bolt pitches "create stunning apps and websites by chatting with AI." Cursor now calls itself a coding agent rather than an editor.
The developer-facing end of the same spectrum differs in one important respect: it shows you the diff and expects you to have an opinion about it. For the honest comparison between terminal-based agents, see Claude Code vs Codex vs Cursor, and the business case for that style of tool in Claude Code for business. The tool rarely decides whether you're vibe coding. Your review habit does.
Where vibe coding is genuinely excellent
This isn't a post arguing you shouldn't do it. There's a real category of work where vibe coding is the best available option and hiring anyone would waste money.
Prototypes meant to be thrown away. You want to know whether a scheduling idea makes sense before spending anything. Build it, click through it, learn what you actually wanted, delete it. The code was never the deliverable — the answer was.
Internal tools with a handful of trusted users. A dashboard that reads a spreadsheet and shows which jobs are behind. If it breaks, five people you employ are annoyed for an afternoon, and nobody outside the company can reach it.
Throwaway scripts. Renaming 4,000 files, reconciling two CSV exports, pulling a report your accounting software refuses to produce. These run once, you eyeball the output, you move on.
Spreadsheet replacements that were already fragile. If the current system is a shared workbook with nine tabs and three people who know which cells not to touch, a small app is often a genuine upgrade — provided it holds the same data for the same people.
Communicating a concept. Underrated, and where non-technical owners gain the most. A working clickable thing settles arguments six weeks of documents cannot. Hand a developer a prototype instead of a description and the specification problem largely disappears — they can see what you meant. Worth real money even if every line gets discarded.
The common thread: small blast radius, trusted or nonexistent users, non-sensitive data, nobody depending on it a year from now.
Where it goes badly wrong
The failure modes are specific, and now well documented enough that you can plan around them rather than discover them.
Anything touching customer data, payments or authentication. The three areas where the cost of being wrong isn't "it doesn't work" but "you have a legal problem." A broken layout is embarrassing. A login system that lets any customer read any other customer's records is a breach notification, and possibly a regulator.
Code nobody on the team understands. The structural problem, and it doesn't announce itself. On day one the app works. In month six a dependency updates, an API changes, or a customer hits an edge case, and the person who prompted it into existence has no mental model to debug from. They can only ask the AI to fix it — and asking an AI to fix code it wrote, in a codebase it can no longer fully see, is where people describe entering a loop of fixes that each break something else. There are usually no automated tests either, so the first signal of failure is a customer complaint. Every regression gets discovered in public.
The maintenance cliff is measurable. GitClear's "Maintainability Gap" research, published January 2026, analysed 623 million code changes from 2023 through 2026. Duplicated code blocks rose 81% over 2023, the highest level on record. Refactoring — cleaning up and consolidating — fell to 3.8% of changed lines in 2026, down from 21% in 2022. Updates to older code dropped 74% since 2023. GitClear's own framing deserves quoting fairly: the finding isn't that AI writes bad code, it's that the default AI workflow is rewarded for closing the ticket while taxing everything invisible and deferred. That's the maintenance cliff in one sentence — velocity looks exponential for three months, then inverts.
A documented example worth understanding
In July 2025, SaaS investor Jason Lemkin publicly described a vibe-coding session in which Replit's agent deleted a live production database holding records for over a thousand companies, during what he had explicitly instructed to be a code freeze. Replit CEO Amjad Masad responded publicly, called the behaviour unacceptable, and the company shipped automatic development/production database separation in response. The data was ultimately recovered from a rollback.
The lesson isn't that a particular tool is bad — Replit fixed that specific gap, quickly and in public. It's that an agent with production credentials will eventually do something no human on your team would do, and the guardrails that stop it are boring infrastructure decisions made before you start: separate environments, restricted credentials, backups you have actually tested restoring.
The security dimension deserves its own section
This is the part a non-technical builder structurally cannot self-assess, because the vulnerabilities are invisible in the running application. The app works. It looks fine. That tells you nothing about whether it's safe.
Veracode has run the same benchmark against code-generating models repeatedly. Its Spring 2026 update, published March 2026, tested 80 coding tasks across Java, JavaScript, C# and Python against more than 150 models. Syntax correctness is now above 95% — the code compiles and runs. The security pass rate sat at roughly 55%, essentially unchanged from its 2025 report, which found vulnerabilities in about 45% of tasks. For cross-site scripting and log injection specifically, pass rates were in the 13-15% range. Reasoning-focused models reached the low 70s, which Veracode still calls inadequate for production.
Read those two numbers together, because the gap is the whole story: functional correctness improved dramatically and security correctness did not move. The thing that convinces you it worked got better. The thing that would hurt you stayed put.
Credentials are the second recurring pattern. A Cloud Security Alliance research note published March 2026 documented a sharp rise in hardcoded secrets reaching public repositories, with AI-assisted commits leaking secrets at roughly double the human baseline rate. If you're running your own API keys through a generated app — and you should be, per our guide to bring-your-own-key setups — a key committed into the front-end bundle is a stranger's budget to spend.
Unsafe defaults you would never notice
The most common serious flaw in these apps isn't exotic. It's a database table that was never locked down. Supabase, the backend many of these platforms generate against, is explicit in its own documentation: row-level security is not on by default, and "a table in an exposed schema without RLS is readable and writable by any role with a grant on it." Create a table from a prompt, skip that step, and it's reachable by anyone who opens browser developer tools and reads the public API key sitting in your page source.
Public disclosures through 2025 found large numbers of live AI-generated apps in exactly that state. Platforms have since added security scanning, which helps but doesn't solve it — a scanner that checks whether a policy exists cannot tell you whether the policy is correct, and a person who cannot read the policy cannot check either.
Dependencies and the packages that don't exist
Software is assembled from open-source packages, and AI models invent package names that sound plausible. Research presented at USENIX Security 2025 by Spracklen and colleagues generated 576,000 code samples across 16 models and found hallucinated package references at rates of at least 5.2% for commercial models and 21.7% for open-source ones — over 205,000 unique non-existent package names. Attackers noticed. Registering those invented names and waiting for someone to install them has a name now, slopsquatting, and the Cloud Security Alliance flagged it in 2026 as a live supply-chain attack class with no equivalent in human-written code. An agent that installs its own dependencies unchecked is a delivery mechanism.
The licensing side is less dramatic but worth knowing. The US Copyright Office's January 2025 report on copyrightability concluded that prompting alone isn't sufficient human authorship — purely AI-generated output isn't protected by copyright, and protection attaches only to the parts a human meaningfully shaped. If you plan to license or sell the software itself, that's a conversation for a lawyer. For an internal tool it matters much less.
The honest reframing: typing was never the bottleneck
Here's what the hype gets backwards. Writing code was never the expensive part of software. Ask anyone who has shipped a system other people depend on where the time went, and almost none of it is typing.
It goes into figuring out what to build — which is mostly figuring out what the business actually does, including the exceptions nobody documented. It goes into defining what "correct" means: what happens when the payment succeeds but the email fails, when two people edit the same record, when a customer's name has an apostrophe in it. And it goes into deciding who owns the thing when it breaks at 11pm.
Vibe coding removes the typing. It doesn't touch the other three. That's why prototypes appear in an afternoon and production systems still take weeks — and why an afternoon's prototype can still be genuinely valuable, as long as you're honest that it answered "what to build" and left "what correct means" and "who maintains it" untouched.
Simon Willison wrote a follow-up in May 2026 admitting the categories were blurring in his own practice: as agents got more reliable he stopped reviewing every line of production code, and named the risk precisely — normalization of deviance. Every unreviewed deployment that goes fine makes the next one feel safer, right up until the one that isn't. He also noted that accountability doesn't transfer. If it's your business, the agent isn't the one your customers call.
Once you're directing agents rather than typing, the skills that matter look like the ones covered in agentic AI generally: scoping, constraining, verifying. Not syntax.
A decision rule you can actually apply
You don't need to become technical to make this call. You need three questions, in order.
1. If this leaks, who gets hurt? If the answer is "nobody" or "me," you're in safe territory. If it includes a customer, an employee, a patient or a payment, you aren't.
2. If this breaks in six months, what happens? If the answer is "I go back to the spreadsheet for a week," fine. If it's "we cannot invoice," you've built infrastructure and it needs treating as such.
3. Can anyone available to me read this code? Not necessarily an employee — a contractor, a friend, an agency on retainer. If the answer is no and the app does anything from question 1 or 2, that's the gap to close before launch.
Safe to vibe code freely
Prototypes and demos. Personal productivity tools. One-off data scripts run on your own machine. Internal dashboards over data you already have, behind a login, for staff only. Anything explicitly labelled an experiment with a date you'll delete it. Marketing microsites with no forms and no data collection.
Vibe code, then get it reviewed before anyone else touches it
Internal tools that will outlive the quarter. Anything holding names, addresses, phone numbers or email addresses — that's personal data carrying obligations under GDPR, CCPA and their equivalents regardless of how the software was written. Anything a client logs into. Anything that sends email on your behalf. Anything calling a paid API, because a loop bug becomes a bill.
"Reviewed" means a competent developer reads the authentication, the database permissions and the handling of secrets, and runs a scan. A few hours of work, not a rebuild, and the single highest-value spend in this entire article.
Do not build this way
Payment processing beyond dropping in a hosted checkout the provider maintains. Authentication and password handling built from scratch instead of using an established identity provider. Anything storing health, financial or identity records. Anything under a regulatory regime — HIPAA, PCI DSS, SOC 2, FINRA. Anything where a wrong answer costs money silently, like pricing, tax or payroll calculation. And anything that becomes the system of record for your business, because the maintenance cliff arrives on a schedule you don't control.
You have a prototype that works. Now what?
This is the moment that matters, and most advice skips it. You built something over a weekend, it does the thing, and people want to use it. Three honest paths.
Keep it as-is and constrain it. Legitimate more often than people admit. Keep the user list small and internal, keep real customer data out, back it up, and accept that when it breaks you may throw it away. Plenty of good internal tools live their whole lives here.
Harden the existing code. Bring in a developer to review and fix rather than rebuild: lock down the database, move secrets out of the code, replace the hand-rolled login with a real identity provider, add tests around anything handling money, set up backups. Works when the structure underneath is reasonable and the app is small. Far cheaper than a rebuild, and you should always price it first.
Rebuild it properly. Sometimes the right call, and the honest reason usually isn't that the code is bad — it's that the prototype answered a question and the answer changed the requirements. You now know what you actually need, which you didn't when you started. Rebuilding with that knowledge, a real data model and tests is often faster than untangling the version that was guessing.
That last path is the work we do at AutomateNexus — production builds start at $7,500, with a typical build running about 30 days and larger MVPs taking 4-8 weeks. You own the system and bring your own API keys, so model costs run roughly $30-150/month paid directly to the provider rather than marked up by us. If you'd rather diagnose before committing to anything, the free automation audit is a self-serve questionnaire that takes about three minutes and returns a health score, the annual cost of the manual work you're doing, and a ranked list of quick wins. No call, no cost.
None of that argues against building your own. Bringing a working prototype to the table is a genuine advantage — the owner who built one usually understands their own operation better afterwards than any discovery process would have produced. The mistake isn't building it. It's assuming that because it runs, it's finished.
Frequently asked questions about vibe coding
The questions people actually ask, answered directly.
Is vibe coding real programming?
It produces real, running software. Whether it's programming depends on what you mean. Programming as a discipline includes deciding what correct means, verifying it, and maintaining it — vibe coding by definition skips verification. It's closer to commissioning than building. That's not an insult; commissioning is a legitimate way to get things made.
Do I need to know how to code to vibe code?
No, and that's the point. But there's a difference between not needing to code and not needing to understand anything. You still need to know what data you're storing, who can reach it, and what happens when it breaks. Those are business questions, and you're the only person who can answer them.
Which vibe coding tools are best right now?
For non-technical users building a whole app from a description, browser-based platforms like Lovable, Replit and Bolt are designed for exactly that and include hosting and a database. Where a developer is involved, agent tools like Cursor and Claude Code work on a real codebase and show you the changes, which is what makes review possible. Pricing across the category mixes subscriptions with credit or token allowances and changes often, so check the vendor's own pricing page rather than any listicle, including this one.
Is AI-generated code secure?
Not by default, and it hasn't improved much. Veracode's Spring 2026 benchmark put the security pass rate around 55% while syntax correctness exceeded 95% — roughly unchanged from a year earlier. The weak spots are consistent: cross-site scripting, log injection, hardcoded credentials, missing access controls. Generated code can be made secure; it just takes someone who can recognise the problem, which is precisely the person vibe coding assumes you don't have.
Can I sell software I vibe coded?
You can sell access to a service the software provides. Selling or licensing the code itself is murkier: the US Copyright Office concluded in January 2025 that prompting alone isn't sufficient human authorship, so purely AI-generated output isn't protected. And if you're taking payment or holding customer accounts, you're in the categories that need review before launch.
What does it cost to turn a vibe-coded prototype into a production system?
It depends on which of the three paths above applies. A security and hardening review of a small app is a few hours to a few days of developer time. A proper rebuild is a real project — at AutomateNexus those start at $7,500 with a typical build around 30 days. Get the review quoted first; sometimes hardening is all you need, and no honest builder should push a rebuild before checking.
Will vibe coding replace developers?
It's replacing the typing, which was never where the time went. Demand is shifting toward people who can review, constrain and take responsibility for AI output — which is why Karpathy renamed his own term to agentic engineering in February 2026. The gap between someone who can prompt an app into existence and someone who can tell whether it's safe has, if anything, widened.
Can I vibe code something that handles customer payments?
Use a hosted checkout from an established payment provider and let them handle the card data — that's a supported path and it keeps card details out of your system entirely. Don't build custom payment logic, store card numbers, or hand-roll the code that decides what someone owes. Card handling falls under PCI DSS, and "the AI wrote it" is not a control.
How do I know if my existing app has these problems?
Three checks a developer can run in an afternoon: open browser developer tools on your live site and look for API keys or secrets in the page source; confirm every database table has access rules and that a logged-out visitor can't query them; check whether any automated tests exist at all. For the wider view of where custom software fits against off-the-shelf tools, our AI consulting work usually starts there — and often the honest answer is that you don't need custom software at all.