back
4 comments
Hah, I love sharing that link too. But contemplate this: Give the Oracle 12 engineering culture an unlimited token budget, do you think the code will get better or worse?

Based on what I've seen in industry, I think the answer could be very likely worse. They'll generate bad code at an even faster rate, and very quickly nobody in the company will have any idea how anything works.

What this proves is that "human made" is not automatically good. Better is a complex question. LLMs have a magnifying affect on the quality of human decisions.

Oracle's codebase got the way it is over several decades of human programmers and customers with changing needs and ambient technological environments. LLM code can get that way in a weekend.
Dunno about that. I have some "vibecoded" projects. I wouldn't exactly call them stellar examples of craftsmanship, but they sure as hell didn't become insane thousand flag contraptions. I actually manage to understand the code when I review it.
Show me a fully LLM-generated database with an implement that's clear, documented, and adequately bug free.

Codebases degenerate when the authors do not understand the system in which they operate and make changes that degrade the cohesion of the system as a whole. Humans do this all the time; at my company we had a 10k line lua function (within a 250k loc lua service) that grew through ten thousand point modifications. It's bad and humans caused it. Now, it's 15k lines of code and 10k lines of misleading slop comments.

LLMs do not go through the struggle of understanding and don't experience the distress of "wtf am I reading?" and don't experience the drive to make things less horrible for the next person. That suffering loop is how many codebases halt degradation and in the absence of suffering LLMs will pile bugs and rot endlessly.

I was arguing with a colleague today that we will never have a reason to make our AIs autonomous and sentient. But now I can't stop imagining an AI startup meeting where somebody says "LLMs do not go through the struggle of understanding and don't experience the distress of "wtf am I reading?"" and the next second the technical founders jump in joy "...that's our way in! Let's outcompete the competition by inventing pain for AIs!"
sounds like the torment Nexus, but someone else is being tormented.
> we had a 10k line lua function that grew through ten thousand point modifications

> It's bad and humans caused it.

LLMs do the same thing. I review the code and interrogate the model about the bandaid fix it applied until the proper architectural solution becomes clear. Then the model implements the correct solution which usually involves some major refactoring.

> LLMs do not go through the struggle of understanding and don't experience the distress of "wtf am I reading?" and don't experience the drive to make things less horrible for the next person.

Of course not. That's the human's job.

And it's not every human either. Way too many humans are actually quite content to ship whatever works then go the hell home. Just a job after all.

I've worked at many firms as a SRE/DevOps and have seen lots of human written code that fell into at least one or generally of the below patterns:

- 30+ committers on <5K LOC

- software is robust/rock solid but the code is essentially unreadable

- changes take a long time b/c there are no tests

Whenever folks mention that LLMs write buggy code I think of the above.

> software is robust/rock solid but the code is essentially unreadable

I come across this fairly frequently. I think it's because the code has simply been tested into submission. So it works for that particular set of use cases, but the instant you try to add a feature, it all falls apart.

What you are describing is not bad software, it's complex, performant and software with a long lifetime.
> can't change a single line of code in the product without breaking 1000s of existing tests

> all held together with thousands of flags

> ridden with mysterious macros that one cannot decipher

> needs to understand the values and the effects of 20 different flag

> Sometimes 100s

> only reason why this product is still surviving and still works is due to literally millions of tests

> The fact that this product even works is nothing short of a miracle!

Sorry, but I can't think of any adjective for this mess other than just "bad". That's some truly industrial grade slop, and I hope whoever worked on that got paid handsomely for it.

It is quite shocking how you over generalize one massive codebase of a working product that has been in use for decades to a couple of projects you did with your single human in the loop process while projecting that experience onto every other project that uses ai to write code regardless of scope and scale. I don't understand your train of thought here.
Not sure what's so confusing here.

I don't like the stigma towards AIs and the people who use them, which is what a post titled "TEMU-Fication of software" is ultimately all about. Call me a misanthrope if you want, as some people have done in the past.

Since I don't like it, I go out of my way to post counterexamples whenever I think people are deluding themselves into thinking human work is somehow magically guaranteed to be better. I cited that example specifically so you wouldn't have to take my word for it.

Working product? With this argument, you're basically admitting that it's all fine as long as it works. What does it matter if the database needs a billion special case flags not to fall apart? What does it matter if it's some AI slop? So long as it ships and people get paid, it's all fine.

I mean seriously, would you work on that Oracle thing if they weren't paying you serious money as compensation? You can literally feel the suffering through that person's words. Whoever they are I hope they're doing alright now.

And it is equally shocking to me that people think it's fine to thoughtlessly generalize and dismiss projects that use AI as slop and AI users as incompetent vibecoders.

So I don't think I'm generalizing at all. I'm trying to dismantle people's generalizations. People act like every human programmer is a deeply caring code artisan or something. Reality is far more cruel, of course.

Reality is that this is how a codebase evolves naturally when these requirements are expressed.

Asking an AI to create a database or something similar would not match the difficulty level of adding new features to Oracle.

These flags are needed because your many versions need to be supported combined with many configuration options. This is true no matter if the code is written by humans or AI.

Honestly, you have a fair and balanced point here, I agree