I think this is a form of path dependency. We talk about unmaintainable messes, but honestly, if you look at Kairosoft or famous game codebases, you'll find 30,000 lines in a single file or just completely chaotic code. I am actually in a position where I see bad code all the time.

The truth is, "good code" is relative. It is determined by the specific domain and the composition of the team. Is incomprehensible FP (Functional Programming) code good? No, it isn't. A programmer must assess the team's capabilities and adapt accordingly. Good code is ultimately something that morphs based on the shape of the organization. Once defined this way, good code might share certain commonalities (like readability or a shared mental model), but its actual form varies wildly.

So, what is good code? That definition is missing. To be blunt, the Hacker News posts insisting that we must write "good code" are essentially a form of self-hypnosis.

Just look at paradigms. The mechanics of OOP have changed significantly, FP approaches have evolved, and DOD or DDD are fundamentally different from their early days. Whenever paradigms are discussed, someone claims, "That problem was solved in the past, and nowadays we do X," only for someone else to reply, "I don't think that's actually solved," leading to a fragmented breakdown in consensus. Ultimately, which knowledge remains as tacit knowledge is entirely dependent on the organization's capability.

You could argue that AI is terrible at simplifying code. However, I am skeptical that AI coding needs to be identical to human coding. When you actually code with AI, it often produces structures humans would call anti-patterns, including God Objects. Yet some of those structures can be faster or simpler for machines to navigate. There is no reason to assume that the optimal modularity for AI maintainers must be identical to the optimal modularity for human maintainers.

Of course, I am not denying that the rewards of good architecture are delayed, or that there comes a point where maintenance becomes impossible. But as the AI era ushers in an age of overproduction, software could become disposable, strictly personal, highly tailored to small niches, or ultimately, heavily polarized.

Realistically, programming domains fall into two major categories: "ship it and forget it" (one-offs) and continuous services. I agree with the OP's point that AI struggles to understand boundary delineations. But honestly, you can enforce those boundaries by injecting them into the spec. How those boundaries are drawn in the first place, however, is purely a matter of personal experience.

Personally, I define "good code" as code that allows the entity responsible for the software to achieve its purpose with a sufficiently low cost and error rate, factoring in the software's expected lifespan and future changes.

If you ask an AI to generate work based on this standard of what level of code is "adequate," you might get entirely different results. The biggest problem with discussions around AI is not just that ideological identities prevent proper evaluation (as seen in that article), but that the AI itself scales proportionally to its input. It is an incredibly difficult issue to judge because you don't know an individual's workflow or exactly how they are utilizing the tool.

I do think the value of reading code is important. However, much of what we are discussing in the AI era is actually rooted in the path dependency of how to become a good human senior developer.

Instead, the core focus of AI-driven development might shift toward defining broader abstractions: data semantics, invariant external contracts, and migration strategies.

Ultimately, I believe the paradigm shift of our era should lead us to ask: "How do we write code most economically in a system where AI is the primary maintainer?" The OP might think differently, but at least, that is where I stand.

I have more than 15 years in the industry. I have worked in some of the most horrendous codebase someone has ever conceived. Honestly? Humans can do worst than AI.

Let's stop overvaluing human work. Sure, I don't want AI to write the entire codebase without I know what the fuck it did.

But AI is on an equal footing with an average dev.

We already have a no-LLM policy where I work, and we're moving faster and delivering bigger features than ever.

Little boxes, little boxes, little boxes made out of ticky tacky. Little boxes made out of ticky tacky and they all look just the same.

The agents are trained by contained data. All agents. Similar data sets. Human knowledge packaged into little boxes that all look just the same.

When the boxes are doing all the work for us, the differences between them will come down to color.

There’s yellow ones, and blue ones…. And, they’re all made out of ticky tacky and they all cost just the same…

> because it takes months, years even, to notice the effects of bad architecture or of unmaintainable code.

Well said. The cost of bad architecture imposes a heavy penalty on the project down the line.

> The proficient developers, the experts, rely on their intuition built with sweat and tears, working long hours trying to debug and fix production issues

Long hours of grinding with the problem, the solution, the code and the machine all makes for an intuitive understanding of what a good architecture is in the first place.

LLMs are a tool. A useful tool unlike any we have seen so far. But still a tool. Treating it as such and leveraging it should be prioritized.

> "except that the software industry is special"

This is the labor theory of value; consumers don't care if the code is hand-made, they want the cheap goods (software) that are the output.

The entire field of software engineering has plenty of depth without requiring you to be the person actually writing and reading the code. The author falsely conflates reading and writing the code to be the same as understanding the structure and design and architecture of the system. These two things aren't the same and never were.

There is a cluster of users posting nonsensical AI-hate articles such as these.

The deeper issue is American business culture.

Everything is reactionary. The focus is always on short term profits. No one cares about long term effects --- until they start impacting short term profits.

This is an inherent vulnerability that is easily exploited by someone willing to engage in some simple, long term planning --- like China has already done with manufacturing.

For decades, the USA gladly shifted manufacturing to China without a second thought. Now, we lack the expertise to make our own and have no choice but to use China.

Replace "manufacturing" with "software" and "China" with "AI" and it's deja vu all over again.

AI's wisdom has been shown empirically by solving Navier-Stokes. Pay more attention here, please. Things are moving very quickly.