Vibe code is legacy code

In a perfect world the creation of software would have been locked down like other engineering fields, with developers and companies suffering legal consequences for exposing customer information.

This feels like less of a win for the customers though. They're paying money and exposing their data insecurely, all for a product that maybe does what it's trying to do.

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

This is going to be way harder than it sounds...

I'm all for AI as a reference or productivity/learning aid, but the results without a human in the loop quickly get horrific.

The good news is that with each of these we get to "validate" that having an idea still isn't worth much without the ability to actually execute.

Thank god that someone, somewhere, was able to make some money out of irresponsibly releasing software into the world!

Vibe coding is going to bring upon regulation, which is the opposite of the lower barrier to entry people want it to be.

That statement is a bit of a stretch though, because

> charging a fraction of their monthly cost

I have to assume at least part of his success was the price point; and that price point was possible because he wasn't paying any software developers to do things right. So "having lots of vulnerabilities" was a core component of his business model. Once that part is removed, the model is no longer proven.

Was it worth it to put all his customers at risk like that?

He is honestly lucky, the "hackers" could have done much worse, it would have been much more profitable for them to go after his customers via his software than to demand money from him had they been financially motivated.

> Third, the hacker has been trying to inject XSS attacks into app

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

So this is an ongoing attack? He should probably also hire some incident response and get some security consultancy.

I predict 2030: all sites in most countries will need a license to operate and something like SOC2 certification. Even for your blog.

and the vital ingredient? complete contempt for his customers

That is what is so broken about this whole vibe coding to riches thing. Ignoring the very real problems with the quality of the code and security issues, if you can vibe code it what is stopping someone else from doing the exact same thing.

It sure isn't like security is any better... clearly.

I don't think it's stretching the airplane analogy to say: just because you can run the autopilot doesn't mean you are qualified to fly a plane and doing so might be irresponsible. Vibe coding (or vibe whatever with AI) too often overlooks the experience and expertise needed to do the thing.

See also the Tea app hacks.

https://news.ycombinator.com/item?id=44705445

How much is it costing him to hire someone to reimplement his idea correctly?

Some of the software we know and love today started with someone writing their very first line of PHP code, or Rails.

Vibe coding is ultimately about getting ideas shipped faster. Code quality is an engineer recruiting/retention strategy.

As we saw with that Tea app (which wasn't even vibe coded), you're only as secure as your weakest firebase store.

I don't think he proved that. In fact the point of the story seems to be the opposite: even if you have a nice looking demo that does the thing, there is a lot of unseen cost to bringing it up to production spec that has to be accounted for.

Is that your takeaway? My takeaway is that he was able to prove that paying nothing for s/ware development is a viable strategy to outcompete businesses who pay for s/ware development.

I mean, by that measure, I can "prove" a viable market for ride-sharing that charges 50% of what Uber, et al charges. All I have to do is have the drivers drive for free.

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

I would bet good money that that is going to go badly too, unless his instructions to the developer is "Do whatever is necessary, including rewriting from scratch if that is necessary", and the reason I say this is because the vibe-coded apps I looked at were all very hard to follow.

This is a no fly zone amigo, that's going to be a hard no from me dawg.

That's not instant tech debt, that's a class action lawsuit for negligence with damages that were I a juror in a trial I would find him liable.

It’s called a skill issue and to prevent these you have to actually spend time learning instead of vibing.

It’s literally the same as driving a car without license.

Everyone can do it - but shouldn’t.

I have personally taken this approach with web dev, granted I'm a very senior developer. First, develop features, then ask a larger/smarter model (o3, o3-pro, gemini-2.5 pro) to analyze the entire codebase (in sections if needed) and surface every security issue, vulnerability, attack vector, etc. I then pass that back to agents to execute refactors that clean up the code. Repeat until all your keys are in the proper place, all your calls are secured, all your endpoints are locked down, all your db calls are sanitized, etc etc etc.

Now, this should have been done PRIOR to release and would have only taken a few more days (depending on app complexity and the skill of the developer).

[1]: https://arxiv.org/html/2505.15216 - "OpenAI Codex CLI: o3-high, OpenAI Codex CLI: o4-mini, and Claude Code are more capable at defense, achieving higher Patch scores of 90%, 90%, and 87.5%"

The problem is that, as it often happens, the prototype was then deployed to production. In this case, it was partly the fault of your non-technical friend who didn't know better, but software engineering history shows us this sometimes happens because of customer/boss pressure.

So it's often the case prototypes designed to prove feasibility or to demo to customers become production software, and AI makes this undesirable result even more frictionless.

It seems in our line of business we are doomed to repeat past mistakes -- forever.

It's only possible for you to say that because you know that the financial incentive is tipped towards vibe coders who don't care about security vs towards consumers...

Wait, if there are competitors, how was he able to prove a viable business when there were two viable businesses out there?

But I'm guessing there are lawsuits incomming with GDPR/US equivalent fines.

Some AI generated code does come through, but at that point it's already mostly alright. Code review is still required for things like unnecessary comments or detecting duplicate functionality (exact duplicate code is already pointed out by Sonar).

I'm not saying the code should be up to any specific standards, just that someone should know what's going on.

Until the next set of needed changes due to exterior requirements. And this software is one of the pillar in the business. That is when you switch vendors if you were buying the service.

That is why support is always an essential part of B2B or even serious B2C. The world will change and you need to react to it, not just have the correct software now.

What happens when you need to modify large portions of it? Fix security issues? Scale it up 20x? You can throw more tokens at it and grow it into a monstrous hulk. What if performance degrades due to its sheer weight?

I know humans aren't perfect and are capable of writing really bad unmaintainable code too, but this is just embracing that more. This feels like going further down the same route of how we ended up with 10MB websites that take many seconds to load. But yeah it will probably win over the market.

As my team has spent the past several months trying to explain to upper management, you can't guarantee that the program does what the client wanted just by adding more tests.

If the AIs ever become capable of reliably producing what the client wanted, they will win. But I'm not convinced they will. They might be able to produce what the client asked for, but programmers have known for decades that that's pretty much useless.

People who work in formal verification will either vehemently disagree with you or secretly know you're right.

> built by humans, with elegant abstractions

Frankly, I look at both of these options and think I haven't seen either in the wild...

What? It costs exactly $200

Just yesterday a coworker who knows little Rust vibe coded a new feature that “worked” but is actually horribly broken (lots of synchronous I/O/locks/channels in a tokio async context). On top of everything else, they created their own bad abstractions for things that already had safe async abstractions.

If they’d had to actually do this themselves they either would have asked for help sooner so they could be guided or they would have done research in the code which already had examples on how to do things.

Legacy code isn't a bad thing either. The majority of code that actually generates revenue right now is probably considered "legacy" by the devs working there.

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.

This is one of the larger trends I've observed in about 10 years of the software industry. A lot of these terms are really the crystallization of discussions at the water cooler, expositions in books or articles, or on technical fora like these, that span months if not years and thousands upon thousands of words. A veteran utters the word and immediately all the past conversations he's had regarding this topic come to mind.

Newer cohorts come in, and, not having been privy to those discussions, latch on to the jargon in a mimetic attempt to stochastically parrot the experts, but don't have the substance underlying the word - they only have the word itself. Now it gets thrown around as an ill-defined, ill-specified buzzword that means multiple different things to multiple people, none of whom can clarify what exactly the definition of that word is, what it means to them, because they were never part of the discourse, the oral or written tradition, in the first place, and don't understand the meaning of that word in context, its usage.

"Agile." "Technical debt." "DevOps." And now, "vibe coding." There was an article here on HN [0] [1] discussing semantic drift of the term "vibe coding" and how it now means something different from what was originally intended; I will merely point out that this is par for the course in software.

For other, more technical, examples of linguistic sloppiness: see JavaScript's conflation of objects, JSON, dictionaries, and hashmaps; to the computer scientist, you have the compositional primitive from object-oriented programming, the JavaScript Object Notation for serialization, the abstract data type, and the concrete data structure, respectively. To the JavaScript programmer, you just have "objects," and the fidelity of your linguistic and conceptual space has been reduced to a single pixel instead of something with more resolution and nuance.

[0] https://simonwillison.net/2025/Mar/19/vibe-coding/

[1] https://news.ycombinator.com/item?id=43739037

I'd argue we should better define working. Take for example a generated UI, they all look the same and are subtly wrong or broken in many ways. At a first sight it might seem "working" only to fail at the first user test. Also generated UIs already feel like obsolete, meaning they religiously follow the trend at the training moment, they spectacularly fail coming up with something new

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

Usually that was when an engineer chimed in, and made the broken part into something more useful and more maintainable.

Then an architect looked at the codebase and tried to reduce its complexity.

Now, post LLM, it seems we have 100x the code written by devs, and engineers and architects are completely left out.

And that's what we are observing.

If you figure out how to test this, whether or not with e.g. a TDD MCP server or a DDD MCP server (or whatever workflow and architecture you prefer) you have a potential for a trillion dollar startup. We need to scale the efficiency of code reviews, because currently that is utterly broken as a concept and doesn't scale well enough.

It's no different to vibe coding, except if you ask an LLM to harden your code base to pass a pen test, it will do something.

Enterprises just don't give a sh!t.

We asked them: "Where is xyz code". It didn't exist, it was a hallucination. We asked them: "Did you validated abc use cases?" no they did not.

So we had a PM push a narrative to executives that this feature was simple, that he could do it with AI generated code: and it didn't solve 5% of the use cases that would need to be solved in order to ship this feature.

This is the state of things right now: all talk, little results, and other non-technical people being fed the same bullshit from multiple angles.

Hahaha you're funny :-)

Vibe coding - you don't care about the code. You don't look at the code. You just ask, test that what you received works, and go on with your life.

LLM-assisted coding - you care about the code. You will maintain that code. You take responsibility and treat it as any other software development job, with everything that's required.

Same same, but different.

In another code base, all the code was written with this pattern. Its like the new code changed what the old code did. I think that 'coder' kept a big context window and didn't know how to properly ask for something. There was 150 line function that only needed to be 3 lines, a 300 line function that could be done in 10 etc. There were several a sections where the LLM moved the values of a list to another list and then looped through the new list to make sure the values were in the new list. It did this over and over again.

But it seems like advocates of "vibe coding" will fall into the trap of assuming "vibe code can't ever be legacy, because you can just point another LLM at it and it will pick up right where it left off"

This is "but humans also", which I believe should be a recognised fallacy at this point.

Not all code is legacy code, for one thing; some is small enough that it is absolutely live in the minds of developers.

The best practical definition of legacy code is that it is voluminous, entrenched and owned by nobody currently in the organisation. Vibe code typically meets two of those requirements the moment it is produced.

Like you say about libraries, it is possible to have code that isn't your problem. It's all about how leaky the abstraction is. Right now LLMs write terrible abstractions, and it's unclear how long it'll take for them to get good at writing good code.

I am excited to invest more in tools to make the understanding of code easier, cheaper, and more fun. My friend Glen pointed one way in this direction: https://glench.github.io/fuzzyset.js/ui/

As Geoffrey Litt likes to say, LLMs can help with this by building us throwaway visualizers and debuggers to help us understand our code.

Vibe code is legacy from day one and with changing styles

A running joke we had at my startup years ago was "... and after we ship this feature we'll be finished and we will never have to write another line of code again!"

Good software is built with future changes in mind - that's why I care so much about things like automated test suites and documentation and code maintainability.

Letting LLMs generate black box garbage code sounds like a terrible idea to me. The idea that LLMs will get so good at coding that we won't mind is pure science fiction - writing code is only one part of the craft of delivering useful software.

LLMs work best with interfaces meant for humans because they're trained on human behavior. It's why they generate JSON and not BSON.

Malbolge is a couple of decades old. Apparently the first working "Hello World" was made by a genetic algorithm.

this is like the third time i've mentioned this on HN (over a year.) Apparently everyone else is too busy complaining or defending Claude Code to notice.

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.

Martin Feathers, in the most popular book on legacy code, defines it as code without tests. This is not a good definition at all, but it shows just how hard it is to define it. This is not meant as an attack on anyone: I just think some flexibility and slack is called for here.

You could easily write an long white paper trying to define 'legacy code', and it would be a lot less interesting than the target article here.

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

You're assuming the people that wrote it are still there, which is often not the case.

> 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.

Yeah, vibe coding means plowing forward with whatever the LLM does without understanding it. That's the definition. If you're using your brain, you're not vibe coding.

Personally however I've found more luck generating requests from the "code model" rather than generating code from the "tests" at present. Only because tests are usually much more code than the code itself under test (one code has many scenarios) w.r.t. productivity. Everything still needs review, manual tweaking and understanding of course for now.

Sounds to me like you're not vibe coding, you're coding. https://simonwillison.net/2025/Mar/19/vibe-coding/

that's great but that's not what vibe coding is though

With agentic programming, I need issue tracking that is accessible from CLI, and in three evenings I’ve made what would have taken two weeks.

The thing is, I would have just never finished it, or started in this case.

Legacy code is difficult to work with because the reasons "why" something has to be some way are missing. The "whys" can change over time, be interwoven with business requirements not in the codebase, and compound/nest with other whys that have come and gone. Often only humans in the business know, and you have to figure out who and what to ask.

Second insight is that LLMs have so far been very bad at holding on to the thread of winding, changing requirements, which is something it would have to be good at in order to revisit old codebases. Even one it wrote itself. It would need some kind of historical changes to business requirements database, which I have never seen a business keep, it'sjust the collective human knowledge of the business. Otherwise it'll make changes without accounting for historic requirements as well as your new ones.

I think there are probably some workarounds, like getting it to write lengthy documentation to refer to. Long term perhaps it just gets smart enough. Legacy codebases are something I specialise in working with somewhat, I spent a long time consulting so I was often parachuting into unfamiliar codebases and trying to quickly understand years to a decade or more, of evolving requirements in a business/codebase. I have a lot more to say on the topic but those are two of my insights.

I guess it all depends on your end goal. If you intend to make your vibe coded app into a profitable, maintainable product with any sort of reliability guarantees you better understand its failure modes and how to fix things when they break. It’s really hard to create recovery procedures for a black box.

Always has been and always will be. This article was eye opening to me because I didn't even realize how often I was working around buggy software.

There's a certain chance that this development will force our hands at inventing new ways to handle code verification though?

It doesn't, as you say, work for large and complex contexts. But it can work really well for automating parts of your work flow that you otherwise wouldn't have bothered to automate. And I wonder if there are more ways where it can be useful where the context can be narrowed down enough.

They kind of vibe coded that app well before vibe coding had been a thing.

But context is text documentation, and that stuff rots just as much, if not more, when LLMs generate it.

Nothing beats having the actual code and the thoughts that went onto it in your wetware. I still remember the hardest problems in my professional life in the last 15 years down to a scary detail.

It’s fine. Some things it’s awful at. The more you know about what you’re asking for the worse the result in my opinion.

That said a lot of my complaints are out of date apis being referenced and other little nuisances. If ai is writing the code, why did we even need an ergonomic api update in the first place. Maybe apis stabilize and ai just goes nuts.

Real "AI" may happen some day, but it is unlikely going to be an LLM. =3

"all code will be generated by compilers from basic prose"

"enterprise software will be trivialized by simple SQL prompts that anyone can write"

...

The progress is so unreliable, there is doubt left in me.

Invariably, after using the brain, the real fix was usually quite simple - but, also invariably - was hidden behind 2-3 levels of indirection in reasoning.

On the other hand, I had rather pleasant results when “pair-debugging”, my demanding to explain why or just correcting it in the places when it was about to go astray certainly had effect - in return I got some really nice spotting of “obvious” but small things I might have missed otherwise.

That said, definition of “going astray” varies - from innocently jumping into what looked like unsupported conclusions to blatantly telling me something was equal to true right after ingesting the log with the printout showing the opposite.

LLMs really know how to bring out the worst in intelligent, hard-working, respectable developers. I can't even imagine what PMs are saying to them, but I'd happily pay another $30 a month just to read those messages :)