Prototyping with AI: what vibe coding is really worth

Prototyping with AI is worth a great deal — provided you know what you'll be left holding at the end. Vibe coding, the practice of describing in natural language what the software should do while a model produces the code, compresses exploration from several weeks to a few days. What it produces remains a prototype: perfect for deciding, unfit for serving customers. The entire value of the practice lies in that distinction.

Article published in March 2026, revised on 25 May 2026, reviewed on 7 July 2026.

Vibe coding, a definition without the mythology

Vibe coding refers to a development practice where intent expressed in natural language precedes the code: you describe the expected functionality, a system powered by a generative model produces the implementation, you review it and adjust it. The term spread in early 2025 — the phrase is attributed to a leading AI researcher — and it triggered a public conversation disproportionate to its actual scope.

For some, the end of software development. For others, a novel category of technical debt. The observable reality sits between the two: the prototyping phase is transformed in depth, production discipline is not, and confusing the two comes at a cost.

What it changes when you're testing an idea

A prototype has only one purpose: to allow a decision on whether an idea is worth the effort of building. Under that criterion, vibe coding changes the game on speed, access, and plurality. Speed: a prototype that used to take a lone developer several weeks now comes together in a few days, sometimes a few hours for a simple concept — what was too costly to validate becomes testable. Access: a product manager, a consultant, a business analyst can produce a working prototype that concretely expresses their intent, without going through the filter of a technical team. Plurality: producing several variants of the same concept in parallel and keeping the one that survives contact with reality becomes affordable, which changes the quality of product decisions.

I speak from direct experience. FiscalDoc, the local application that handles my taxes, was born exactly this way: described, dialogued, adjusted over three evenings. The full account is published in FiscalDoc, or replacing a SaaS with local AI, and the tooling I use is described in my hands-on account of Claude Code.

What the prototype doesn't give you

Three zones remain untouched by vibe coding's promises, and they come at a high cost when ignored.

Invisible debt first. Code produced through iterative dialogue often works, but its overall coherence is guaranteed by no one. Every addition quietly complicates the whole, and the cost reveals itself precisely at the moment the prototype should become a product — that is, too late to fix without a substantial rewrite.

Security next. Generated code works along the nominal path; error cases, injections, permissions, edge conditions — everything that makes up application security — aren't handled systematically. Acceptable for a mock-up tested in a closed loop. Dangerous in front of real users.

Compliance finally. Regulated Swiss sectors — finance, healthcare, insurance — require traceability of technical choices that dialogue-driven generation doesn't naturally produce: processes that are not very deterministic, choices rarely documented, reviews lightened by design. Nothing disqualifying for a prototype; everything becomes so in production.

The rule of thumb: validate with it, build without it

The rule I apply comes down to two sentences. Vibe coding is the right tool to validate that an idea deserves to be built; it is not the tool to build it afterwards. This distinction isn't a concession to caution: it's the most effective use of the practice itself.

The teams that get the most out of it prototype fast, validate what needs validating, then cleanly rebuild what has proven its value — architecture, tests, review. Those who push the prototype into production accumulate a debt that gets paid in the following months, one no further round of prompting will repay. Clean rebuilding, meanwhile, falls under scoped custom development: a different working regime, with a different level of rigour.

Four situations where I don't even prototype

Even for exploration, some contexts fall outside the frame.

• Real data. A prototype that handles identifiable customer, financial, or medical data exceeds what prototype status can absorb. Fictional or anonymised data, an isolated environment — no exceptions.
• Public exposure. A prototype online with no access control is a production deployment without the corresponding rigour. It's the most common operational mistake among teams adopting the practice without scoping it.
• A connection to your production systems. Connected to your management software, a business database, or a critical API, a prototype bug has real consequences. A separate environment, always.
• No review. No one shows a prototype to a client, an investor, or a user without a competent person having been able to say whether the result holds up.

And what about FiscalDoc, then?

One could object that FiscalDoc, a prototype dialogued into existence over three evenings, still runs at my place every day. That's true, and the scope explains everything: one user — me —, my own data, a local machine, no network exposure, no third-party data. That's precisely the scope within which a prototype can live for a long time. The day a tool of this kind should serve someone other than its author, it gets rebuilt with production discipline.

Apply the same test to your prototypes: if their scope resembles that one, they can live; if not, rebuild before the debt decides for you.

What this calls for in your organisation

For a Swiss SME, the challenge is less technical than a matter of scoping. Explicitly define what can be prototyped in vibe coding and what calls for supervised development — this clarification takes shape within a few weeks and avoids improvised trade-offs. Keep the dialogues that produced good results: it's a body of method that gets passed on, rather than tacit knowledge that fades away.

And connect the practice to your real priorities. A prototype is only worth as much as the hypothesis it tests that actually matters, which presupposes having mapped your flows and your automation projects beforehand. For the order of these projects, the general framework is in What should a Swiss SME do about AI in 2026?.

Key takeaways

— Vibe coding compresses exploration: what used to take weeks is tested in a few days, even without a technical background. — What it produces remains a prototype: invisible debt, security, and traceability rule out putting it into production as-is. — Validate with the prototype, cleanly rebuild what has proven itself: the rule fits in one sentence.

FAQ

Can a non-developer really prototype alone? Yes, to explore and express an intent: the resulting prototype is worth more than an abstract brief, because it can be tested. Before showing it outside the team or connecting it to anything, review by a competent person remains necessary.

Can a prototype be kept in production? Only if its scope stays that of a prototype: a single user or closed circle, non-sensitive data, no public exposure, no link to your critical systems. As soon as one of these walls falls, rebuilding becomes necessary. FiscalDoc lives at my place precisely because it respects these limits.

How much does an AI-assisted prototype cost? In-house, often just a few days of work where it used to take weeks — that's the core of the gain. On a mandate, the amount depends on scope: demand a written scope and a fixed price before starting, and be wary of a prototype sold as a finished product.

What's the difference between vibe coding and AI-assisted development? Vibe coding aims at exploration: intent precedes code, review is light, the result is disposable by design. AI-assisted development preserves production discipline — architecture, tests, systematic review — using AI as an execution accelerator. Same family of tools, two different working regimes.

What about your ideas on hold? The AI Usage Diagnostic: sixty minutes to map your real flows, identify what deserves a custom-built solution, what stays in SaaS, and what needs no AI at all. Book a diagnostic

Jérôme Deshaie is CEO and founder of MCVA Consulting SA, an augmented agency based in Valais. Fifteen years serving major international brands, now working directly with Swiss SMEs. Background.