Every Generation Picked the Wrong Stack. Vibe Coders Are No Different.
Agents reproduce training data patterns. That's not a bug. It's why your rewrite is already scheduled.
Now you can build an app without understanding what's running underneath.
Look, as long as it works, it works... But if you have more ambition than a simple home tool, if you want to evolve it, scale it, eventually sell it, you will need to get your hands dirty at some point. The no-code wave said you didn't need to code. The vibe coding wave says you don't need to understand the architecture. Both are true, until they aren't. And when they stop being true, you rewrite.
LLMs don't eliminate this pattern. They accelerate it.
The Same Script, 3 Times
Sometime in the 80s, BASIC arrived with a straightforward pitch: you don't need to understand pointers or manage memory, just write the logic. And for a while this was completely real. You could build actual programs without ever touching the low-level details, which was genuinely liberating for a lot of people who just wanted something that worked. The problem wasn't the promise. The problem was what the promise kept invisible. When your BASIC program got complex enough, the coupling arrived right on schedule. UI logic and business logic tangled together with no clean seams and no way to test anything without touching everything. The rewrite wasn't a failure of BASIC. It was built into the deal from the start.
Somewhere in a drawer I still have a floppy disk from 1993 with a BASIC program that automated my little sister's birthday card list. Addressed envelopes, 47 of them, printed on a dot matrix at roughly the speed of continental drift. I have absolutely no idea why I'm thinking about this right now.
Visual Basic extended the same deal through the mid-2000s, just with forms and event handlers instead of line numbers. Then no-code showed up with an even cleaner version of the pitch: you don't need to code at all. Again, true, until you need a feature the platform doesn't support, or you hit the pricing ceiling, or you need to move data somewhere the platform can't reach. The ceiling on no-code is just the edge of the platform. You find it at the worst possible moment, when there's the most at stake.
Vibe coding is act 3. The pitch is upgraded but it's almost word-for-word identical underneath: you don't need to understand the architecture. Just describe what you want, the agent handles the rest. True, for a lot of cases, for a while. What's consistent across all 3 waves isn't the tool. It's the footnote the pitch omits: "you don't need to understand X, except when your problem has the shape of X." And that condition, the person starting out can't see it at the moment of choosing. That's what makes the promise feel real until the rewrite begins.
Your Agent Knows the Popular Problem
I've been reading threads this week about what to orchestrate around AI-generated code. State management, retry logic, rollback, all the plumbing that surrounds what agents produce. The tools in those threads are technically correct. They solve real problems. But the real problems they solve were created upstream, by earlier choices: a full React SPA, a thick client, complex state distributed across multiple services. If you don't have those problems, you don't need those solutions.
And whenever someone asks how to handle the orchestration complexity, at least 1 comment in every thread says: "just tell your agents to handle that." Which is completely true. And also sidesteps the more useful question, which is why those agents produced the complexity in the first place. (It works on my machine. The machine just happens to need 14 services running in Docker to function.)
When you ask an agent to build an app, it produces the statistically probable response for the type of problem it was trained on most often: not the response that fits your actual constraints, but the response most likely to be correct across all the times this kind of question was asked. The agent optimizes for the modal answer, which in practice means the dominant pattern in the ecosystem. So you ask for an app and you get the default stack: React with a bundler, a state management layer, the whole setup. The agent is doing exactly what it's supposed to do, I think. It just can't know that your specific problem doesn't need any of that.
I ran through the same exercise for tooling, not code: whether CLI or MCP actually fits production agents. The popular option has the same problem.
Before I Opened the Prompt
I have 2 projects running right now, built in roughly the same period, same developer, same AI-assisted workflow.
The first is a lightweight tool. Server-rendered, Hono JSX, zero front-end bundler. My agent's first pass came back with 23 runtime dependencies. I needed 1. The extras weren't wrong in any absolute sense. Each one solves a real problem in a real context, but none of those contexts were mine. (Claude Code kept proposing React Query for a server-rendered app with zero client state. I pushed back 3 times. On the 4th prompt it finally dropped the suggestion.) There's no state complexity worth naming and no flow complex enough to justify a state machine here. XState would have been engineering for a problem that doesn't exist.
You Died.
The second project is a SaaS with paying customers and a multi-step import flow where failure modes actually matter. If step 2 fails, step 3 doesn't run. If the import dies mid-way, the user sees the exact failure state, not a generic error. That project uses React 18 and XState v5, but just 1 machine, for exactly that 1 flow. The rest of the app doesn't touch XState. It doesn't need to. A product usually has many surfaces that are simple and 1 surface that has actual state complexity, and the mistake is treating the whole product as if it has the complexity of the hardest part.
Before I wrote a single prompt for either project, I asked myself 1 question: does this problem have distinct named states with explicit transitions and separate failure modes? For the tool, no. For the SaaS import flow, yes, but only for that specific flow.
The agent cannot answer that question. It doesn't know your problem well enough to ask it.
Your agent optimizes for the popular problem. Make sure yours actually is one.
The Constraint That Doesn't Delegate
The skill that has survived every wave intact is knowing which complexity your problem actually requires.
None of the 3 waves built it, because none of them had to. Each wave convinced enough people for long enough that the skill wasn't needed. BASIC did it first, then no-code packaged the same promise in drag-and-drop, and now vibe coding is running the same play in natural language. The ceiling is the same each time.
Vibe coding accelerates both sides of the equation: the building and the debt. The first rewrite comes faster, not never. The architecture question doesn't disappear. It gets deferred to a moment when there's more code to untangle and more decisions already baked in that now cost something to change.
The thing that doesn't delegate isn't the coding. It's the diagnosis. Before you open the prompt, before you describe the app to the agent: can you explain, in plain language, why you do NOT need X in this project? The agent already knows X is useful in general. The question is why your specific project, with its actual constraints, doesn't need it right now. If you can answer that, you can constrain the agent to the adequate stack instead of the modal one. If you can't, the agent defaults to popular, and it won't be technically wrong, just not right for you.
I laid out the exact mechanism in how prompt contracts actually constrain an agent. The constraint is the 1 step the agent can't do for you. Everything else, the agent handles pretty well.
It's also the skill that BASIC, Visual Basic, and no-code all said you didn't need to learn. Worth noticing.
When you take your car to the shop without knowing anything about what's under the hood, the bill is always a surprise. The mechanic knows his job. You just don't know what to question or what to push back on. Same with your app. You'll find out what's running underneath it the moment you want to change something, or hand it off to someone else. The invoice tends to match.
Sources
- Andrej Karpathy, original vibe coding tweet, February 2025. https://x.com/karpathy
- "Vibe Coding: From a Throwaway Tweet to a $6.6 Billion Industry." Reborn.hr, April 2026. https://reborn.hr/unwrapped/vibe-coding-from-a-throwaway-tweet-to-a-6-6-billion-industry
This post may contain affiliate links. If you click them, I might earn a small commission, costs you nothing, and helps me keep shipping quality articles every day for your reading pleasure.
The article walks through why every generation of builders picks complexity they don't need, then pays for it later. The demo-vs-product checklist in the welcome kit shows you which choices actually matter before the rewrite starts.