You Can Vibe Code Everything Now. But Should You?

Vibe coding is addictive. Describe what you want in plain English, wait a few seconds, and something appears on your screen that looks like it works.

It does work. For the demo. For the screenshot. For the tweet.

Then a real user touches it…

The tool changed. The gap didn't.

Here's the thing about the "anyone can code now" slogan: a junior developer with vibe coding tools is still a junior developer. A senior developer with the same tools is still a senior developer. The gap between them just changed shape.

A senior using Cursor or Claude Code knows what to watch for before it breaks. They know users will get locked out if the session handling isn't right. That the app in its current state will grind to a halt the moment more than a handful of people use it at the same time. That the form looks fine until real people start putting real data into it. They've seen these failures before. They carry a mental PTSD catalog of everything that can go wrong. And this is only achieved through experience.

A junior — or a non-developer vibe coding their first app — doesn't even know those failure modes exist. The AI didn't mention them. The prototype works on their machine. But the actual product doesn't.

Your 10% of work feels like 90%

There's an old truth in software development: the prototype only took 10% of the time and yet it feels like 90% of the work. But the remaining 10% is everything that makes it actually work for real people in real situations. And that takes 90% of the time.

Edge cases. What happens when the network drops mid-transaction. What happens when two people edit the same thing at the same time. What happens when someone enters data you didn't expect, or the third-party service you depend on goes down for an hour, or traffic spikes because your product got shared on social media. Security. Accessibility. Performance. Monitoring. The hundred invisible things that nobody sees in a demo but that decide whether your product survives a week of actual use.

Vibe coding didn't change this ratio. It made the easy 10% even easier. Which means that the thing you just built in a weekend even though you didn’t even know how to code? You've done less of the total work than it feels like. Maybe 5%. Or maybe just 2%. The other 90-plus percent is still ahead of you — and it's the part that still requires knowing how to build.

Unfortunately you still can't ask for what you don't know is missing, as the AI models don’t really know what level of execution you are looking for. For this, you need the lingo and the understanding of what you are aiming for.

The slop inheritance problem

And it gets worse. When you start a project, the AI generates a codebase. That codebase has structure, patterns, and assumptions baked in. If you're experienced, you can guide those decisions towards the eventual goal. You set up the architecture. You establish conventions. The AI fills in details within a framework you designed.

If you do not have the experience, the AI makes every decision for you. And it makes them based on the most surface-level interpretation of your prompt. Or just straight up guesses. The result is what we call AI slop — code that technically runs but has no coherent architecture, no consistent patterns, no thoughtful error handling. It effectively has no future.

Ah, but surely AI will fix it? In theory yes, in practice not so much. When you go back to the AI to improve said code, the agent reads the existing codebase. It treats what's there as the standard. Whatever patterns exist, it replicates. Whatever shortcuts were taken, it takes them again. The slop just becomes the template for more slop.

I've seen this repeatedly. Ask the AI to add a new feature to a vibe-coded project, and it copies the same sloppy patterns from the rest of the codebase. Nothing handles failures gracefully? The new feature won't either. Data flows through the app in three different ways depending on which part you're looking at? The new feature will pick whichever pattern it finds first and add a fourth. The agent isn't judging the quality of the existing code. It's treating it as intent.

Breaking out of that loop is brutally hard. You can't just tell the AI "do it properly this time" because "properly" requires understanding what's wrong — which brings us back to the experience gap. You have to find each specific problem, and describe what you want instead. And make sure AI understood you correctly, instead of defaulting back to the same slop. At that point, you're doing the senior developer's job anyway. Except now you're also fighting against the momentum of a codebase that's pulling everything toward its own patterns.

Fixing AI slop ain’t easy

This is the dirty secret of vibe coding — and the reason "vibe fixer" is now an actual job title. The time you saved generating the initial code? You'll spend it three times over trying to make that code production-ready.

Track down why users sometimes see the wrong data. Figure out why the app works fine for you but crashes for customers. Rewrite the login flow that works when you test it but breaks in ways you've never seen when real people use it. Restructure the entire backend because it was built for a demo and can't handle growth.

At some point, you hit the decision every developer who inherits a vibe-coded project eventually faces: keep patching, or throw it away and rewrite? More often than not, especially if you want to be sure, the answer is rewrite.

And that rewrite needs to be done — or at least guided — by someone who knows what the goal actually means in practice. Someone who's built these systems before and understands the invisible work that separates a demo from a product.

So what should you actually do?

There's a pleasant dream going around right now, and it goes like this: anyone in the company can build anything. No more waiting on engineering. No more specs. No more gatekeepers.

The dream is seductive because it's partly true and holds actual value. Raw code production has never been easier and faster. But code production was never the hard part, lot of it was done by junior developers — and the parts that were hard are still hard. Which means at some point, someone has to step in.

In reality, you have three options, roughly.

Stay in the dream and hope for the best. Fine for throwaway prototypes and internal tools nobody depends on. Dangerous for anything real. The moment a paying customer or a critical business process depends on what you built, the dream ends — usually at the worst possible time, in front of the worst possible audience.

Spend a few years learning what a senior developer knows. Genuinely valuable if you want to become a developer. But you'll pay with your calendar. And by the time you're up to speed, the problem you were solving might no longer be problem worth solving.

Get someone experienced to build it properly. This still costs money. Probably more than you budgeted, because the budget was based on how easy the prototype looked. But it's the option where the thing you ship actually works — and keeps working when real users, real data, and real stakes are involved. It's the boring, honest answer nobody selling "anyone can code now" wants to give you.

None of these options are free. That's the point. The cost was always there. Vibe coding just hides it behind a working demo.

The irony is that the more powerful AI coding tools become, the more leverage experienced developers have. The tools amplify whatever judgment is driving them. With an experienced hand at the wheel, you get ten times the output. With a novice at the wheel, you make mistakes ten times faster — and none of the intuition to spot them.

This is why vibe coding hasn't (yet) replaced senior developers. In fact it has just made them more important. It's made professional development faster, tighter, and more valuable. I've written elsewhere about what that actually looks like in practice — the workflow, the guardrails, the tests, the reviews, the monitoring. None of it is magic. All of it is experience, applied with the new tools on top.

Closing thoughts

If you're building something that matters — a product people pay for, a system that handles real data, an application that needs to work reliably — the gap between "it works" and "it's production-ready" is not a bunch of random details. It's the entire product.

The code was and still is the easy part.