Comment by hibikir
6 days ago
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.
> 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.
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.
That's not what legacy means. Legacy means the people who understood it are gone and you're left with code that's hard to maintain because it's hard to understand because the people who understood it are gone.
I find this a bit like saying that we can't understand East of Eden because Steinbeck is dead.
Yeah, we all own all code, if we can't understand the code we own, we study it. If we need to change it, we change it.
"Legacy" for me is a bad word. I refuse to use it, and I scold my colleagues when they do: it's our code, we modernize it if we don't like it, and if we stop using it, then it's finished code. What is this false dichotomy between legacy code and "not in prod yet code" ?
In companies we call our regulatory prosecutions for fraudulent behavior that are so complex that they last for 10 years "legacy matters". Do you think that points at a statement of factual representation, or at a ridiculous attempt at distancing ourselves from our actual responsibilities ?
A program is not a novel, despite the arguments of literate programming fans. It is more like interactive fiction. In the small, it is just short pieces of text. In the large, there is an invisible network connecting each of them. And the challenge you are facing when assigned to legacy code, is to make changes in the small pieces of text that are consistent with that network, or even sometimes changing the connections.
All code is a liability but all code is not legacy. I'm not OP but I agree Vibe is legacy simply because there is no longer anyone around that is qualified to maintain it or know the reasoning behind it (there never was)
The argument against this can be summed up as throwing more data, training and gpu's at the problem until it works again.
Knowing if it is actually working or not is half the problem.
1 reply →
Fair! I agree that we want as little code as we can get away with. We love pull requests with a lot of red (deleted lines).
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.
But we have plenty of tools that helps us understanding code. Things like inspectors (UI,network,..), tracing (including the old printf), debuggers (stack frame for function calls and variable values), grep (for context and overview) and static analysers.
I see people going all in with LLMs and forgetting that those even exists. It's hard to take such people seriously.
Strong agree! For example, we at Val Town just invested very heavily in getting a good ol' fashioned language server to work in our product to power hover-overs and type information in our web editor. That'll likely be our next company blog post...
1 reply →
I'm sorry, but how is all code legacy code? Have you never written or worked on a project for which you got such a deep understanding that you could track down the likely source of a bug in your head before even fully reading the issue? Visualize how you'd add a feature before opening the editor? This is not legacy code just because it's old.
My hand rolled code isn’t legacy code for at least three months. After that I need my documentation to make changes.
Vibe code is legacy from day one and with changing styles
If you have good documentation and you're on stable platform, you can go for years without changes (Common in the Common Lisp world). Which is what we called finished software. Just light maintenance here and then.