Every app we scope in 2026 starts with some version of the same conversation: how much of this should we let an AI agent write, and how much needs a person sitting down and actually thinking through the logic by hand? Neither "vibe-code everything" nor "hard-code everything" is the right answer. Here's the framework we actually use.

Start with blast radius, not difficulty

The instinct is to ask "is this code hard to write?" That's the wrong first question. The better one is: if this is subtly wrong, what happens?

  • A wrong margin on a settings screen — low blast radius, fine to vibe-code and eyeball.
  • A wrong discount calculation at checkout — high blast radius, needs a human writing and testing the exact logic.
  • A slightly-off permission check on a shared document — very high blast radius, needs review by someone who understands the threat model, not just the happy path.

Difficulty and risk aren't the same axis. Plenty of "easy" code (an auth guard, a pricing rule) carries outsized risk if it's wrong.

A simple decision framework

We sort work into three buckets before a project starts:

1. Prompt it, review lightly

UI layout, copy tweaks, non-critical animations, internal admin screens. If it's wrong, someone notices in five minutes and it's a five-minute fix.

2. Prompt it, review hard

API integrations, data fetching logic, form validation, most business logic. An AI agent can draft this quickly, but a senior engineer reads every line before it merges — this is where most of our review time actually goes.

3. Hand-write it, no shortcuts

Authentication and authorization, payment and billing logic, anything touching regulated data, and core data models. These get designed on a whiteboard first, and written — or at minimum, rewritten line-by-line after generation — by an engineer who understands exactly why each line exists.

If you can't explain why a piece of logic is correct, you shouldn't ship it — whether an AI wrote it or you did.

The trap teams fall into

The failure mode we see most often isn't "used AI too much." It's treating bucket 2 and bucket 3 work like bucket 1 — reviewing an authentication flow the same way you'd glance at a padding change. AI-generated code reads confidently regardless of whether it's actually correct, which makes shallow review more dangerous with AI in the loop than without it, not less.

Where this actually saves time

Used this way, vibe coding doesn't replace engineering judgment — it removes the boring parts of typing so that judgment can go toward the buckets that matter. On a recent MVP build, roughly two-thirds of our screens were bucket 1 or 2, which is exactly where AI-assisted development earns its keep. The remaining third — auth, payments, the core data model — got the same rigor it always has.

For more on where the line sits between AI tooling and no-code platforms, see No-Code, Low-Code & Vibe Coding. For a broader look at what "vibe coding" even means as a term, start with Vibe Coding in 2026.