In today's massive applications, the number of people who can see the entire structure is very limited—yet commercial applications still work.

And I think GPT Codex and the products from AI companies are, at least for now, working reasonably well.

Of course, it depends on your baseline for quality.

But here's what I think is the core point:

Modern SaaS applications have become significantly more complex compared to older codebases. If you look at old books on open source architecture, the lines of code and overall size were much smaller. But today's commercial applications require a much higher level of complexity just to be marketable. In that kind of complexity, there are bound to be many bugs. But I think AI has significantly reduced that complexity burden

▲

mikojan 3 hours ago | parent [-]

We have been building complex software before and we continue to do so. The question is where is this mythical codebase 10 times more complex then the Linux kernel that we were previously unable to produce? Or let it just be complex software. Where is it? What are the names?

▲

jdw64 2 hours ago | parent | next [-]

The real problem is that we forget that there was a lot of bad code in the early days.

When I studied books from 10 to 15 years ago, the patterns that were considered 'common practice' back then would be considered low-quality code today.

Our threshold has risen. People tend to forget the rings of experience embedded in community codebases and only look at the final results.

And they always claim that only the best results represent their community.

But the 'bad results' were also produced by the same community.

From that perspective, I think the floor has risen significantly. You might disagree. People with name recognition in open source usually only see the 'best' code.

But I mostly see the 'worst' code.

This is an issue of accessibility depending on your environment. I work for $15 an hour, as a freelancer doing subcontracting work in Korea, so I mostly see the worst of the worst. In that context, AI code quality feels like a huge improvement.

Because in closed source codebases, there's plenty of low quality code.

In contrast, open source projects tend to curate only the best code, driven by visibility and reputation. I think that difference is significant.

You might not agree with me. And that's fine. We all have our own value systems. I don't agree with you, and you probably don't agree with me. That's a natural consequence of us being different people.

But here's what I think: I respect you, but our views can differ. I think your point is valid in certain contexts, but I stand by mine.

▲

pmg101 42 minutes ago | parent [-]

Can you give an example of a pattern that was considered common practice in a book 10 to 15 years ago that would be considered low-quality code today?

My experience is pretty much the reverse: that we seem to just go round and round relearning the lessons that had already been learned in the past.

	▲	ModernMech 22 minutes ago \| parent [-]
		I feel like the industry has learned a lot of good lessons from functional programming, and that has been reflected by functional features being baked into almost every popular imperative language.

▲

jdw64 2 hours ago | parent | prev [-]

I think this is a complex issue.

If there were a need for a new open-source OS to replace Linux, it would be used then. Once infrastructure becomes entrenched, the cost of dismantling or replacing it becomes enormous.

So you might argue:

'If AI is so great, shouldn't it be able to directly modify Linux's millions of lines of code right now?'

My answer is different:

'Why break something that already works? It only makes sense to change it when a problem actually arises.'

The example of Bun, originally written in Zig and later ported to Rust, illustrates this. Zig is a relatively new language, but whether for political reasons or not, Bun was eventually ported to Rust. And after the rewrite, Bun still works just fine.

And rewriting infrastructure from scratch is fundamentally a cost issue.

I can handle up to 60,000 lines of code on my own. With AI, I can handle up to around 200,000 lines. But building new infrastructure from scratch is an entirely different matter.

Why would you replace something that already works with AI? That's a separate question. If the current OS were no longer viable and a new one were needed, then the situation would be different.

In other words, I don't think your argument is wrong—I just don't think there's enough motivation for it.

In that sense, codebases that heavily use AI are already appearing in abundance.

There were issues with Open CLAW, but it was purely AI-written and still boasted a huge number of active users, right?

Same goes for Codex.

So my conclusion is this: AI is currently being used in layers above the infrastructure. But if a new infrastructure needs to be built, that's when AI will come into play.

In other words, it's a matter of motivation. Using AI for coding doesn't eliminate maintenance costs. And to be extreme, both maintenance and generation now require spending 'tokens'—you're paying money instead of the developer's time. We need to think about that cost.

In other words, there's no reason to break something that's already working.

I'd summarize it as: there's no reason to reinvent the wheel.