Vibe coding agency.

Vibe coding means programming by describing: you tell a language model in ordinary language what should exist, you check the running result, and you describe the next change — rather than writing or fully reading the generated source yourself. The term goes back to Andrej Karpathy, who popularised it in early 2025, and Collins Dictionary chose "vibe coding" as its word of the year 2025. So it describes an attitude towards code, not a technology.

The decisive part sits in the word "vibe": what gets judged is the behaviour of the program, not the way it is built. It runs, it looks right, it does the right thing — carry on. That omission is the entire time saving of the method. It is also the reason a system built this way becomes hard to change after a few weeks: nobody knows the structure any more, because nobody decided it.

The distinction from "using an AI assistant" matters. Almost every developer does the latter today — in the Stack Overflow survey 2025, 84 per cent use such tools or plan to. Vibe coding in the narrow sense, meaning the deliberate choice to stop reading the code, was named as part of their work by only around 12 per cent in the same survey. The term is far more present in the discourse than in practice.

Vibe coding delivers speed at the beginning: from idea to a clickable, testable result in days rather than weeks — wherever something new is being built and a mistake costs nothing. That is not a marketing promise but a consequence of the type of task. An empty project has no history, no dependencies and no legacy; that is exactly the situation where language models are strong.

• Prototypes and clickable demos. An idea becomes visible before a budget has been approved for it. That shifts the discussion from opinions to observations.
• Variants instead of guesses. Three implementations of one interaction pattern side by side now cost hours rather than days. You decide on screen, not at a whiteboard.
• Throwaway tools. Data preparation, migration scripts, small internal helpers that run once and are never needed again.
• First drafts. Component skeletons, sample data, test cases — material a human then reworks instead of typing from nothing.
• Unfamiliar territory. A foreign API or a new framework becomes comprehensible faster, because a running example arrives sooner than the read documentation.

For founders that is the commercially interesting part: the most expensive decision in software is spending a year on something nobody needs. A fast result, honestly labelled as a prototype, answers that question before it gets expensive. That is exactly what our prototype validation aims at, and the accompanying look at business model and market belongs in startup consulting.

Vibe coding fails at four points, and it does so reliably: maintainability, security, test coverage and architecture — as soon as a system grows beyond its first size. These four are not opinion. They are the points at which the bill arrives in practice.

Maintainability. A prototype is untidy after a week and impenetrable after a month. Because nobody decided the structure, it emerges by accident: the same logic in three places with slight differences, naming that contradicts itself, dead paths nobody dares delete. The Stack Overflow survey 2025 names the consequence: 66 per cent cite "almost right" solutions as their biggest friction, and 45 per cent say debugging AI-generated code takes longer than debugging their own.

Security. Here the evidence is unambiguous. In the Veracode report of spring 2026, over 150 language models were tested on 80 tasks in Java, JavaScript, C# and Python. Without an explicit security instruction in the prompt, only 55 per cent of results passed the check; for cross-site scripting it was 15 per cent, for log injection 13 per cent. Over the same period syntactic quality rose from roughly 50 to 95 per cent — security did not. A model writes what works, not what withstands an attack.

Test coverage. Tests appear in vibe coding only when you explicitly ask for them, and even then they tend to check the happy path rather than the exceptions. That goes unnoticed for exactly as long as nobody changes anything. At the first larger rebuild the safety net is missing — the net that decides between half an hour and half a week.

Architecture. Language models work locally and optimise the next file, not the whole. Beyond a certain size, though, a system needs decisions that only make sense globally: where the boundaries between modules sit, which data is the source of truth, what may be synchronous and what may not. We make those decisions by hand — they are the part of the work that will still belong to people in ten years.

We use vibe coding where speed creates the value and a mistake stays harmless, and we switch it off where a silent error would only surface weeks later. The line does not run between "simple" and "complex". It runs between "disposable" and "owned".

• Used for: prototypes for idea validation, clickable demos for stakeholder sessions, design variants, sample data, internal helper scripts, first drafts of components and test cases, exploring unfamiliar interfaces.
• Not used for: authentication and permission handling, payment processing, processing personal data, migrations on production databases, anything with a legal obligation attached — and, generally, any code nobody would have read in the end.

In client projects one simple rule applies, and we put it in writing: no code goes live that a human has not read, understood and taken responsibility for. AI speeds up the route to a draft here; it replaces neither the review nor the liability. What that process looks like in detail — which steps AI takes over, which steps it demonstrably slows down — is on AI-assisted development.

For the finished, operated site the same standard applies as before the AI wave: clean server-side rendering, good Core Web Vitals, maintained structured data. That is the standard we build premium websites and more complex web solutions to. A prototype does not meet it by definition, and that is not a shortcoming but a division of roles.

A prototype built by vibe coding is an instrument for learning, not a product: it exists to test an assumption, and it may be thrown away afterwards. That permission to throw it away is where the value actually sits. It lowers the price of knowing something far enough that you can afford to be wrong.

The most expensive mistake in this field is the creeping change of role: the prototype convinces, somebody shows it to a client, the client wants to use it — and suddenly a learning instrument is running on real data, with no permission handling, no tests, no logging. From that moment you repay the saved effort with interest, usually at the least convenient time.

We therefore fix the role in writing and state before we start what a prototype does not include with us: no robust access control, no scaling, no accessibility audit, no automated tests beyond the main path, no operational monitoring. If the idea holds, the prototype is not "finished off" — the part that carries is rebuilt with proper architecture, often faster, because the open questions have by then been answered.

That is exactly why the method fits the validation model: a prototype for idea validation starts at CHF 10,000 with us and answers a question whose wrong answer can run into six figures. Skip that step and you are buying certainty you do not have. The full process is described under prototyping with AI and prototype validation.

Vibe coding is the wrong choice as soon as a system processes other people's data, falls under regulatory obligations, has to be maintained for years, or is changed by several teams at once. We say so in the first conversation, even when it argues against the faster commission.

• Personal data and payments. Once the revised Data Protection Act, retention obligations or card data are involved, you need vetted components and documented decisions — not the fastest solution that runs.
• Long-lived systems. Anything expected to run for five years has to be readable. The cost of comprehensibility falls either today or, with a surcharge, at the first staff change.
• Existing, grown codebases. Here the time saving reverses: the METR study of July 2025 measured 16 experienced developers across 246 tasks in projects they knew well, and found a 19 per cent longer completion time with AI tools — alongside a feeling of having been 20 per cent faster.
• Teams without a review culture. Without the person who reads the code and is allowed to reject it, the method runs away with itself. Three months later you have a system nobody can safely change.
• When there is no open question. If it is already clear what should be built, you do not need a prototype but a proper implementation. In that case the fast route is the expensive one.

And one last uncomfortable point: vibe coding does not replace product understanding. A model writes what you describe — it does not ask whether anyone needs it. That question stays yours, and we ask it deliberately before the first line of code. Projects we have delivered through conventional development are in our work, among them a web app for tax returns in Zurich.