🌊 The vibe coding mirage - demo, product, or illusion (there is no fourth option)

on June 18, 2026

Introduction: the collapse of the barrier

The cost of generating a line of code has reached a near-zero marginal threshold. We have entered an era where the barrier to entry for software production has effectively collapsed. This is not a gradual shift; it is a structural failure of the traditional gatekeeping mechanisms of engineering. Historically, the difficulty of syntax and the manual labor of implementation acted as a filter. Today, that filter is gone.

Software has not become easy. It has become easy to simulate.

The current landscape is defined by a dangerous asymmetry: AI dramatically reduces the cost of code generation, but it does not—and cannot—reduce the cost of understanding complex software systems at the same rate. We are witnessing the industrialization of the "demo," a phenomenon where the visual artifacts of software are produced at a velocity that far outstrips the architectural integrity required to sustain them.

This creates a "Vibe Coding Mirage." To the untrained eye, a working URL is indistinguishable from a production system. To the market, a rapidly shipped feature set looks like a competitive advantage. In reality, we are accumulating systemic risk at an exponential pace. If nobody understands your runtime, you do not have a product. You have an illusion that compiles.

Archetype #1 — The vibe coder: the architect of the surface

The Vibe Coder is the primary beneficiary of the collapse of the barrier to entry. This archetype is often non-technical or semi-technical, leveraging UI-based "vibe coding" tools like Replit or Lovable to manifest software through sheer intent. For the Vibe Coder, software is an aesthetic exercise. If the interface responds and the URL resolves, the engineering is considered "done."

The aesthetics of implementation

The Vibe Coder optimizes for visual output and speed. They can "deploy" a functional-looking application in forty-eight hours, sharing it internally to generate immediate stakeholder excitement. However, this speed is achieved by ignoring the fundamental pillars of software engineering: backends, persistent databases, and security protocols.

The Vibe Coder operates entirely within the "happy path." Their code is a collection of fragments that satisfy the immediate requirements of a demo but possess no internal logic for handling the entropy of a live environment. In the Vibe Coder's world, a "working URL" is the final goal, ignoring the fact that a URL is merely a pointer to a potentially hollow core.

The mirage of completion

The danger of the Vibe Coder is not their lack of skill, but their confusion of appearance with engineering. They produce "Darling" products—tools that the community falls in love with because they solve a surface-level pain point—without realizing that the "revenue comes after the love," and only if the product actually works. When a Vibe Coder's demo is mistaken for a product, it sets a lethal precedent for the organization, creating the expectation that "real" engineering can be bypassed.

Archetype #2 — The prompt manager: the orchestrator of anonymous code

The Prompt Manager is often a seasoned developer who has transitioned from a writer of code to an orchestrator of agents. They use LLMs to handle security audits, test frameworks, and boilerplate generation at a pace that feels superhuman. They ship fast. They meet deadlines. They are the heroes of the sprint.

The erosion of architectural intent

The Prompt Manager's failure is subtle: the loss of architectural ownership. While they are moving "super fast," they are doing so by sacrificing the "think time" required to hone in on exactly what is being built. Architecture is not a collection of functional snippets; it is a cohesive strategy for managing state, flow, and failure.

When code is prompted rather than designed, the underlying architecture begins to erode. The Prompt Manager becomes a passenger in their own codebase, unable to account for the subtle interactions between generated modules. They are managing a system whose internal invariants—the rules that must never be broken—are unknown even to them.

The illusion of productivity

The Prompt Manager confuses visible progress with engineering progress. They believe that because they have "agents that handle security," they are secure. This is a fallacy. Automated security audits are a baseline, not a guarantee. Without deep comprehension of the runtime, the Prompt Manager is building a "Flambeur" organization: burning capital and velocity to dominate mindshare while the technical foundation rots beneath them. They are shipping code they can no longer explain.

Archetype #3 — The system engineer: the guardian of the runtime

The System Engineer is the only archetype that recognizes the mirage for what it is. They use AI—they may even use it more effectively than the others—but they maintain absolute ownership of the system's core. To the System Engineer, the code is the least important part of the software. The most important parts are the invariants, the failure modes, and the observability.

Ownership of complexity

The System Engineer knows that the hard part of engineering was never making something appear on a screen. The hard part is ensuring it keeps working when data needs to be stored correctly, when edge cases appear, and when the system must be maintained six months later.

They treat AI as a high-speed intern, not a lead architect. They subject every AI-generated line to rigorous validation against the system's invariants. They focus on the runtime—how the code actually behaves under load, in a distributed environment, or during a partial network failure.

The engineering manifesto

For the System Engineer, a prompt is not architecture. Engineering is the discipline of turning an AI-generated illusion into something real. They prioritize:

• Invariants: Defining the constant truths of the system state
• Observability: Building systems that explain their own internal state to the operators
• Failure modes: Anticipating how the system will break and designing for graceful degradation
• Scalability: Understanding the theoretical limits of the chosen data structures and concurrency models

The System Engineer is the one who prevents the product from falling into the "Valley of Death". They understand that while AI can generate the "what," the human must still define and defend the "how" and the "why."

Why managers get fooled: the psychology of the demo

The most dangerous moment in a product's lifecycle is the first successful demo. Non-technical stakeholders see a functional UI on a deployed URL and immediately ask: “Why can't we just productize this?”.

The visibility trap

Managers and VCs are biologically wired to respond to visible progress. In their eyes, if the frontend is 90% done, the project is 90% done. They do not see the absent backend, the unencrypted database, or the race conditions in the concurrency model.

The Vibe Coding Mirage exploits this cognitive bias. It presents the "visible" as the "valuable." This pressure forces engineering teams to "go faster," which only accelerates the accumulation of unmanaged complexity.

The darling vs. the flambeur

In the current market, managers are chasing the "Darling" status—a product that the community falls in love with overnight. They use demos to raise capital as "Flambeurs," burning through cash to buy distribution. But without the System Engineer's rigor, these companies are "Morts" (Dead) within 14 months. The demo got them the meeting; the lack of a product killed the company.

The hidden cost of complexity: the invisible debt

AI is a complexity multiplier. By reducing the friction of code production, it encourages the creation of systems that are larger and more intricate than any single human—or even a team—can fully comprehend.

Architecture erosion and technical debt

When we use agents to "move super fast," we often bypass the design phase. We skip the requirements and design documents that both the human and the AI need to truly understand the goal. This leads to architecture erosion, where the system's structure becomes a patchwork of local optimizations that are globally incoherent.

The concurrency and scalability wall

AI is notoriously bad at reasoning about concurrency and failure modes in distributed systems. It can generate an event loop, but it cannot predict how that loop will behave under a thundering herd problem. It can write a SQL query, but it doesn't understand the scalability implications of that query on a multi-terabyte dataset.

As the codebase grows, the "cognitive load" of system comprehension increases exponentially. The bottleneck has shifted: it is no longer about how many lines of code you can write, but how much of the existing system you can hold in your head at once.

The future of engineering: comprehension as the core value

The future of software engineering value is shifting away from syntax and toward high-level system orchestration and runtime models.

The shift to orchestration

In a world where code is a commodity, the engineer's value lies in their ability to manage distributed systems, event loops, and async systems. The new "hard part" is not writing the function, but ensuring that the function's side effects are observable and reversible.

The observability mandate

We are moving toward a future where we must manage software we did not write. This makes observability the most critical engineering discipline. If we cannot understand the code by reading it, we must understand it by watching it run. This requires a profound understanding of telemetry, tracing, and log aggregation.

The engineers who thrive will be those who can define the invariants and then use AI to build the machinery that enforces them. They will be the architects of systems that are robust not because every line of code is perfect, but because the system's architecture is designed to survive imperfection.

References & bibliography

Primary sources

Karpathy, A. (2025, February 2). Post on X introducing "vibe coding"

MIT Technology Review. (2025, April 16). What is vibe coding, exactly?

Bencoding. (2026, April 20). Demo-grade vs ship-grade: the most expensive confusion in AI

Uphack. (n.d.). The illusion of building

He, Y., et al. (2026). Debt behind the AI boom: a large-scale empirical study of AI-generated code in the wild. arXiv.

Winters, T., Manshreck, T., & Wright, H. (2020). Software engineering at Google: lessons learned from programming over time (Ch. 10, Design docs). O'Reilly. https://abseil.io/resources/swe-book/html/ch10.html

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: the science of lean software and DevOps. IT Revolution Press.

Stack Overflow. (2025, July 31). Do AI coding tools help with imposter syndrome or make it worse?

CB Insights. (2025). Why startups fail: top reasons

Myriad Consulting. (2022). Entreprises : comment résister aux crises grâce à la frugalité ?

Scientific & technical literature

Brooks, F. P. (1975). The mythical man-month. Addison-Wesley.

Dijkstra, E. W. (1989). On the cruelty of really teaching computer science. Communications of the ACM, 32(12). https://doi.org/10.1145/76380.76381

Vogels, W. (2008). Eventually consistent. ACM Queue, 6(6). https://doi.org/10.1145/1466443.1466448

DORA. (2023). State of DevOps report. Google Cloud.

Amdahl, G. M. (1967). Validity of the single processor approach to achieving large scale computing capabilities. AFIPS Conference Proceedings. https://doi.org/10.1145/1465482.1465560

Final conclusion

The Vibe Coding Mirage is a siren song for the modern age. It promises the rewards of engineering without the labor of comprehension. But software is not a visual medium; it is a structural one.

We must return to the fundamentals: runtime, observability, and invariants. If we continue to mistake the demo for the product, we are not building a digital future; we are building a digital graveyard.

“If your coding agents disappeared tomorrow, how much of your codebase would you still truly understand?”

Brutal diagnostic

• Safe: You can explain every state transition in your system and can recreate the architecture's mental model from scratch in a whiteboarding session
• Dangerous: You rely on the AI to explain what "your" code does when a bug appears. You have no design documents or recorded invariants
• Critical dependency: You cannot deploy, debug, or scale your system without an active LLM window open. You are a passenger in a vehicle with no steering wheel