Comment by apimade | Hacker News Reader

Comment by apimade | Hacker News Reader

All code is legacy code.

And as someone who’s reviewed plenty of production scripts, functions, and services written by junior developers, including my own early work, this take is overly absolutist.

The problem persists in the vast majority of organisations.

You can write articles criticising LLM-generated code, but if you’ve spent most of your career fixing, extending, or re-architecting systems built by others, you should know better.

Until software engineering adopts the same standards, certifications, consistency, and accountability as traditional engineering, along with real consequences, these arguments don’t hold much weight.

This entire modern industry was built on the opposite philosophy: agile. Move fast, break things. Ship iteratively with minimal design. Drop production? Just revert. Outage? Oops.

Software is still treated like a toy. It’s playdough in the hands of toddlers led by other toddlers. You might be among the 1% who do things properly.. but the other 99% don’t.

And odds are, if you’re reading this, you’re not the 1%.

I see that you're not alone in your position clearly, but still, this is such a strange take to me. Do people not seriously not see, nay, instinctively understand the ontological difference between the difference between using code someone no longer understands and deploying code no one ever understood?

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

I don't actually see the difference. If someone writes the code and understands it but then becomes unavailable, what's the practical difference with no one having understood it?

One of the implementations underwent analysis.

Surely they both go through that before being merged? If not then I think the the issue is somewhere other than I'd being suggested.

Someone at some point had a working mental model of the code and a reputation to protect and decided that it was good enough to merge. Someone vetted and hired that person. There's a level of familiarity and history that leads others to extend trust.

You could never have the same amount of trust in LLM-generated code as in a human developer, even if you wrote a large amount of tests for it. There will always be one more thing that you didn't think to test. But the many reports of massive security holes in AI coding tools and their products show that nobody even bothers with testing. Neither the vendors nor the users.

The way I see it is that LLMs and humans are not inherently different. They are simply on different segments of a very complex spectrum of sensory input and physical output. Over time this position on the spectrum changes, for both LLMs and humans too.

With this in mind, it's all matter of what are your metrics for "trust". If you are placing trust on a human employee because it was hired, does this mean the trust comes from the hiring process? What if the LLM passed went through that too?

About familiarity and history: we are at the point were many people will start working at a new place were the strangers are the humans, you will actually be more familiar and history with LLM tools than actual humans, so how do you take that into consideration?

Obviously this is a massive simplification and reduction of the problem, but I'm still not convinced humans get a green checkmark of quality and trust just because they are humans and were hired by a company.

> Someone at some point had a working mental model of the code and a reputation to protect

This isn’t always true in absolute terms. In many places and projects it’s about doing a good enough job to be able to ship whatever the boss said and getting paid. That might not even involve understanding everything properly either.

Plenty of people view software development as just a stepping stone to management as well.

With reading enough code it becomes apparent that the code quality that AI generates will often be similar or better to human developers, even if the details and design are sometimes demented.

Agreed with you. I've always told people all code "rusts" (not a language reference) - in multiple ways: the original author's mental model, the contributors, institutional knowledge, and the supporting ecosystem and dependencies. All code atrophies towards being legacy and debt. The more the worse. AI Vibe coding simply creates much more of it, much faster.

piggybacking on everything you said, which is all true: Code is not a science, despite what pedants would have you believe. The annoying answer to "what's correct" code is, "it depends." Code is just a tool used to achieve a goal.

Reply on news.ycombinator.com