Vibe code is legacy code

What I think happened: there are two incumbents in this space that are not happy about him showing up and charging a fraction of their monthly cost for a better, more modern product (their products are Windows-based desktop software). So they hired hackers to hack his SaaS (because these hackers have never demanded money). Unfortunately, that vibe-coding resulted in some bad code that made it easy to hack. First, the user list was leaked on the FE of the code and the hacker emailed all of the customers. Second, the hacker got a hold of his Stripe key and issued every customer a refund. Third, the hacker has been trying to inject XSS attacks into app (we'll see a random `<script>alert()</script>` tag in some fields)

I think indeed, vibe-coded software in the hands of the inexperienced is instant tech debt. But at the same time, he was able to prove out a viable business in a matter of a few months with no engineering background and no technical capability.

Now he's hiring a developer to shore it up.

Was it worth it? Yes, it is terrible, shoddy, insecure code, but he proved out a viable business with just a few hundred dollars of investment.

Come to think of it, the exact same thing happened when the PC became popular. Mainframe people were aghast at all the horrible unprofessional mess that the PC people were creating.

You still think out all the classes, algorithms, complexities in your head, but then instead of writing code by hand, use short prompts like "encapsulate X and Y in a nested class + create a dictionary where key is A+B".

This saves a ton of repetitive manual work, while the results are pretty indistinguishable from doing all the legwork yourself.

I am building a list of examples with exact prompts and token counts here [0]. The list is far from being complete, but gives the overall idea.

[0] https://sysprogs.com/CodeVROOM/documentation/examples/scatte...

And as someone who’s reviewed plenty of production scripts, functions, and services written by junior developers, including my own early work, this take is overly absolutist.

The problem persists in the vast majority of organisations.

You can write articles criticising LLM-generated code, but if you’ve spent most of your career fixing, extending, or re-architecting systems built by others, you should know better.

Until software engineering adopts the same standards, certifications, consistency, and accountability as traditional engineering, along with real consequences, these arguments don’t hold much weight.

This entire modern industry was built on the opposite philosophy: agile. Move fast, break things. Ship iteratively with minimal design. Drop production? Just revert. Outage? Oops.

Software is still treated like a toy. It’s playdough in the hands of toddlers led by other toddlers. You might be among the 1% who do things properly.. but the other 99% don’t.

And odds are, if you’re reading this, you’re not the 1%.

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.

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.

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.

Now, they see themselves challenged to defend against the non-technical departments, because all they see are some elitist developers, that deem something as "not good enough", which, from a user standpoint, "is working quite well".

However - it's unmaintainable. That whole situation is a mess, and it's becoming bigger and bigger.

I’ve noticed myself writing requirements for a feature and asking Claude to help me think through and expand. Obviously in a real project, there are challenges: (1) how do we tell Claude what is already in the project so it doesn’t reimplement existing methods? (2) how do we get Claude to fully implement the feature and not just “stub it out?” (3) how do we help Professionals maintain visibility and digest the new code?

Claude recommends the explore-plan-code-commit loop. I’m working on a package which formalizes that process within a Laravel application.

Wow, no. Bad misunderstanding of what legacy means.

Long-lived organizations all eventually go through tech renovations, where they re-platform their business functionality onto more modern systems. But sometimes, the cost/benefit analysis to that re-platforming doesn't make sense... yet. The pieces of the business still running on the former platform are legacy code.

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.

But it is not easy for anyone other than them. That is the true risk of legacy code, and that is probably where the author got off-track. They may have only ever worked in orgs after the last of the legacy coders left, and everything was a disaster. You definitely do not want to let a legacy system get to that point... and at the same time, if you ever do get there, the cost/benefit analysis has changed and you need to retire the legacy stack.

All that being said, now, yes, we can compare it to vibe coding. If nobody understands the code from the beginning, you never have that magical timeframe when someone just keeps the system alive with ease. You never solved business problems with it. It is just bad code launching straight into the disaster-filled zone where nobody can maintain anything.

I have seldom encountered these.

What I encounter, instead, are lashups that the engineering team thought would be throwaway, but which Management made "Final Ship" code.

I have learned to always do "ship-shape" code; even for the most innocuous projects. I may be a bit sloppy as I'm exploring different paths, but the minute I decide on a firm plan, the code cleanup and documentation starts.

What's happening is that all this "vibe coded" software needs someone to fix it when it breaks. I've been getting more requests than ever to debug AI-generated codebases where the original "developer" can't explain what any of it does. The security audit work alone is keeping me busy - these AI-generated apps often have vulnerabilities that would never pass a human code review. It reminds me of when WordPress democratized web development. Suddenly everyone could build a website, but that just created a massive market for developers who could fix broken WordPress sites, migrate databases, and patch security holes. The difference now is the scale and complexity. At least with WordPress, there was some underlying structure you could reason about. With vibe coding, you get these sprawling codebases where the AI has reinvented the wheel five different ways in the same project, used deprecated libraries because they were in its training data, and created bizarre architectural decisions that only make sense if you don't understand the problem domain.

So yeah, the jobs aren't disappearing - they're just shifting from "build new features" to "fix the mess the PM made last weekend when they tried to ship their own feature."

There are approximately two definitions of "legacy" code that I'm familiar with. One is: "valuable code that you're afraid to change." This definition is subjective. I might be afraid to change code that you're unafraid to change, especially if it's code that you wrote (because you remember, at least vaguely, how your code is "supposed" to work).

Another definition of "legacy" is attributed to Michael Feathers: "Legacy code is simply code without tests." The definitions overlap because code without tests is definitely scary to change, because it's very hard to be sure whether or not you've broken it, or even understood it in the first place.

When vibe-coding with an LLM that generates automated tests, (as they mostly all do nowadays), it's not legacy code. The tests both specify and ensure correct behavior.

Automated tests are particularly useful for vibe coding, because they help prevent LLMs from hallucinating answers. (This is also why type checkers are so helpful for LLMs.)

Once the code has tests, you can pretty much let the LLMs change anything they want, including refactoring the architecture. LLMs are extremely good at refactoring code with automated tests, in the sense that they'll puke out some hallucinated, hilariously wrong answer, and then refine their answer automatically until it passes the tests. (Just like I did when I was a junior engineer.)

But watch out, because sometimes the LLMs try to delete tests that are hard to pass. If vibe-coding means reading no code, not even the tests, then, yeah, you're gonna have a bad time. But if it means "only reading the tests and not reading the application code," then vibe coding works pretty well, actually.

What the new systems give you (and especially junior engineers/PMs) is disposable code with automated tests, ensuring that that you can dispose of the code and regenerate it (aka refactor it) and add features with confidence.

That's the very opposite of "legacy code."

I've found it faster to have AI write the code, revise with instructions as necessary, and delve into the code itself if I need to.

What we've had a hard time with is understanding what this article calls legacy code, and also understanding where our new changes fit into a larger context.

It isn't at all dissimilar from the paintbrush analogy that all the (neo)vimmers love. We spend more time reading and navigating than we do writing.

AI needs to help with that.

I think that we devs are now very skeptical because we are the ones that have to fix the sh that llms spit out. But likely we will be taken out of the loop completely.

What’s the definition of “Legacy Code”? It’s code that has business value.

(otherwise you’d just delete it and move on)

Interesting times ahead for sure.

It's very true that any vibe code is immediately legacy after they are generated. In other words, they are incarnations of foreign minds, things from a realm that is shuttered from my access, and they are giant pile of code that is beyond immediate recognition to any human engineers.

There’s just shit buggy software everywhere now and I’m definitely not expecting AI to make the way we build things better.

Full context > human context capacity > LLM context capacity.

We should all be able to agree on this and it should settle the debates around the efficacy of vibe coding.

I think the whole premise of the article is wrong because it compares apples to oranges, assuming that you’re going to maintain “vibe code” in a traditional way.

So if the foundation is overengineered, it will produce over-engineered code on top. If your code is super clean and succinct, it will produce code that is equally neat and succinct.

I've used Claude code with my own backend serverless platform and it's like it can read my mind. It's almost exactly how I would do it. It's like working with a clone of myself. I can implement nuanced features and ask for very specific changes and the success rate is extremely high.

On the other hand, I've worked with some other people's code which was slightly over-engineered and it struggled. I managed to achieve what I wanted with a lot of manual intervention and careful prompting but it was a very different experience and the code it produced didn't look like my code. It looked like it was written by a mid-level dev.

I can sense that it's a code completion engine because it clearly doesn't have an opinion about code quality. It doesn't know what metrics to aim for. It doesn't aim for succinctness; just as most human developers don't aim for it either.

My assessment of LLMs is that they don't have a specific intrinsic goal so the goal/motivation is inferred from the text it sees (from the input). If the original author of the code was motivated by creating complexity for the purpose of lock-in factor and career advancement, the LLM will produce code which optimizes for that. Unfortunately, this describes the vast majoy of code which is produced.

You can tell a lot about someone based on their code.

What we are seeing right in front of our eyes is how the boundaries of what is possible in the realm of software programming has gone from AI/LLMs poorly writing simple scripts, to being able to "zero-shoot" and "vibe code" a complex system, with a set of instructions written in natural language.

What we might be seeing in 2025 is how programming, the way it has been for the last decades, be disappearing and becoming a rare artisanal craft, not meant for being productive, but for showing off skill, for intellectual entertainment of the programmer.

I know how hard this hits the real coders. I am one, too. But I cannot unsee, what I have seen. The progress is so undeniable, there is no doubt left in me.

As I did this, I was keeping everything documented using a memory bank approach[1], so that I can fire up Claude Code and get it up to speed without explaining everything from scratch. Even with this disciplined approach, the code base got to a point where Claude would "forget" the big picture and start trying to optimize locally, hurting the global optimum. Eventually, I got burnt out by having to keep it in check every time it tried to do something stupid. I found myself always needing to remind it to check other modules to see how things fit together. I guess the memory bank got big with many concepts and relationships that Claude "got lost" in it.

Also, I realized that I missed the opportunity to learn deeply all those topics. so now I'm back to coding things myself, with little help from Cursor Tab, that's it. Will see how that goes.

[1] https://docs.cline.bot/prompting/cline-memory-bank

> If you don't understand the code, your only recourse is to ask AI to fix it for you, which is like paying off credit card debt with another credit card.

Excellent article! But I wonder if the above point will always be true. Maybe AI at some point could become better at cleaning its own mess?

An engineer can guide an agent to write good, modular code, but a non programmer can't.

The ecosystem is bigger than the internet.

I really don't want to sign up for a service and then get my shit leaked immediately

In general, a good code base teaches future developers how to leverage a pragmatic solution in the context of the use-case. Often, "vibe" code relies on superfluous computational heuristics overhead to compensate for people that had zero notion of what they were doing in the first place.

To summarize, no one competent is fooled by low-value content farmed blogs, or the folks that rely on LLM. The age of Spam exceeding content is upon us. =3