alt Hacker News > Fact is, vibe-coded projects devolve over time into an unmaintainable mess. The reason is simple, yet hard to fix: code maintainability and good architecture don’t have good measurements that we can apply, because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.
>
> For one, AI is not trained on what it means for code to be maintainable. For instance, any reinforcement learning done needs a reward signal that can be measured immediately, not in months or years.
I think at the end of the day, it is not impossible to have AI write "good" or "high quality" code. If anything, once the patterns are established, AI will be more likely to adhere to the patterns and rules than any human team. It requires the most experienced engineers on the team to split their time writing the core patterns and documenting them in references/skills.
But it takes a lot of "taste" and a willingness to slow down a bit with AI (to create necessary artifacts), something teams find hard to do when you can ship so fast now.
My experience has been that there is a camp of very senior engineers that are unwilling to adapt to reality and focus on documentation and writing (effectively producing skills and agent guidance which multiplies their effectiveness); they will cling to their knowledge thinking coding a sacred art.
Replies
To me the difference is humans (ideally) will learn when they build something in a non-optimal way, and so will improve over time to become a competent engineer / architect. We cannot be perfect but to me a huge part of life is learning from failure and improving yourself, something that LLMs short-circuit and cannot replace.
LLMs cannot truly learn and so are destined to produce whatever the "average" software looked like at their training cutoff, or worse to produce code based on _other_ LLM generated code.
Ouroboros eat your heart out
Yes, "code rot" is not in any way an AI-unique problem. Codebases like Flash Player or Bethesda Engine have been deep in decay long before AI was capable of contributing to them.
Historically, this was caused by hiring the cheapest developers one can find, having high turnover, outsourcing, pushing to ship at any cost and more. AI just lets you get there faster, and without having to hire bargain bin Indians.
The thing is, today's AI is already far better at "code rot per feature shipped" than the worst of developers - and I struggle to believe that we're at the limit there.
I've already seen benchmarks that test for AI's ability to make incremental changes and tweaks to code continuously - thus, tracking whether earlier changes make the latter changes harder. This makes for a clear target to RL for.
> Human written code just takes even longer to realize the mistakes because the pace is slower.
Yes but the ceiling is still higher, and that's the author's point. If you vibe code, without code review, code becomes a mess quickly. If humans write code by hand, then this is often the case too, but crucially, this is not unavoidable. Sure, most codebases are a terrible mess, but some are not. AIs unfortunately got trained on all of them (+ reinforcement-learned stuff) and therefore their quality standard is about as low as that of the average codebase, ie pretty damn bad.
But there are plenty examples of acceptably decent yet long-lived codebases, both in OSS and inside companies. You simply couldn't get that quality by vibe coding. (unless you review every line of code and every design decision, at which point you're about as fast as you would be writing it all by hand, assuming some seniority)
>Sad to say, but this is no different from human written code. Human written code just takes even longer to realize the mistakes because the pace is slower.
I really don't think so, poor written human code IME is rarely overly complex, where as the AI code is almost always vastly over complex. Naturally complexity can be an issue because it leads to more surface area for failures and challenges to diagnose, but where I am REALLY seeing an issue is the complexity hiding an issue. Something that should normally fail or produce an error is covered up by something multiple layers deep in the code that returns an incorrect value instead of an error when something goes off the rails.
Taste and smell still apply. You have to know the art and have comparative priors in order to judge the output.
> Sad to say, but this is no different from human written code. Human written code just takes even longer to realize the mistakes because the pace is slower.
When the pace is slower you can notice mistakes earlier because you have time to reflect. It also allows you to detect when it’s becoming hard to maintain and you can correct course, rather than after it has become an unworkable mess.
> Sad to say, but this is no different from human written code.
I don't think so. It's true that human also write shitty code but the key difference is we actually remember what is the intention behind those crappy implementations so someone can fix it later. aka it is the matter of long term memory that currently LLM architecture is not capable of.
You can argue that claude can read the whole linux codebase and report bugs, but they can only report local bugs, not systematic one. 1M context windows seems like huge, but the effective range is actually pretty limited, and it still does not equal to human insight.