Vibe code is legacy code

Something interesting is happening. A false narrative is spreading online, pushed by people who know little about engineering, and others who should know better.

They claim junior devs are now 10x more productive, and project managers are shipping code themselves. Now, close your eyes for five seconds and try to picture what that code looks like. It's 100% legacy, disposable code.

The problem isn't AI, or PMs turning Figma into code, or junior devs prompting like mad. The real problem is the disconnect between expectations and outcomes. And that disconnect exists because people are mixing up terminology that took engineers years to define properly.

- A lean prototype is not the same as a disposable prototype

- An MVP is not the same as a lean prototype

- And a product is not the same as an MVP

A lean prototype is a starting point, a rough model used to test and refine an idea. If it works, it might evolve into an MVP. An MVP becomes a product once it proves the core assumptions and shows there's a real need in the market. And a disposable prototype is exactly that, something you throw away after initial use.

Vibing tools are great for building disposable prototypes, and LLM-assisted IDEs are better for creating actual products. Right now, only engineers are able to create lean prototypes using LLM prompts outside the IDE. Everyone else is just building simple (and working?) software on top of disposable code.

I think you are not going far enough though: All code is legacy code. So vibe coding's ability to make writing more code faster isn't special because it's code nobody understands: Your hand-rolled code is also bad.

Once you embrace the fact that all the code is legacy, then it's clear how writing more code, faster cannot be helpful from a maintenance POV: You are just creating more work for yourself.

And no, libraries don't really solve the problem, but might make it a bit less so if they are well maintained, because hopefully then they are someone else's problem. Eventually it can be mostly trusted and be almost not legacy. But a library that changes too often, or has a bad interface, is just legacy code which you also cannot change easily for a double whammy.

The more one writes code, the more one eventually realizes that the one way out of the problem is doing less: Not necessarily you, but just needing fewer things, in general. Because all complexity is ultimately a puzzle for someone that doesn't remember, and that's probably you a week later, or even in the way you typed it, as what you thought were the requirements might not really have been the requirements. And even if they were what a supposed expert told you they should be, that doesn't mean that whoever told you was right, and that's true even when you are the supposed expert.

Even thinking outside of product view point - speaking technically, I can't think of anything worse than junior dev's or PM's determining what they want technology-wise. At least once a week in my entire career I've had to shoot down awful ideas because they would be unnecessarily risky, won't possibly scale beyond minor use case, etc.

I would hazard a guess it's going to be extremely profitable being a consultant in the next few years.

Well, all code once written is legacy code. But at least if written by a human you can talk sensibly to someone about it.