Comment by dfabulich
6 days ago
Vibe code may be "disposable," but isn't "legacy code" if it has automated tests that the product owner can read and understand.
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."
Have you seen the tests that LLMs write if you just vibe code it and don't pay attention? They're generally worse than worthless. They test pointless stuff and they miss important stuff. If you have them on a tight leash, then you can get some useful tests, but then that's not vibe coding.
> 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.
In the long run that's the promise of RL; build the verifications vs the model. As a SWE we could be relegated to doing what many consider the "boring part" of software development, which is just writing case by case test cases rather than the code/model of the world interaction. The "math/intellectual" part may get rarer which sadly devalues the skill/intelligence part of software development assuming the AI can come up with a code model that meets requirements.
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.