This may be interesting to you

"Vibe code is legacy code (val.town)" https://news.ycombinator.com/item?id=44739556

Thanks pmxi. I read that post when it trended, and it got me thinking. I then wrote a post that tries to give a framework for deciding whether to take a gig fixing vibe code.

https://www.slater.dev/about-that-gig-fixing-vibe-code-slop/

You can use vibe coding in strongly type languages?

I agree that vibed code can often be treated like other legacy code. However is it true that people are reluctant to change vibe code?

> strongly typed languages?

Depends on training data. It's not great at rust but it can chug along in small examples. I do suspect strongly typed languages are more suited to AI if it has the opportunity to learn them properly. The movement recently has been generalization, but i personally think if we want to reach further in AI coding, we need models with language and domain specialization.

I imagine a AI agent trained to parse LLVM and feed itself static analysis output, could reach new heights of code understanding for Rust for example.

> people are reluctant to change vibe code?

I think people are reluctant to change existing code in general. Its one thing for a personal project, but for a collaborative codebase, it's a large investment of energy to parse out a unfamiliar part of the system. "The original developer made sure this works, and it passes all tests, so i shouldn't poke it too much without knowing the system as well".

I think most often people have some vibe coded stuff that kind of does what they want but they don't really understand what it all is and how it works, or any confidence it can be made into something useful, so rather than spending time cleaning up AI code they just use it to grasp the idea and write it themselves. Whether any time is saved by going through this process with the AI seems doubtful to me. Sitting down with pen and paper and thinking through things would probably be more useful.

Legacy code isn't necessarily bad - it may just be complex, or poorly documented, having accumulated a lot of production fixes over the years that were never properly documented (if if the original project was - typically not).

Your legacy code products may be happily running without problems, due to all those production issues (incl. new requirements) that were identified and fixed over the years, with the problem only coming when there is a need to change it, especially when there is no-one left familiar with the codebase, maybe not even with the language/tools used to build it.