What is vibe coding?
Vibe coding is a style of building software where a person describes what they want in natural language, an AI coding tool generates the actual code, and the person steers the result mainly by prompting again rather than by reading and editing the code line by line. The judgment call that defines the term is where the human attention goes: toward whether the thing works when tested, not toward whether the code itself is well written or fully understood.
The term was coined by Andrej Karpathy, a well-known AI researcher and former Tesla and OpenAI leader, in a February 2025 social media post describing a new way of working where he would fully give in to the vibes, embrace exponentials, and forget that the code even exists. It spread fast through the developer community and was named Collins Dictionary Word of the Year for 2025, a sign of how quickly the practice moved from a niche habit to a mainstream one.
Adoption numbers reported in 2026 back that up. Independent developer surveys report that a large majority of professional developers now use AI coding tools on a daily or weekly basis, and GitHub has reported that a substantial share of newly written code across its platform is now AI-generated. What varies enormously between those developers is how much of that generated code gets reviewed before it ships, and that variation is exactly what separates disciplined AI-assisted development from vibe coding in its purest, most hands-off form.
Why vibe coding matters
Three shifts explain why this is now a real decision for any business building software, not just a curiosity for hobbyists.
- It collapses the time between an idea and a working demo. A non-technical founder or a small team can produce a functioning prototype in hours instead of weeks, which changes who can realistically test an idea before committing real development budget to it.
- It changes what a small team can attempt on its own. Tasks that used to require hiring a developer, a quick internal tool, a simple automation, a basic website, can now often be produced directly by someone without a traditional coding background.
- It introduces a real gap between code that runs and code that is safe to run. Working demo software and production-grade software solve different problems, and vibe coding is explicitly optimised for the first, which creates risk when the two get confused.
The trade-off worth being direct about: speed comes from skipping the review step that traditionally catches security issues, inefficient logic and subtle bugs. That trade makes sense for a throwaway prototype and makes considerably less sense for anything handling customer data, payments or public traffic.
How it works
Four elements distinguish vibe coding from earlier forms of AI-assisted development.
Natural language as the primary interface. Instructions are written in plain sentences describing intent and desired behaviour, not in code, and refinement happens through further prompts rather than manual edits to the generated output.
Outcome-based judgment. Code is accepted or rejected based on whether the running result behaves as intended, tested by using it, rather than reviewed line by line the way a traditional pull request would be.
Fast, disposable iteration. Bad results are usually discarded and re-prompted rather than debugged and fixed, treating generation as cheap enough that redoing it beats repairing it.
An honest scope limit, even when it is ignored in practice. The approach is genuinely well suited to prototypes, internal tools and throwaway scripts, and genuinely poorly suited to anything security-sensitive or difficult to unwind once deployed, a boundary that gets crossed more often than the risk profile would justify. IBM and other technology vendors now distinguish vibe coding from what they call agentic coding, where an AI system still writes most of the code but works inside a more structured process with defined checks, a distinction worth knowing since vendors increasingly market tools along exactly this spectrum, from fully hands-off generation to reviewed, checkpointed automation.
Implementation
The order below reflects how vibe coding tends to work well in a business context rather than becoming a liability.
- Match the tool to the actual stakes of the task. A quick internal script or a marketing landing page carries very different risk than a checkout flow handling card data, and the amount of human review should scale with that difference, not stay constant.
- Keep a human in the loop for anything touching real data or money. Full vibe coding without review is reasonable for a prototype and unreasonable for a system processing personal or financial information, where GDPR and basic security practice both apply regardless of how the code was written.
- Test with real inputs, not just the happy path the AI demonstrated. Generated code that works cleanly in a demo frequently breaks on edge cases, unusual input or scale that was never part of the original prompt.
- Have someone who can actually read code review anything before it reaches production. This does not mean abandoning the speed of vibe coding, it means treating the generated output as a draft from a fast but inexperienced contributor rather than as finished work.
- Keep a record of what the tool was asked to do and why. When something breaks months later, the ability to reconstruct the original intent behind AI-generated code matters far more than it does for code a developer wrote and remembers.
- Decide upfront whether the output is disposable or is meant to last. A prototype can be vibe-coded freely and thrown away. A component meant to run for years needs a different process once the prototype has proven the idea.
What it costs
The direct cost of vibe coding is low and often the main appeal, a single AI coding tool subscription commonly runs from roughly 20 to 200 euros per seat per month, well below the cost of a developer's time for the same output. For a non-technical founder testing an idea, that can mean producing a working prototype for a few hundred euros in tool costs rather than tens of thousands in development fees.
The hidden cost is remediation, and it can be substantial. Security researchers have documented that AI-generated code without review carries a meaningfully higher rate of vulnerabilities than code written and reviewed by an experienced developer, and fixing a security or architecture problem after launch, once real users and real data are involved, routinely costs several times what proper review would have cost upfront. The honest way to frame the economics is that vibe coding shifts cost from development time to review and remediation time, it does not eliminate the need for that expertise, only the point at which it gets applied.
There is also a less obvious cost worth naming: dependency on a tool a business does not fully understand. Code nobody on the team can read is code the team cannot confidently modify, debug or extend without going back to an AI tool for every change, which quietly recreates the same reliance a business would have on an external agency, just without the accountability or support contract that usually comes with one.
Conclusion
Vibe coding is a genuine shift in who can produce working software and how fast, not a passing trend, and businesses that ignore it are giving up a real speed advantage for prototypes and internal tools. Businesses that treat it as a substitute for engineering judgment on anything customer-facing or data-sensitive are trading a short-term speed gain for a real and often larger downstream cost.
The practical position for most SMEs is to use it freely for the fast, disposable, low-stakes work it excels at, and to insist on real review the moment code touches customer data, payments or anything the business cannot afford to get wrong.
