Ship Fast With AI, But Know the Line Before You Stop Reading the Code

One sentence from Andrej Karpathy did more to confuse this topic than clarify it: “forget that the code even exists.” People took that and turned vibe coding into “any app touched by Cursor, Claude, or Copilot,” which is too broad to be useful.

If you run a solo SaaS or tiny product team, the line that matters is simpler: you’re vibe coding when you stop reading the code and ship based on outside behavior alone. That can be a great way to build a prototype fast. It’s also how you end up owning code you can’t debug next month.

What is vibe coding?

Vibe coding is prompting an AI to build software, testing what comes out, and asking for changes without really reviewing the code itself. That narrower definition comes straight from Martin Fowler, who describes it as building an application by prompting an LLM, trying it out, prompting for changes, “but without looking at any of the code that the LLM generates.”

That’s much tighter than the loose internet version. The broad version says vibe coding is any AI-assisted development. But Google Cloud splits the practice in two: “pure” vibe coding, where you trust the model and move fast, and “responsible AI-assisted development,” where you still review, test, and own the code. That distinction matters.

MIT Technology Review points back to Karpathy’s original post from February 2025, where he said he would “Accept All” and didn’t read diffs anymore. That’s the signal. Not whether Cursor wrote 80% of the file. Not whether Claude helped you debug. The real question is whether you still inspect what’s being shipped.

If you read the code, understand the changes, and take responsibility for them, you’re doing AI-assisted development. If you mostly steer by prompts and judge the app from the outside, you’re vibe coding.

The useful boundary is whether you still read the code before shipping

The most useful test for a working operator is not “did AI write this?” It’s “did I review this enough to trust it when it breaks?”

That’s why Fowler’s framing is better than the social-media version. In his write-up, the key point is “forget that the code even exists.” Wikipedia lands in roughly the same place, describing vibe coding as accepting AI-generated code without thorough review and relying on results and follow-up prompts instead.

That boundary gives you a clean decision rule:

• If you read the code, it’s AI-assisted coding
• If you don’t read the code, it’s vibe coding
• If you can’t explain how a risky path works, you shouldn’t ship it

That sounds obvious, but people blur it because the tools feel the same. Cursor, Claude, Copilot, Gemini, Bolt, Lovable, and similar tools can support both modes. Cloudflare describes vibe coding as heavily relying on an LLM to generate code, but the same tools can also act like a fast junior pair programmer if you still inspect the output.

So don’t classify by tool. Classify by behavior. The minute you stop reading the diffs, stop tracing the logic, and stop checking what the code actually does, you crossed from assisted coding into vibe coding.

Black-box testing only tells you whether the app seems to work

A working demo can hide a lot of bad code. If you only click around the UI and see the happy path succeed, you still haven’t checked the parts that usually hurt later.

Fowler says the common problems in vibe-coded software are maintainability, correctness, and security, and that it’s best used for disposable software with a limited audience in his post. Cloudflare makes the same tradeoff clear: vibe coding helps you spin up applications and features quickly, but speed is not the same thing as confidence.

Black-box testing is fine for one question: does the thing appear to work? It is weak at the questions you’ll care about once real users show up:

• Does auth fail closed, or can the wrong user slip through?
• Do permission checks happen on the server, or only in the UI?
• Will billing logic double-charge on retries?
• What happens on edge cases, partial writes, and timeouts?
• Did the model duplicate logic in three places that will drift later?
• Are errors handled, logged, and recoverable?

Google Cloud says the responsible version of this workflow still requires you to review, test, and understand the generated code. That’s the key point. Outside-in testing can tell you whether the surface looks fine. It can’t tell you whether the foundation is rotten.

Tiny teams pay the maintenance bill faster than they expect

When AI-generated code breaks, the first job is often not fixing the bug. It’s figuring out what the model built in the first place.

Karpathy said in the quote reproduced by Martin Fowler and MIT Technology Review that the code can grow beyond his “usual comprehension” and that sometimes he works around bugs or asks for random changes until they go away. That’s funny when it’s a weekend toy. It’s not funny when it’s the thing handling customer data on a Tuesday morning.

For a solo founder or 3-person SaaS, maintenance pain shows up fast because you don’t have a spare platform team to absorb it. A simple bug can turn into a three-step mess:

1. Reconstruct what the code is trying to do
2. Trace where the model duplicated or tangled the logic
3. Fix the issue without breaking two hidden side effects

That reverse-engineering tax is the real cost. Cloudflare says vibe coding’s goal is to spin up working applications quickly. True. But quick creation and long-term ownership are different jobs.

Google Cloud says pure vibe coding is best suited to rapid ideation and “throwaway weekend projects.” That should tell you how to use it. If you expect to extend the app next month, hand it to a contractor, or wake up at 2 a.m. to debug it, unread code stops being cheap.

Vibe coding is great for prototypes, admin tools, and one-off scripts

Disposable software is the sweet spot. Fowler says that directly in his definition: vibe coding is best used for software written for a limited audience and a short life.

That maps well to real operator work. If the code only needs to do a job once or support a tiny internal workflow, speed can matter more than polish. Google Cloud calls this “rapid ideation.” Cloudflare frames the upside as quickly spinning up working apps and features.

Good vibe-coding candidates:

• a one-off data cleanup or migration script
• an internal admin panel for your own team
• a prototype to test demand before you invest
• a throwaway workflow tool glued to APIs
• a rough MVP you expect to replace after learning from users

The reason these are safer is simple. Failure costs less. If the script is ugly but saves you four hours, great. If the internal dashboard needs a rewrite in two weeks, who cares. If the MVP proves people don’t want the feature, even better.

Vibe coding is useful when the main question is “can we get this working fast enough to learn something?” It is much less useful when the question is “can we trust this to keep working under real use?” Those are different jobs, and you shouldn’t pretend one tool choice solves both.

Read every line for auth, billing, deletion, and customer-facing flows

High-risk code needs human review, even if AI wrote the first draft in seconds. Google Cloud says the professional version of this workflow means the user takes full ownership of the final product. Ownership without review is fake.

If a path can hurt a customer, cost you money, or create a security mess, read it. Then test it. Then read it again. Martin Fowler flags security, correctness, and maintainability as the main failure points. That gives you a clear review list.

Code you should not ship unread:

• authentication and password resets
• permissions and role checks
• billing, invoices, credits, and webhooks
• data export and data deletion
• file uploads and anything public-facing
• email sending, notifications, and retry logic
• database migrations that touch production data

Cloudflare says vibe coding relies on high-level directions while the LLM fills in the precise implementation. That’s exactly why risky paths need scrutiny. The details are where the damage lives.

For a tiny SaaS, a good rule is brutal but useful: if support will hear about it, if legal would care, or if you’ll lose sleep when it fails, don’t ship it unread. Use AI to draft it, sure. But then act like it’s yours, because it is.

Cloudflare and Google both treat vibe coding as fast, but not free of risk

The cheerier “ship in hours” posts usually stop at speed. The vendor docs don’t. They keep the upside, but they also draw limits around it.

Cloudflare says vibe coding is an approach that heavily relies on an LLM for code generation and is meant to more quickly spin up working applications and features. That’s the upside in plain English. But the same framing tells you what you’re trading away: precision and direct control over the implementation.

Google Cloud is even more explicit. It separates “pure” vibe coding from “responsible AI-assisted development.” Pure vibe coding trusts the output and fits exploratory work. Responsible use means you review, test, understand, and own the code.

That split matches what operators already know from experience. Speed is only free on code you can throw away. On code you need to maintain, every unread line turns into future work. Sometimes that future work is a bug. Sometimes it’s a security hole. Sometimes it’s just the slow misery of touching code nobody understands.

So yes, use the models. Use them aggressively. Just don’t flatten every AI coding workflow into one bucket. The real line is not whether AI wrote the code. The line is whether you still read it before you ship.

A simple rule for solo SaaS teams: vibe the spike, review the product

You don’t need a philosophy here. You need a rule you can use on a busy Wednesday.

Martin Fowler gives the cleanest definition, and Google Cloud gives the cleanest operating split. Put them together and you get a practical workflow:

• Vibe code anything disposable
• AI-draft anything repetitive
• Review anything customer-facing
• Inspect every path tied to money, access, or data
• Refuse to ship code you can’t explain

That rule lets you keep the speed without lying to yourself about the risk. You can absolutely build an MVP, an internal tool, or a migration helper by steering the model from the outside. That’s often the smart move.

But if the app needs to be secure, stable, and editable by future-you, the job changes. At that point, unread code is debt the moment it lands in your repo.

If you want the shortest answer to “what is vibe coding,” here it is: it’s not just coding with AI. It’s coding with AI after you stop reading what it wrote. Use that mode on throwaway work. Turn it off before the code becomes part of your product.