| ▲ | Kiro 3 hours ago |
| Yeah, it's baffling. I can't relate to these statements at all. What are people doing? Surely the smart people of HN would have been able to figure this out a long time ago. I also don't find these people in real life. Even the most junior developers I know are able to navigate this without creating this supposed mess. |
|
| ▲ | gregoryl 3 hours ago | parent | next [-] |
| Its a bit unkind to talk like this - the obvious and equally unproductive response is to question if you are really as good as you think you are. Are those junior developers not making a mess, or do you lack the insight to see it? |
| |
| ▲ | anal_reactor 2 hours ago | parent | next [-] | | Big codebases tend to become a mess anyway so if your company has experience dealing with shit, the fact that now shit is AI-generated doesn't substantially change anything. And I'm not joking. Imagine it this way - managing a group of skilled professionals is a completely different skill from managing a bunch of alcoholics doing a minimum-wage job, and sometimes the latter situation is just the reality you find yourself in. | |
| ▲ | throwaway314155 2 hours ago | parent | prev | next [-] | | Or perhaps the ones complaining aren’t as good as they think they are at coding, prompting, etc. | |
| ▲ | lelele 3 hours ago | parent | prev [-] | | This. |
|
|
| ▲ | Philip-J-Fry 2 hours ago | parent | prev | next [-] |
| I've seen two camps of people within the same company I work at. Some think AI is generating acceptable code. Others think it's generating slop. I sit in the middle a lot of the time as my opinion on code quality vary depending on how important the code actually is. I will say one thing, the people who I generally deemed as worse developers prior to the wide AI roll out are the ones that are more accepting of AI code. And consequently, they're the ones spending a magnitude more money each day. The people who were writing better code and, in my opinion, were stronger developers, are spending less on AI and are generating more acceptable code when they use it. And they can spot issues from a mile away, because they actually understand the code being generated. They're not just committing lots of redundant code. We had an AI outage for a day or two a few weeks back. The reaction from some people was like it was the end of the world and they couldn't do any work. Some projects got put on hold because no one actually knew how to work on the code base without AI. Other, better in my opinion, developers just went shrugged it off and got on with their job. AI over-dependence is a big issue that people will face more and more. Weaker juniors used to just be a bit slower and stagnate a bit, but they could still kinda work independently and understand what they were doing. Now they are almost entirely prompt monkeys, take away their Claude Code terminal and they are completely stumped. |
| |
| ▲ | flohofwoe an hour ago | parent [-] | | > I sit in the middle a lot of the time as my opinion on code quality vary depending on how important the code actually is. This is really the key insight that most people on the extreme ends of the discussion don't seem to grasp and then talk in absolutisms because they think that their tiny village is the whole world. It's the same kind of 'extremism' that dominates most discussions about memory safety btw. For some types of programs, code quality simply doesn't matter as long the program does its job, and generating those programs even with the most sloppiest vibecoding approaches is totally fine. And in some areas of the industry (like web development) these types of programs are basically the norm - but this sort of code was already mostly hastily cobbled together slop even before AI. I also see extreme differences in usefulness of LLM code generation. For anything JS or TS it works great because there's a giant corpus. For C code (or even more obscure languages) especially when using libraries which change all the time my experience is totally different (at least for code generation, bug scanning works quite well). That's my experience so far anyway, literally "hit and miss" with some areas where there are more hits than misses, and other areas where it's the other way around. |
|
|
| ▲ | skydhash 2 hours ago | parent | prev [-] |
| It’s not a mess as in spaghetti code, which you will find with novice programmers. It’s a mess as in complex and disjointed codebase. Happy path works somewhat, but it crumbles if you run it long enough or encounters an edge case. You need a very good level of insight to build a codebase to do what is supposed to do, to not do what it shouldn’t do, and to still be comprehensible. Because a software is a system and building system well is what engineering is about. |
| |
| ▲ | pmg101 an hour ago | parent [-] | | Isn't "spaghetti code" a casual term to describe "complex and disjointed codebase"? What's the difference? Have I been using the term wrong all this time? | | |
| ▲ | skydhash an hour ago | parent [-] | | Not really. Spaghetti code is usually related to the big ball of mud. Meaning anything you need to understand, you need to go up and down the files while being distracted by irrelevant concerns. There’s no abstraction, no separation of concerns,… Complex and disjointed codebase is the usual over engineering. The requirement calls for a quick printf, but the implemented module is equivalent to ncurses. And then every calling point turns into a complex ceremony. And most of them are subtly wrong in some way. Those are two distinct mode of failures. The first was the sin of novice programmers before LLM. The second was the sin of not so novice programmers before LLMs, at least until the pain of living with their mistakes taught them better. But with agentic tooling, the output is often the second. I believe mostly because no one publish the simple generic version of their codebase. Instead it’s the one that is aligned with their specs, simple in that context, but too complex in any other. | | |
|
|
