Your app was vibe-coded in a weekend. Who fixes it when it breaks on a Tuesday?

Vibe coding has a name now, which means it's no longer a curiosity — it's a normal way software gets made. Describe what you want in plain English, let an AI tool generate the code, run it, see if it works, describe the next fix, repeat. Within an afternoon, a person with no engineering background has a working login flow, a payment page, a database. It is a genuinely remarkable capability, and it is exactly as good as it sounds for getting something running fast. The part nobody puts in the demo video is what happens afterward.

The word for what accumulates during a vibe-coding session is technical debt, and it's not a metaphor — it's closer to compound interest. Each prompt solves the immediate problem in front of it without necessarily fitting into a coherent structure, because the person driving usually can't evaluate whether it does. The AI tool isn't lying to you or cutting corners on purpose; it's answering the question you asked, which is rarely the same as the question a working system actually needs answered. Do this fifty times across a weekend and you have an app that runs — and a codebase nobody, including its own builder, could confidently explain a month later.

This matters more than it sounds like it should, because software isn't a thing you finish. It's a thing you maintain, indefinitely, for as long as the business depends on it. A login flow that works today needs a security patch next year. A payment integration needs updating when the payment provider changes its API, which they do, without asking permission. A database that handled a hundred users starts falling over at ten thousand, in ways that are specific to how it was actually structured, which is exactly the part nobody was tracking. None of this is optional maintenance. It's the actual job, and it starts the day after launch, not before it.

The genuinely dangerous version of this shows up around security, because a system can look completely fine — buttons work, pages load, forms submit — while quietly doing something it should never do. An AI-generated login flow that doesn't properly separate what one user can see from what another can, so account A can browse account B's private data by changing a number in the URL. A database query built by concatenating whatever a visitor typed directly into a command, which is the textbook setup for an attacker to run their own commands instead. An admin panel left reachable by anyone who finds the URL, because access control was never wired in — it just wasn't part of the plain-English description that generated it. Every one of these is invisible during a demo. Every one of these is exactly the kind of thing a person who understands what they're looking at would catch, and exactly the kind of thing a person who doesn't can't.

There's a specific moment worth watching for, and it comes earlier than people expect: the first bug that resists being prompted away. Something breaks, the fix that used to work stops working, and the person who built it starts asking the AI tool to explain its own code back to them — because they genuinely don't know what it did. This is not a failure of the tool. It's the predictable outcome of skipping the part of software development where a person forms a mental model of the system as they build it, so they have something to reason from when it misbehaves. Vibe coding, done end to end with no review, skips exactly that step, on the exact parts of the job where it matters most.

It would be dishonest to write this from a position of not using the tools — we do, daily. AI-assisted tooling is genuinely excellent at scaffolding, boilerplate, and the mechanical parts of a build that don't need judgement, and using it well is faster than not using it at all. The distinction that actually matters isn't AI versus no AI. It's whether a person who understands the resulting code reviewed it before it went anywhere near real users or real data. Fast generation plus real review is a legitimate, efficient way to build software. Fast generation with nobody checking is a bet that nothing important will ever go wrong, made by someone with no way to evaluate the odds.

If you're running something that was vibe-coded — your own weekend project, or a tool a contractor built for you this way — a few questions are worth answering honestly before it touches more of the business than it already does. Does anyone currently involved actually understand how the whole thing works, not just that it works? Has anything handling passwords, payments, or personal data been reviewed by someone who does this professionally, specifically for the standard security gaps above? Is there a real backup, and has restoring from it actually been tested, not just assumed to work? What happens the day the person who built it is unavailable and something breaks? A shaky answer to any of these is not a reason to panic — plenty of exactly this kind of system is quietly running fine. It's a reason to get a second, qualified look before it's carrying more weight than it can bear.

None of this is an argument against building fast. It's an argument for building fast and then actually checking the result before it becomes load-bearing — which, for anything real users or real money will touch, is not an optional extra step. It's the part of the job that was always the job.