/ Insights
By Daniel
06 May 2026
Vibe coding is useful because it lowers the cost of starting. You describe what you want, iterate with an AI tool, and get to a working interface in days instead of months.
That speed is not the problem. The problem is what gets skipped while the product is taking shape.
Technical debt in a vibe coded app does not look like bad code at first. It looks like momentum. The app works, the demo is impressive, and each new prompt seems to add another feature. Then a real user arrives, a customer asks for a change, or the launch date gets close, and the product starts fighting back. Every change breaks something that used to work, and nobody can say why.
AI tools optimize for visible behavior, because visible behavior is what you prompt for:
Production asks questions no demo ever surfaces:
When those questions were never part of the build, the answers default to no. That gap is the debt, and it stays invisible exactly as long as nothing real depends on the app.
We review codebases like this as part of our AI prototype to production work, and the same five problems keep showing up.
Duplicated logic. AI tools regenerate instead of reuse, because each prompt starts from the file in front of it, not from your architecture. The classic shape: the same permission check pasted into four route handlers, and the fourth one is subtly different. The app has features but no stable internal model, so every edit is a chance to fix three copies and miss the fourth.
Blurry data boundaries. User data, workspace data, admin access, test records, and third-party integration state get handled by whatever pattern the tool reached for that day. It works in the demo because the demo has one user. It fails the first time customer two can see customer one's records.
Implied security. Authentication exists because the template shipped with it. Authorization exists wherever the model happened to add a check. Those are different things: the app knows who you are, but not consistently what you are allowed to touch. Generated API routes tend to trust their inputs because nothing in the prompt said not to. This is the highest-stakes pattern on the list, and the one our AI app security review exists to catch before launch.
No safe change path. Tests are thin or missing, deploys are manual, error logs are incomplete. Nobody is sure which parts of the app are safe to touch, so people stop touching them. That is the debt collecting interest: the product still runs, but it has quietly stopped being changeable.
Unreviewed AI features. If the app itself calls LLMs, there is a second layer: prompt injection, sensitive data flowing into prompts, tools with more access than they need, and per-user model costs nobody has measured. Cost deserves real numbers early. We wrote up what unmeasured model spend does to a business, and what fixing it looks like, in Cheap Model Finds, Expensive Model Thinks: one pipeline went from $6.45 to $1.60 per session once we stopped sending everything to the most expensive model.
AI makes adding one more feature feel cheap. That changes founder behavior.
A user asks for something. A competitor ships something. The tool can probably generate it. So the product grows.
The hidden cost is not development time. It is product clarity. Every feature adds states, permissions, support cases, and maintenance burden, and in a codebase with the five patterns above, every feature multiplies the debt. When the app is still looking for its market, shipping more features can become a way of avoiding the harder question: which users are we actually winning?
That question is a scoping problem, not a refactoring problem. If the honest answer is "we do not know yet," the fix is a tighter MVP scope, not more code.
A fragile vibe coded app does not automatically need to be thrown away. Often the right move is targeted hardening:
Other times a rebuild is cheaper than preserving a confused foundation, especially if the product direction is clearer now than when the prototype was built. The point of a senior review is to make that call with evidence instead of frustration: what stays, what gets refactored, what gets rebuilt, and in what order.
Before putting customers on the system, review the parts that create the most exposure:
If the app already has users, their bug reports are the best map of where the debt actually is. Start there, not with the code you happen to dislike.
We help teams move from AI-built momentum to production reality: AI prototype to production when the app needs hardening, an AI app security review when the biggest risk is exposure, and a rebuild-versus-refactor call when nobody is sure which one they need.
The first step: Book a readiness audit. Bring the repo, known bugs, launch timeline, and user feedback. We will separate urgent debt from optional polish and tell you plainly whether the next phase is hardening, refactoring, or rebuilding.
Frontier LLMs are spectacular, and spectacularly expensive at scale. We cut per-session AI processing cost from $6.45 to $1.60 by training small task-specific models on our own data, and the deeper win was teaching cheap models to find exactly what the expensive models need.
Long context vs RAG is a false choice. Here's the three-tier memory architecture I expect to replace both within three years, and what to build (and skip) now.
A Lovable app can reach production, but clickable is not ready. What we check first: Supabase RLS policies, auth, secrets, the release path, and who owns the code.
