When artifacts replace architecture, we substitute simulation for trusted judgment.

I recently reviewed several demonstrations of Google Stitch. It is genuinely impressive as a rapid interface generator. However, it still exhibits the same problems nearly all so-called “vibe coding” tools possess, including a visual homogeneity that makes every output feel like it came from the same template, limited control over refinement, and code that is not ready for production.

Despite these flaws, the market reaction was immediate. Figma’s stock dropped roughly 8% in a single day, then fell another 4% the next, totaling about 12% in two days. That response suggests the industry believes something meaningful is being automated.

The problem is that we are describing this transformation incorrectly.

The term “vibe coding” is simply wrong.

The phrase was coined by Andrej Karpathy in February 2025 to describe exploratory, low-stakes programming, what he called “throwaway weekend projects.” The word vibe signals that spirit well enough. The word coding does not. Coding carries expectations of precision, structure, and continuity. It implies the deliberate construction of systems that can be extended, maintained, and relied on over time. However, most outputs from these tools do not meet those conditions.

They are not meant to survive contact with reality. They are executable prototypes. If the activity needs a name, “vibe prototyping” is more honest. It keeps the energy of the original term while describing what is actually being produced.

Ethical Interface Design Nominated for a Webby Award – Public Voting Now Open

It’s also worth pointing out that the excitement surrounding these tools does not come from the design itself. It comes from the collapse of distance between description and interaction. An interface appears immediately, behavior responds instantly, and possibility becomes visible before structure exists. That is genuinely new. What is not new is the gap between something that looks finished and something that is.

I am old enough to remember building large-scale websites directly from static Photoshop files (some still standing today). There were no prototypes, no clickable mockups, no interactive previews to reassure anyone. There was a brief, a conversation, a few static comps, and then construction.

That process demanded something increasingly rare: a shared trust in architecture before anything was tangible. Nobody needed to see it move to believe it would work. The thinking and our design authority was the evidence.

Prototypes, when they eventually became standard practice, were genuinely valuable, particularly for user testing and surfacing assumptions early. But they were always meant to be a manifestation of thinking that had already happened, not a substitute for it. A prototype was supposed to be the output of a good architecture decision, not the thing that persuaded people one had been made.

That distinction has quietly collapsed. Teams now expect something interactive before they are willing to believe progress is happening. Visible behavior has replaced invisible structure as evidence that work is moving forward.

Designers have been rehearsing this misunderstanding in Figma for years. A prototype can look complete because it moves convincingly, but nothing inside Figma becomes infrastructure. Every UI element and interaction still has to be rebuilt with grown-up engineering practices before the system actually exists.

What is now being called “vibe coding” is not a break from that pattern. It is the same logic scaled up. We are using the appearance of progress to stand in for progress itself. Designers produce on demand, iterate live while stakeholders drive the decisions, and chase approval. Better tools. Same dancing monkey.

Calling this activity “coding” makes that drift harder to see. When something is described as code, it sounds deployable. It sounds like infrastructure rather than demonstration.

A VeraCode study from October 2025 found that while LLMs have become dramatically better at generating functional code over the past three years, the security of that code has not improved at the same rate.

Fast Company reported that senior software engineers were already describing a “vibe coding hangover,” citing development hell when inheriting AI-generated codebases. The word “coding” creates the impression that what appears on screen today can simply be shipped tomorrow. It cannot.

The persistence of “vibe coding” has less to do with accuracy than with identity. Coding signals authorship and control. Prototyping signals experimentation and incompleteness. In a field where status has long been tied to technical authority, the stronger word wins.

The technology industry has always renamed activities upward in this way. Templates became frameworks. Styling became UX strategy. Wireframes became experience architecture. “Vibe coding” fits neatly into that tradition because it preserves the mythology of programming even as the activity shifts toward generation and selection rather than construction. Collins Dictionary named “vibe coding” Word of the Year for 2025, which tells you something about how quickly a term can outgrow its original meaning.

Continuity is what makes software real. Vibe coding produces convincing fragments quickly, but fragments are not systems. The moment a prototype must evolve, integrate, or survive maintenance, someone still has to understand what exists underneath the surface. As Simon Willison put it: “vibe coding your way to a production codebase is clearly risky without understanding the underlying code.”

But renaming it does not solve the harder problem underneath.

Even if the industry adopted a more accurate term such as “vibe prototyping” tomorrow, the cultural shift would remain. Stakeholders would still expect something clickable before they believe thinking has occurred. Teams would still be pressured to produce visible behavior before invisible structure has been decided. The label changes—the dynamic it describes does not.

The real problem is not what we call the output. It is what we have allowed the output to replace. Architecture used to be trusted on the strength of reasoning. Now it has to be demonstrated before it is believed. That is not a tooling problem, it is an authority problem. And better tools will not fix it.

What might is a deliberate separation between the prototype and the decision. AI prototyping tools are genuinely powerful for making possibilities visible early, but visible should not mean decided.

The prototype can show what something might feel like without determining what it will be built on. Holding that line requires designers and engineers to name it explicitly, to say this is a surface, not a system, and the architectural conversation still has to happen.

That means producing thinking artifacts alongside interactive ones. Not wireframes for their own sake, but documented reasoning for what assumptions this prototype is testing, what it is not answering, and what decisions still need to be made before anything here becomes infrastructure. The prototype earns its place in the process when it is framed as a question, not an answer.

That compression, from description to working interface, is real and it is genuinely valuable. But the distance between a convincing fragment and a maintainable system has not collapsed at all. Vibe coding has made it easier to forget it exists. Closing that gap is not a job for better prompting, it is a job for the kind of trust that used to sustain a conversation from brief to construction, before anyone needed to see it move.

Don’t miss out! Join my email list and receive the latest content.

“Vibe coding” is accelerating the erosion of design authority was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.