I use coding agents every day. They write all my code now.

I do not think vibe-coded SaaS apps are automatically doomed. The problem is who is driving the agent.

The cleanup usually starts across the system

The code can be bad even when each file looks plausible. The UI works, the demo looks real, and there are routes, components, migrations, and auth screens.

Then you look across the app:

  • The database model does not match the product rules.
  • Auth exists, but ownership checks are missing in the places that matter.
  • Background jobs, retries, rate limits, and idempotency were never designed.
  • The architecture is accidental instead of chosen.
  • The app has five partial patterns instead of one consistent one.

AI is good at continuing a pattern. It is much worse when there is no pattern yet, or when the person driving it cannot tell whether the pattern is any good.

How I keep agents from making that mess

My workflow is built around avoiding that. For larger features, I write a spec first: data model, API behavior, edge cases, and what not to change. I wrote about this in Two Ways to Direct Coding Agents. For new projects, I often point the agent at one of my existing projects and tell it to build the same way, except for the parts I want changed.

Every repo I work on has an AGENTS.md file: commands, architecture, conventions, deployment rules, and mistakes the agent has made before.

I also have a simple skill that uses a second agent to review the first agent’s work. One writes the change, another reviews the dirty diff, then the first one fixes what the reviewer caught.

I would audit before refactoring

I would not automatically throw away every AI-built app. Plenty are fine. Others need hardening. A few should be rebuilt because the foundation is wrong.

The first pass I would do on a vibe-coded SaaS app is not a refactor. It is an audit:

  • Can two users access each other’s data?
  • Are permissions enforced on the backend, including server-owned fields like role, plan, or owner IDs?
  • Does the database model match the business?
  • Is the database reachable only by the app/backend?
  • Are payment, webhook, subscription, and rate-limit states explicit?
  • Are secrets kept out of frontend code and public env vars?
  • Can the app be deployed from a clean checkout?
  • Is the architecture clear enough that the next feature has an obvious place to go?
  • Is there one pattern for routes, errors, jobs, and logging?

When I use an agent for this, I avoid broad prompts like “is this app secure?” I ask it to check all API routes for authentication, authorization, ownership, server-owned fields, paid feature limits, rate limits, and secrets crossing into the frontend.

After that, the decision is clearer: patch, harden, or rebuild.