Why vibe coding doesn't scale

I've seen some videos in my personal feed where someone opens an IDE and types into the prompt: "create a login system with registration, password recovery and JWT authentication" — wait... they missed the most important part at the start, "Act as a Senior Developer and create...", then they wait 30 seconds and accept whatever appears on the screen. At the end, the video's title: "How to create full authentication in 2 minutes with AI." Done, countless likes, comments like "this will change everything", "I don't need to study backend anymore", "programming is over."

Anyone who knows a bit about web programming asks: seriously, is that all there is now? Is there no reasoning behind this? Is it just ask-and-accept? Where are the architectural decisions? Why on earth use JWT... does this guy at least know why JWT and not the good old Session Cookie?

You look at it and think, keep going like this and it's going to blow up. And it's not because the AI wrote bad code. The code will probably even run. The problem is different, and it's the one nobody talks about because it doesn't sell courses, won't make a thumbnail and doesn't generate engagement. There was no architecture there. There was a prompt and a hope.

That's what I want to talk about today.

What vibe coding is (to me)

Vibe coding isn't "using AI to program." I use AI every day and I don't consider myself a vibe coder. Vibe coding is programming by accepting everything the AI spits out without having a mental model of the system you're building. It's outsourcing the thinking, not
the typing. Yes, in my view most of the thinking and decisions should be yours; the AI should only type.

The difference is subtle, but it's everything. When I ask the AI to generate a Service Object (this one hurts the Ruby on Rails purists), I already know:

• Where it will live in the project's structure.
• Which pattern the other Services follow.
• What it can and cannot do.
• How it will be tested.
• Who will call it and in what context.

The vibe coder asks "make a service to process payments" and accepts whatever comes. On the next prompt, asks "make a service to send email" and also accepts whatever comes. Not realizing that the two end up with completely different patterns, because the AI often won't remember what it generated five minutes earlier.

Why it seems to work

This is the sneaky part. Vibe coding seems to work. And it seems to work very well.

The demo runs. The CRUD shows up on screen. The login authenticates. The user signs up. You open the browser, hit back, everything responds. You feel like you produced something — you produced a lot. And you did produce something, but you produced something nobody has tried to maintain, change, scale or debug yet.

Vibe coding's technical debt doesn't show up on day 1. It shows up 90 days later, when someone asks for a "simple" change and you discover that business logic is scattered in four places, each implemented differently because each prompt was generated in isolation. It shows up when a new person joins the team and takes two weeks to understand something that should have taken two days. It shows up when a poorly thought-out migration runs in production and leaves behind a lot of overengineering.

Where it really breaks

Let me be specific, because I've fallen into some of these traps myself using AI in next-next mode: Business rule scattered. You ask for the user registration in one prompt. Two weeks later, you ask for the profile update
endpoint in another prompt. The AI generates email validation in both places differently. When the client asks to accept another email domain, you change it in one place and forget the other. Bug in production.

Another example: architectural inconsistency. Half the project uses Service Objects, half has fat logic in the controller, half shoved it into the model. It's not a decision, it's an accident. Each prompt arrived with a different mood from the AI.

Tests that look like they test (when they exist). If you're not in control, the AI will be great at generating tests that pass, and terrible at generating tests that protect against edge cases. There's a huge difference between assert response.successful? and a test that actually covers the business-critical path. The vibe coder doesn't notice the
difference because they've never seen a test save a deploy.

What changes when you have architecture in your head

When you know where the system is going, the prompt stops being "do this" and becomes something like: "implement this use case following the Services pattern in app/services/, returning a Result object, and generate tests covering the happy path and the two error paths I've already mapped."

Do you feel the difference? The second prompt is longer, more annoying, and generates code that fits the rest of the project. The first generates a loose piece that will fight with everything that exists.

More importantly: when you have architecture in your head, you review the code the AI generated with the same criteria you'd use on a junior's PR. You read it, question it, request changes. You say "no, that responsibility doesn't belong to that object", "that
name isn't clear", "that test doesn't test anything." You're the senior in the room. The AI is the fast intern.

Vibe coder doesn't review. Vibe coder accepts.

Fact

AI amplifies who you are as a developer. It doesn't invert you, it doesn't replace you, it amplifies.

A senior with AI becomes absurdly faster, because they know what to ask for, what to reject, and when to intervene. The AI takes the mechanical work off their plate (words per minute don't matter) and returns focus to the real work, which is deciding.

An inexperienced junior with AI produces more junk, faster. And worse: they produce junk that looks good, because the AI writes nicely.
Correct indentation, names in English, a comment in the right place. On the outside it's Google. Inside it's nothing.

The tool doesn't replace what you don't have. It just makes it more obvious.

Wrapping up

Vibe coding scales for demos. It scales for a GitHub portfolio that no one will open again. It scales for a YouTube video that will blow up for a week.

It doesn't scale for production. It doesn't scale for a team. It doesn't scale for a system that needs to be alive five years from now, with new people joining, requirements changing, and growing scale.

To conclude, it is possible to write a good system using AI, but you always need to be in control, making all the decisions. And here's a tip: all those architectural decisions should be in the file CLAUDE.md/AGENTS.md. That will save you a lot of time.