Comment by nkmnz | Hacker News Reader

Comment by nkmnz | Hacker News Reader

It’s ironic that all negative comments on here are dismissive because “slop’s baaaaad”. Yes, slop is bad. Carelessness is bad. Lack of understanding is bad. It always has been. Code has been copied from stackoverflow. Built-in methods or std libraries have been used in a wrong way. Edge cases haven’t been covered. Rate-limiting and other hardening tasks haven’t been taken care of until the system broke. The code wasn’t DRY.

Now, people are building tools that not only hide the solutions to these problems in some obscure coding tool, markdown file, or agent harness, but they build gates that help developers to elevate themselves from the darkness of not knowing better. The number of developers roughly doubles every ~3 years, so at any given time, half of the people building software have less than 3 years of experience. Most of them didn’t even study CS before starting their careers. Tools like this will be the new warning voice that told people like us 5 to 10 years ago to never copy code from stackoverflow that you didn’t understand. It’s great.

The problem with AI SE is that AI writes un-architecture-ed code. The problem #2 is that a lot of people suck even more....

> The problem with AI SE is that AI writes un-architecture-ed code

Not necessarily. I use SOTA models with established stacks like .NET which allow my agent to easily follow decades of best practiced patterns (DI, EF Core, ASP.NET Core...) so you still and up with proper architecture.

In fact I can easily still manually inspect everything bc I already know how it's supposed to be written.

The fact that you can say this with a straight face impresses me.

From my experience, the latest models still struggle to create good architecture in the sense of good system design. You mention a couple of generally helpful patterns for the structure of the code. But they don't help much to create logical units, with intuitive boundaries, good cohesion etc. - at which even the latest models constantly make awkward decisions.

> But they don't help much to create logical units, with intuitive boundaries, good cohesion etc.

Completely, 100% agree on these exact points. I have access to every frontier model at work. None of them write what I would call clean code. At work the teams that have gone fully vibe-coded have repos full of broken abstractions that just accumulate over time. Eventually most of the effort of the team and their AI tokens seemingly goes to fixing issues that then break other things. Any attempt at 'refactor this mess, make no mistakes' turns into a _huge_ churn of changes ("shuffling the deck chairs") without ever really fixing things.

Yea but you chose to blame the LLM, not the vibe coders.

As I said: prompting correctly and reviewing are still indispensable skills.

Ofc a big part of it is still knowing how to prompt correctly and manage context.

Perhaps a lot of devs still have a flawed mental model of how these things even work.

I agree, but if we go one step further, what is the goal of those logical units? If the answer is, to make the code more maintainable, then the next question is, for whom? For humans, or for llms? Is it still important that the code is maintainable for humans if no humans read it anymore? Those are not rethorical questions, I am asking them for real. What is "good quality" code in the age of AI? If there is a lot of duplication but no performance consequences, is it really a problem if only AI modify it?

It's fair questions. I think we can see that in lower complexity products, it's already not that important anymore. But I can see that for more complex cases (I'm working on a fairly complex video game for example), the maintainability is currently still important. As the latest models would otherwise still create too many inconsistencies that they can't dig themselves out of. Who knows where we are in 6 to 12 months, though!

Let him who is without sucking among you, suck the first stone.

AI writes unarchitectes code if you don't have a system for developing and maintaining a consistent architecture over time. In human coding, a lot of architecture decisions tend to only live in human brains, communicated through ephemeral means (text chats, voice calls, etc) and are not concretely documented. Since LLMs don't really have a way to manage long running architectural decisions (memory systems can only get so far, like it won't capture architectural decisions if you never talk about architectural decisions), you have to (have your agent) capture architecture design within the repository.

I personally like using openspec for this, because it makes the model iteratively ask you architectual decisions, and then manages creating and accessing the documents as needed.

> AI writes unarchitectes code if you don't have a system for developing and maintaining a consistent architecture over time (...)

I work at a ~15y old codebase; guess that the famous "architecture" is - a glue of half-baked solutions, unfinished ideas and inconsistencies. Recently I discovered there are 6 different ways used to create audit trails in the app. The "human memory" lives until person decided to switch job or is fired. Then the next person re-invents the wheel and cycle continues.

I suggest taking an honest look at "the architecture" people are so proud of - you might realize there is not much moat there after all. But then again - I mostly write cruds - so that's probably core of the problem, lol

Reply on news.ycombinator.com