Vibe code is legacy code

> And a product is not the same as an MVP

Tell that to almost every company I've worked for!

The whole "make it to the next financial quarter" attitude among directors and C-suite these days leads to the kind of crap where developers build an MVP and then are made to move on to the next thing. Like you said, it's not really about vibe coding at all. To a degree, they're right; the perception of feature richness leads to the bottom line irrespective of quality because few are truly comparing products, assuming it's feasible.

Hell, are developers (which we now call engineers apparently) even empowered to prototype things these days? I'm sure it happens, but it doesn't seem all that common. Maybe it happens in the gaming industry and actual tech (not "big tech"). Most coding outfits don't provide much affordance for that. It's just MVPs all the way down. At best, vibe coding just accelerates that process while quality suffers.

> People do understand it. Often, deeply understand it because they wrote it, and have lived and supported it for years. They know the reason behind the tech debt, all the odd tech constraints that drove it to where it is, they can keep the thing running without breaking a sweat. It is second-nature to them.

I don't think it counts as legacy code if the original devs are still around to work on it

Legacy is not just "old" it is something that was left behind by someone else

IMO, the time of "code as math" is over. No sufficiently large software system that interacts with the real world is provable to be correct like a mathematical statement is. They are all complicated, engineered systems that are backed by a mix of formal guarantees, earned design principals, experimental testing, rules of thumb, acceptable performance envelopes, etc

This is what all software will become, down to the smallest script. The vast majority of software does not need to be provably correct in a mathematical way. It just needs to get the job done. People love the craft of programming, so I get it, it's uncomfortable to let go.

But what is going to win out in the end:

- An unreadable 100K loc program backed by 50K tests, guaranteeing behavior to the client requirements. Cost: $50K of API tokens

- A well engineered and honed 30K loc program, built by humans, with elegant abstractions. Backed by 3K tests. Built to the same requirements. Cost: $300K of developer time.

If I am a consumer of software, and not particularly interested in the details, I am going to choose the option that is 6x cheaper, every time.

This definition doesn't make any sense to me. If code at an org is working, and there are people or at least a person at that company that understands it, how is it legacy? Just because it's been around for a while? At what age according to your definition, does perfect working code that can be improved or added to by currently employed developers, become "legacy"? I feel like you are falling into the "keeping up with the Jones'" trap.

I much more agree with the blog author. Once the last developer that has a deep understanding of a codebase moves on (or simply forgets it all), that's the point it becomes legacy.

The argument is that if you intent to maintain the code you should keep the AI on a very tight leash, and at least understand the architecture of the code, if not every line.