Vibe coding: what it is, how it works, and how reliable it is.
You built it in an afternoon. The demo works, the UI looks sharp, and the deployment succeeds. And then the first real users get their hands on it, and all sorts of things break that you never even built. Welcome to the reality of vibe coding: software development where you describe what you want in plain language, and AI generates the code. Lightning-fast for prototypes. Production software requires more. In this article, you’ll learn exactly what vibe coding is, how it works, how reliable it is, and how a working prototype compares to software that can handle real users, real data, and real responsibility.
What exactly is vibe coding?
Vibe coding is a method of software development in which you give an AI tool a command in natural language, and the tool writes the code itself. No syntax you need to know in advance, no frameworks to memorize, no typing line by line. You describe what the software needs to do, and the AI builds it. The term was coined by Andrej Karpathy, co-founder of OpenAI. As early as January 2023, Karpathy summed up the direction in a single sentence: “the hottest new programming language is English.” Two years later, in February 2025, he gave it a name in a short post on X: “vibe coding.” What began as a tweet became, within a year, a working method that founders, product managers, and even experienced development teams actively use to quickly bring ideas to life.
How does vibe coding work in practice?
The workflow is surprisingly short. You open a tool like Cursor, Lovable, v0, Replit, Bolt, Windsurf, Claude Code, Gemini Code Assist, or GitHub Copilot. You type something along the lines of: "Build a web app where users can track their monthly expenses, with a login and a dashboard." Within seconds, the tool starts generating code. A moment later, a working preview appears. What follows is a conversation. You ask for adjustments: “make the header dark,” “add a filter by category,” “make sure it works on mobile too.” The AI adjusts the code, the preview refreshes, and you continue building iteratively. This shifts the user’s role. You are no longer a programmer in the traditional sense. You are more like the director of an AI that does the actual work. For people without a development background, this opens up a world that was previously closed off. For experienced developers, it’s an acceleration: what used to take days is now done in a few hours.
Vibe coding, AI-assisted development, agentic engineering en low-code.
In discussions about AI in software development, four different approaches are often lumped together. They all use AI or automation to some extent, but the differences between them determine whether the result is suitable for a prototype or for production software. Let’s break them down.
Vibe coding is intuitive and fast. The AI does most of the work, with minimal human oversight, and the result is ready in a matter of hours. It’s ideal for prototypes, experiments, and validating an idea. The output is meant to demonstrate a concept, not to last for years.
AI-assisted development is what many developers do every day. The engineer is in the driver’s seat and uses AI as a tool: to get suggestions, speed up refactoring, generate test code, and supplement documentation. The human remains the author and reviewer. AI makes the work faster, but the discipline of the profession does not change.
Agentic engineering takes it a step further. AI agents independently undertake multi-step engineering tasks within clear frameworks: they write code, run tests, assess the architectural principles, perform security checks, and deliver a review-ready change. Humans set goals and monitor those frameworks. Tests, architecture, security, and review are fixed components of the process, not optional.
Low-code and no-code are something else. Bubble, Webflow, OutSystems: visual platforms where you build apps from ready-made blocks. Not an AI paradigm, but an abstraction paradigm. You work faster than with code, but within the limits the platform has predetermined.
These four approaches are not mutually exclusive. In practice, you see a lifecycle: an idea is prototyped to see if it works, and then development teams take over using AI-assisted or agentic methods to turn it into production software. Which approach is best depends on what you need at that moment.
How reliable is vibe coding?
For prototypes and experiments: highly reliable. You’ll have something working within hours. For production software: not without further engineering. That difference is greater than many people realize, and this is where things usually go wrong. The problem is that a Vibe-coded demo looks complete. The UI is polished. The deployment succeeds. It works on your laptop. And then real users show up. At that moment, things break that were never visible in the tool.
The hidden layers beneath a vibe-coded demo.
What looks like a finished product is actually just the front end and back end built on top of layers that haven’t been developed yet. These layers don’t appear in a Lovable preview or a Cursor screencast. Yet that’s exactly what sets a working demo apart from software that people actually pay for.
Authentication, Authorization, and Row-Level Security.
Login usually works in the demo. But Row Level Security—the mechanism that ensures User A can never see User B’s data—is rarely enabled. Permissions are hardcoded rather than role-based. One well-crafted URL, and your clients’ data is out in the open.
Hosting, deployment en CI/CD.
There is no staging environment. No version control with a review process. No rollback if something goes wrong. Code goes from the command line to production without a second pair of eyes checking it. With every change, you just have to cross your fingers.
Security, rate limiting en secret management.
APIs without rate limiting can be overloaded or drained by a single actor who keeps hammering away at them or targets the most expensive endpoints. API keys and passwords are often hard-coded right into the code, ready to be leaked via a Git commit or browser inspection.
Database hardening en performance.
No indexes, no query optimization. The first actual query on a hundred records runs smoothly. With a hundred thousand, the database freezes. A backup strategy is usually completely absent, so if something goes wrong, the data is lost.
Monitoring, logging en disaster recovery.
Errors quietly pile up without anyone noticing. No tracking, no alerts, no incident response. The user sees a blank page; the development team sees nothing. If the server goes down, there is no recovery plan, because one was never put in place.
What this means for B2B and regulated sectors.
For organizations in regulated sectors, compliance issues come into play on top of the technical layers, yet these are not addressed in any of the prompts. Personal data is processed without a processing register, legal basis, or DPIA. Audit trails for ISO 27001, NIS2, or NEN 7510 are missing. Access control cannot be demonstrated. Code provenance (i.e., who wrote what, when, and why) has been lost in the command history of a single person. For organizations where compliance is not an afterthought, this means that a Vibe-coded app cannot simply go into production.
Where vibe coding really shines.
With all these caveats, vibe coding might sound like child’s play. It isn’t. When used correctly, it changes how ideas are generated and validated within organizations. Prototypes and proof-of-concepts are the most obvious benefits. An idea that used to take a week to sketch out can now be demonstrated in working order within an afternoon. Internal tools, small disposable experiments, demos for stakeholders: all areas where vibe coding simply works. Validating an idea before serious money is invested no longer has to be a PowerPoint presentation, if you can build a clickable version in a few hours. In our practice, we see this as a healthy phase in the lifecycle of software ideas. A vibe-coded prototype that has been validated internally and gained support proves that a direction works before a larger investment is made. It makes discussions about the next step concrete, because there is something tangible on the table.
From a Vibe-coded prototype to production software.
The transition from a working prototype to production-ready software is not an iteration. It is a redesign that begins with a straightforward question: what parts of the prototype are reusable, what needs to be discarded, and which assumptions in the original prompts have become problematic? Asking that question requires a different kind of work than building the prototype itself. That doesn’t mean everything has to go. A data model or a UI design is often usable. It means you shouldn’t build on assumptions that were never intended for production.
What the transition requires from a technical standpoint.
The invisible layers aren’t “added later.” They are conceived, designed, and built. The existing code is adapted or rewritten accordingly. This isn’t fortune-telling; it follows from how production software works: authentication belongs in the architecture, not tacked on top of an existing structure. Monitoring must be part of the deployment pipeline, not a dashboard that’s turned on after the fact. Compliance requires that audit trails be accurate from the first commit, not that they be reconstructed later.
For clients in regulated sectors, there is an additional consideration: the choices made in the prototype must be assessed against the requirements applicable to their sector. What was considered acceptable in a Lovable preview is rarely acceptable in a NEN 7510- or ISO 27001 context. The code review and architecture audit that kick off such a process are therefore just as much a discussion about what the organization needs around it as about what the code itself does.
What "agent-based engineering" means in this context.
Karpathy himself now considers vibe coding to be almost obsolete and describes agentic engineering as the next phase. So the coiner of the term has already moved on. Agentic engineering works differently from vibe coding and differently from traditional AI-assisted development. An AI agent no longer receives a single code suggestion, but rather a multi-step task within predefined parameters: implement a function in accordance with the existing architecture, write the corresponding tests, verify that security rules are being followed, and submit a merge request. The agent carries out these steps independently and flags anything that may not fit. The crucial difference lies in the parameters. Tests are mandatory, not optional. The architecture is predefined and serves as the benchmark for every change. Security checks are part of every step. And the human review is not a formality, but the moment when an experienced engineer assesses whether the work is correct, fits into the bigger picture, and will withstand the demands of the next two years.
At Cube, we’ve found that this approach works as long as the boundaries are strictly enforced. AI speeds up the work, but professional discipline determines whether the work is sound. A developer who strays beyond their boundaries produces something that looks like progress but is actually technical debt. A developer who stays within strict boundaries delivers tested, traceable work that fits into a scalable architecture.
What this means for production software.
The difference between a vibe-coded prototype and one that’s taken to production is clear in a few key areas: Software that scales without requiring a complete rebuild in year two, because scalability is built into the architecture from the start. Codebases that remain maintainable for changing teams, because the structure is consistent and doesn’t depend on a single person who can still reconstruct the prompt history. A development process that is verifiable for audits, because tests, reviews, and changes are traceable. A turnaround time that keeps pace with what AI makes possible, without compromising on quality, security, or compliance.
There’s also something a bit less tangible to it: contributing ideas on process and technology. Which feature deserves priority, which integration is better off postponed, which architectural choice will give you the most flexibility in two years’ time. Those kinds of questions are rarely answered by an agent. That’s exactly where engineering expertise continues to matter, even (and especially) at a time when AI is taking over much of the operational work.
Putting vibe coding into perspective.
Vibe coding isn’t a passing fad, nor is it a replacement for professional software development. It’s a new layer in how software is created. An idea that used to get stuck in the design phase for weeks can now be up and running within a day. That’s a win, regardless of what comes next. At the same time, that speed doesn’t change what production software requires. Authentication, monitoring, compliance, scalability, maintainability: those layers exist because without them, software breaks down when it matters most. They don’t disappear just because you don’t build them; they still show up in the form of data breaches, downtime, or audit findings.
The two worlds follow one another.
Vibe coding quickly proves that an idea works. A development team that works in an AI-assisted and agentic manner then ensures that the working idea is ready for production. AI as an amplifier, craftsmanship as the foundation. For organizations currently working with a functional prototype, this may be the most important takeaway: the demo is not the end point; it is the starting point for a conversation about what this could become when real users, real data, and real responsibility are brought into play.
Ready for the next step? We are too.
Do you have a vibe-coded prototype built with that’s starting to show its limitations? Or would you like to brainstorm how to use AI without compromising on scalability, security, or maintainability? We help organizations move from proof of concept to reliable production software.
Worth reading next...
Remi on software architecture: Build today what will still work tomorrow.
MCP integration: connect AI securely to your business systems.
Four database technologies we use at Cube.
Questions? No problem.
Vibe coding is a type of software development where you describe what you want in plain language, and AI generates the code. The term was coined by Andrej Karpathy (February 2025). Collins Dictionary named vibe coding its Word of the Year for 2025.
You provide an AI tool like Cursor, Lovable, or Claude Code with a description in natural language. The tool generates the code, sets up a prototype, and immediately provides a working preview. You can then refine it with additional prompts to adjust features, design, or functionality.
Highly reliable for prototypes and experiments: you can have something up and running within hours. For production software, however, further engineering is required. Vibe-coded apps almost always lack authentication, monitoring, rate limiting, and compliance, making them unsuitable for B2B and regulated sectors without a review and enhancement of the critical layers.
The term was coined by Andrej Karpathy, co-founder of OpenAI. He described the approach as being guided entirely by intent and intuition, without even looking at the code itself. The programmer acts more as a director than an engineer: the AI does the actual work.
In vibe coding, AI does most of the work while a human provides limited oversight, making it suitable for prototypes. In AI-assisted development, the engineer is in the driver’s seat and uses AI as a tool. Agentic engineering goes a step further: AI agents independently perform multi-step tasks within defined parameters for testing, architecture, and security, with an engineer guiding them toward specific goals and parameters.
Rarely a one-to-one fit. The code usually lacks authentication, error handling, rate limiting, and compliance requirements. An experienced development team assesses which components are reusable and which need to be rebuilt based on the original functional specification. Often, a targeted rebuild is more cost-effective than patching AI-generated code.
The biggest risks include data breaches due to inadequate access controls, downtime caused by a lack of monitoring and disaster recovery, liability in the event of GDPR incidents, and technical debt that makes any further development more expensive. In regulated sectors, non-compliance with ISO 27001, NIS 2, or industry-specific requirements adds to these risks.