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.
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.
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.
> 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 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!"
> 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.
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.
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.
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.
> 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 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.
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.
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.