Vibe Coding Built Your App. Who Checked It?

A founder came to us after 3 years of steady demos and reassuring updates. The screens were beautiful. Real completion was closer to 20%.

We run a product team that ships with AI every single day, so this is not an argument against building with AI. It is an argument about the gap between what vibe coding shows you and what it delivers, and about the founders discovering that gap at the worst possible moments: at launch, under real users, or across the table from an investor's technical reviewer.

The uncomfortable shift is this: for the first time in software history, the demo tells you almost nothing about the product. Shipping something that looks finished has become nearly free. Shipping something that is finished costs what it always did. The distance between those two is the defining delivery risk of this era, and this article is about how to measure it on your own build.

What Vibe Coding Is, and What It Actually Ships

The term comes from Andrej Karpathy, who coined it in early 2025 to describe a real and enjoyable way of building: you describe what you want, the AI writes the code, you run it, and you steer by vibes. You barely read the code. When something breaks, you paste the error back in and accept whatever fix comes out.

For a weekend prototype, that is a superpower. It collapses the distance between an idea and a thing you can click. Used well, it is the fastest validation tool founders have ever had, and we would tell any founder to use it for exactly that.

Karpathy also named the other side of this line. A year after the original post he wrote that his preferred term for the professional workflow is agentic engineering: "you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight". The difference is the builder. Vibe coding is nontechnical founders and junior developers accepting output they cannot evaluate. Agentic engineering is experienced engineers directing AI agents under specs, reviews, and tests, multiplying their output while keeping the understanding in human hands. Same tools, very different products.

Vibe coding and agentic engineering, side by side. Source: Karpathy on X.

Vibe coding ships something every time. That is exactly the problem. What it ships, reliably, is the visible half of a product: screens that render, flows that survive a demo, features that exist. What it does not ship, unless somebody deliberately makes it, is the invisible half, and the invisible half is where products actually live:

• Error states and edge cases: what happens when the input is wrong, the network drops, or 2 users touch the same record.
• A data model that survives growth: the difference between a schema someone designed and a schema that accreted, one prompt at a time.
• Authentication that holds: login that works in a demo and login that holds while someone is actively poking at it are different engineering problems.
• The unhappy payment paths: refunds, failures, cancellations, disputes. The happy path is a form; the rest is the product.
• Security posture: secrets out of the code, environments separated, access scoped, an audit trail. We wrote the full founder-level checklist in Security Led Product Development? Why Not.
• Consistency: the property that lets the next developer, or the next AI session, touch the system without breaking it.

A prototype is allowed to skip all of that. A product is not. The danger starts when a prototype puts on a product's clothing: taking real signups, holding real data, and carrying a real company on its back.

Why Vibe Coding Fools Smart Founders

Nontechnical founders have always had one structural problem: no independent way to verify what the build team reports. So founders learned to read proxies. Watch the demo. Track the velocity. Gauge the confidence in the room. Those were never great signals, but they were correlated with reality: a team showing you working screens had usually done real work to get there.

AI broke the correlation. Looking done is what AI does best.

• The demo inflated: a polished frontend used to be evidence of months of engineering. Now it is evidence of a good prompt. The demo still measures something, it just no longer measures depth.
• Velocity inflated: commit counts and shipped screens used to track effort. Now the codebase can grow faster than anyone reads it, and growth is precisely what you would expect from an ungoverned pile.
• Confidence inflated: the builder is not lying to you. They watched the AI produce something that runs, and they believe in it. Belief built on output nobody deeply understands is the most sincere kind of wrong.

This is why the smartest founders get fooled worst, and why we would push back on anyone feeling stupid about it. They did the diligence they knew how to do: demos, velocity, updates, references. Every signal came back green. Vibe coding is, among other things, a machine for producing green signals.

The asymmetry gets one notch worse with a technical team in the loop, because "we use AI responsibly" is now part of every agency's pitch. The claim is unverifiable from the founder's chair. The only signals that still work are the ones this article is about: governance you can inspect and understanding you can test.

Prototype Hell: Where the Vibe Coded App Ends Up

Here is what an ungoverned AI codebase looks like from the inside, pattern by pattern. We are not describing a hypothetical; this is what audits of AI-built products keep finding.

5 versions of the same button: each screen generated in a separate session, each session inventing the button fresh, each styled slightly differently. Nobody maintained a component system, so there is nothing to reuse, only things to regenerate. When the design changes, there are 5 buttons to fix, and next month there will be 6.

Components that almost match: the same card, form, or table rebuilt per screen with small mutations. The AI had no memory of last week's build and nobody made it check. Users feel this before anyone can name it: the product feels slightly off everywhere, because it is.

An architecture nobody decided: ask which parts of the system everything else depends on and nobody can answer, because no one chose the structure. It accreted, prompt by prompt. There is no load-bearing wall diagram because there are no load-bearing walls, only rooms leaning on each other.

Duplicated logic with divergent behavior: the same business rule implemented 3 times in 3 places, each version drifting independently. The bug report says "it works sometimes". All 3 implementations are working exactly as written; they are just not the same rule anymore.

Fixes that multiply: with no tests and no consistency, every change is a dice roll. Bugs you already paid to fix come back. New features break old ones. The team slows down every week while the codebase grows every day, which is the exact inversion of what software velocity should look like.

Dead code nobody dares remove: abandoned attempts, half-migrations, and orphaned files the AI generated along the way. Nobody knows what is safe to delete, so nothing gets deleted, and the pile compounds.

AI multiplies the skill of whoever is holding it. We call the underlying law the AI Gap. A senior engineer with AI is 1 times 10, a genuine superpower. A beginner with AI is 0 times 10, and 0 times 10 is still 0, except now the 0 is 80,000 lines long.

That is Prototype Hell. Not a broken app. A pile of prototypes cosplaying as one.

Where the Vibe Coding Bill Comes Due

The pile does not announce itself. It surfaces at 3 predictable moments, and the price climbs at each one.

At launch: real users are the first adversarial workload most vibe coded apps ever meet. They paste emoji into forms, lose connectivity mid-checkout, and hit the back button at the exact wrong moment. Auth falls over, half the "finished" screens turn out to have no backend behind them, and the support inbox becomes the real bug tracker. The product did not break at launch; launch is simply where the missing half became visible.

Under real load: growth turns quirks into outages. The data model that accreted starts contradicting itself, the duplicated logic diverges under pressure, and the fix-one-break-two loop eats the roadmap. Teams in this stage ship nothing new for a quarter while they relitigate everything already shipped. The burn continues; the progress stops.

In due diligence: the most expensive version. An investor's technical reviewer opens the repo with no incentive to be polite, and everything invisible from the founder's chair becomes a line item in someone else's report. Findings at this stage do not just cost engineering time; they reprice the round, delay the close, or end the conversation. The problem was always there. The timing is what makes it catastrophic. And do not count on generated paperwork to paper over it: we have watched AI-templated documents get discredited the moment a reviewer recognized the texture, and investors’ technical reviewers know that texture well.

The pattern across all 3: the cost of the gap is a function of when you find it. Which is the entire argument for finding it deliberately, early, on your own schedule, instead of accidentally, late, on someone else's.

The Vibe Coding Test Any Founder Can Run

You do not need to read code to detect any of this. You need one meeting and one question.

Ask whoever built the system to walk you through the most important part of it, live, explaining rather than presenting. What does this piece do? What depends on it? What happens when it fails? Then change one variable and make them re-derive the answer: what if the user count grows 5 times, what if this integration goes down, what if we swap this payment provider?

A builder who understands the system answers easily, because the understanding exists independently of the artifact. A builder who vibe coded it cannot, because the artifact is all there is. We have watched people fail to explain systems they submitted a week earlier, with the correct answer written in their own deliverable a page below where they were stuck. The lesson generalizes: the code stopped being evidence of understanding the day AI started writing it. The document stopped being evidence too. The walkthrough is what survives, because fluent output can be generated and understanding still cannot.

Two refinements make the test sharper:

Pick the load-bearing component: the team will happily walk you through the AI chat feature. Ask instead about the thing everything else depends on: the auth flow, the billing logic, the data pipeline. That is where vibe coding hides.

Watch for the deflection to the tool: "the AI handled that part" is an honest answer and a damning one. Somebody has to own every part. If a part is owned by nobody, you have found the gap.

And run the same logic on your product's automated actions. AI agents wired into real systems inherit every permission and none of the caution. We watched a bot with delete rights wipe around 100 users' messages in a community it was meant to manage, because nothing irreversible had a guardrail in front of it. If your product has AI actions that can delete, send, charge, or ban, ask the second question: what stands between that action and the wrong target? "It has not happened yet" is not a guardrail. The professional version of this risk, whole teams wiring agents into production systems, gets the full treatment in our agentic engineering governance guide.

Vibe Coding With Governance Is a Different Sport

The honest version of this argument has to include the other side, because we build with AI daily, across production systems that move real money, and the work is genuinely better and faster for it. AI is not the risk. Ungoverned AI is the risk. The difference is a handful of practices, all of them inspectable by a nontechnical founder:

The spec comes first: every piece of work starts as a written brief with acceptance criteria, and the AI implements against it. The spec is the agreement about what done looks like. Without one, AI output is a guess with good posture, and "done" means "it ran once".

A human signs off on everything that ships: AI output gets reviewed the way any teammate's work gets reviewed: read carefully, challenged, and approved by a person who then owns the result. "The AI wrote it" is never an excuse, because accountability never transfers to the tool.

The design system is law: components come from one source of truth, so the 60th screen uses the same button as the first. This is the direct antidote to the 5-button problem, and it is checkable: ask to see the design system, then ask when it was last updated.

Documentation lives: the product docs, the architecture notes, and the conventions get revised as the product moves, because AI-assisted systems change too fast for write-once documentation. A living doc trail is also what makes the walkthrough test passable by more than one person, which is how you retire key person risk at the same time.

Anything irreversible gets a gate: confirm steps, scoped permissions, dry runs, and an audit trail on any action that can lose someone something. Features that can only be wrong are one class of work; features that can lose someone something are another, and they get engineered accordingly.

The pipeline pauses on purpose: our AI delivery runs as gated procedures, never fire-and-forget automation. The pauses are where a human steers, where the client approves, and where AI-isms get caught before they compound. Autonomy optimizes for done fast; client delivery optimizes for right, owned, and approved.

None of this slows AI down in any way that matters. It is the difference between compounding an asset and compounding a liability at the same speed. So skip asking whether your team uses AI, because everyone does. Ask to see the governance, and treat a shrug as a complete answer.

How to Check the App Vibe Coding Built You

Seven checks, no code knowledge required. Run them in an afternoon.

1. Run the walkthrough test: the load-bearing component, explained live, with one variable changed. The highest-signal 30 minutes available to a nontechnical founder.

2. Ask for the spec trail: "show me the brief this feature was built against." If features have no written intent, the AI was steering and nobody was navigating.

3. Ask what gets reviewed: who approves code before it reaches production, and where is the record? "We move fast" translates to "nobody".

4. Ask to see the design system: one source of truth for components, actually referenced by the code, updated recently. A screenshot of Figma from 6 months ago does not count.

5. Check your keys: do you control the repos, hosting, domains, and every third-party account, or does the builder? AI made rebuilds cheap and founders casual about ownership, and ownership is its own risk with its own article: Own Your Infrastructure.

6. Watch a real user, not a demo: hand the product to someone outside the team with a task and no help. The distance between the demo and that session is the distance between the story and your product.

7. Count the bugs that came back: ask how many of last quarter's fixed bugs reopened. Bugs that return are the signature of the pile: fixes applied to symptoms in a system nobody fully understands.

If all 7 come back clean, genuinely clean, you are ahead of most funded teams building right now, and you should keep shipping with confidence. If 2 or 3 wobble, you do not have to guess how deep it goes. An independent Product Team Audit exists for exactly this reading: AI risk is the first of 6 risks we sweep, we test what is actually behind the screens, and every finding comes back ranked by severity, claimed versus actual, in a report you own. The point is to replace a story with a reading, while the fix is still yours to schedule.

Use AI Aggressively, Govern It Obsessively

Use AI aggressively. Govern it obsessively. That is the whole position, and we hold both halves with equal weight because we live both halves: AI acceleration is in every engagement we run, and so is the governance that keeps it an asset. The teams treating those as opposites, the AI maximalists shipping ungoverned piles and the AI skeptics shipping slowly on principle, are both going to lose to the teams that figured out the two belong together.

For founders, the practical version is simple. The build got cheap, so the value moved to what surrounds the build: the verification, the governance, the judgment about what is actually done. That is where your attention belongs now, and it is a place a nontechnical founder can genuinely operate, because every check in this article runs on questions, not code.

The Demo Was Never the Product

Vibe coding is not going away, and it should not. It is the cheapest idea-validation machine ever built, and in governed hands it is a genuine multiplier on good teams. The teams that win with it treat AI like the most productive junior engineer ever hired: enormously capable, entirely unaccountable, and never allowed to ship unreviewed.

The teams that lose with it are the ones that mistook the demo for the product, because the demo was the one thing vibe coding guaranteed. Your app looking done tells you what the AI is good at. Whether it is done is a different question, and it deserves a real answer while the answer is still cheap.