The Great Software Quality Collapse: How We Normalized Catastrophe

[1_rick]

https://techtrenches.substack.com/p/the-great-software-quality-collapse

The Apple Calculator leaked 32GB of RAM.

Not used. Not allocated. Leaked. A basic calculator app is hemorrhaging more memory than most computers had a decade ago.

Twenty years ago, this would have triggered emergency patches and post-mortems. Today, it's just another bug report in the queue.

We've normalized software catastrophes to the point where a Calculator leaking 32GB of RAM barely makes the news. This isn't about AI. The quality crisis started years before ChatGPT existed. AI just weaponized existing incompetence.

Some examples are given, then:

But the real pattern is more disturbing. Our research found:

AI-generated code contains 322% more security vulnerabilities

45% of all AI-generated code has exploitable flaws

Junior developers using AI cause damage 4x faster than without it

70% of hiring managers trust AI output more than junior developer code

We've created a perfect storm: tools that amplify incompetence, used by developers who can't evaluate the output, reviewed by managers who trust the machine more than their people.

 

[1_rick]

I forgot to quote this, which may be relevant to some here:

The Pipeline Crisis Nobody Wants to Acknowledge
​

Here's the most devastating long-term consequence: we're eliminating the junior developer pipeline.

Companies are replacing junior positions with AI tools, but senior developers don't emerge from thin air. They grow from juniors who:

• Debug production crashes at 2 AM
• Learn why that "clever" optimization breaks everything
• Understand system architecture by building it wrong first
• Develop intuition through thousands of small failures

Without juniors gaining real experience, where will the next generation of senior engineers come from? AI can't learn from its mistakes—it doesn't understand why something failed. It just pattern-matches from training data.

We're creating a lost generation of developers who can prompt but can't debug, who can generate but can't architect, who can ship but can't maintain.

The math is simple: No juniors today = No seniors tomorrow = No one to fix what AI breaks.

 

[LukeTbk]

View: https://youtu.be/pW-SOdj4Kkk?t=1094

I think the article is a bit all over the place, datacenter are the opposite of large abstraction stack or a place where memory leak are seen as normal, the race at optimizing per watt at the lowest level of the hardware is extremelly aggressive in that space I feel like (and there is no link between them an the calculator memory leaks).

If we look at how often youtube or netflix or amazon website goes down and what they do per watt, I am not sure that the kinds of place we would say code got bad. Netflix was up 99.999+% of 2024, 15 minutes of issue in the whole year and the double their energy efficay every 36 month or so, they are now counting a stream in low amount of milliwatts.

Also no a single person accept that a calculator leaking to all available memory is normal, that such a strange premise, it did make the "news".

 

[sfsuphysics]

It's not a bug it's a feature... one that will make Apple money for every 8GB of memory you add is another $200, so just get above that 32GB mark and you're set!

 

[Armenius]

1 exabyte should be plenty, right?

 

[Prince Valiant]

Could probably move the timeline back several years, if not more.

 

[1_rick]

I think the article is a bit all over the place

He's mostly talking about desktop, not datacenter, by the way he talks about client apps like calculators. But he's also not wrong about multiple layers of abstractions causing their own problems. I would look at that like this decade's version of bufferbloat.

 

[LukeTbk]

He's mostly talking about desktop, not datacenter, by the way he talks about client apps like calculators. But he's also not wrong about multiple layers of abstractions causing their own problems. I would look at that like this decade's version of bufferbloat.

The $364 Billion Non-Solution
​

Instead of addressing fundamental quality issues, Big Tech has chosen the most expensive possible response: throw money at infrastructure.

This year alone:

• Microsoft: $89 billion
• Amazon: $100 billion
• Google: $85 billion
• Meta: $72 billion

They're spending 30% of revenue on infrastructure (historically 12.5%). Meanwhile, cloud revenue growth is slowing.

This isn't an investment. It's capitulation.

When you need $364 billion in hardware to run software that should work on existing machines, you're not scaling—you're compensating for fundamental engineering failure

I think he is clearly saying (and most of the article) is about the software running in datacenter being not optimized.

And this part ?:
Today’s real chain: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways.
Each layer adds “only 20–30%.” Compound a handful and you’re at 2–6× overhead for the same behavior.

That's how a Calculator ends up leaking 32GB. Not because someone wanted it to—but because nobody noticed the cumulative cost until users started complaining.

What is happening the "calculator" end up leaking infitne (people with 256 gb saw 170+), there is no VM, no chromium, no react involved, it is a pure native macOS (SwitfUI-macos windows server issue) binary without container/docker, he is talking about the common modern development hell using an anecdote that has nothing to do with it, it is clearly due to a memory leak (which can happen on a raw 200 line of assembly code), not to a very heavy level of abstraction that made ram usage growth and growth.

 

[Ihaveworms]

Quite writing desktop apps in electron. It's "easier", but so bloated.

 

[paradoxical]

The $364 Billion Non-Solution​

​

Instead of addressing fundamental quality issues, Big Tech has chosen the most expensive possible response: throw money at infrastructure.

This year alone:

• Microsoft: $89 billion
• Amazon: $100 billion
• Google: $85 billion
• Meta: $72 billion

They're spending 30% of revenue on infrastructure (historically 12.5%). Meanwhile, cloud revenue growth is slowing.

This isn't an investment. It's capitulation.

When you need $364 billion in hardware to run software that should work on existing machines, you're not scaling—you're compensating for fundamental engineering failure

I think he is clearly saying (and most of the article) is about the software running in datacenter being not optimized.

And this part ?:
Today’s real chain: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways.
Each layer adds “only 20–30%.” Compound a handful and you’re at 2–6× overhead for the same behavior.

That's how a Calculator ends up leaking 32GB. Not because someone wanted it to—but because nobody noticed the cumulative cost until users started complaining.

What is happening the "calculator" end up leaking infitne (people with 256 gb saw 170+), there is no VM, no chromium, no react involved, it is a pure native macOS (SwitfUI-macos windows server issue) binary without container/docker, he is talking about the common modern development hell using an anecdote that has nothing to do with it, it is clearly due to a memory leak (which can happen on a raw 200 line of assembly code), not to a very heavy level of abstraction that made ram usage growth and growth.

I don't take criticisms of AI seriously that are obviously written by AI.

"It's not this, it's that."
"And this part?"
"Here's the closer - with an emdash."

 

[cageymaru]

More backdoors for the script kiddies to exploit and governments to track your every movement.

The more you rely on technology, the less you learn to live on your own.

 

[Ididar]

I forgot to quote this, which may be relevant to some here:

It isn't just software developers but people in multiple industries. As they wipe out tons of junior positions and get the senior folks to do the "grunt work" using software to replace warm bodies they're guaranteeing that there will be no senior people in a decade or two. But, they don't care because they'll be retired on their own personal island by then. They'll have their money made and if shit starts falling apart then it isn't a big concern of theirs. Businesses used to be good at this sort of long term planning but since the stock price took over all business planning nobody cares about the long term anymore. It is all about the quarterly profits driving share price. Will the company still be there in 10 years? They don't care.

 

[DukenukemX]

Decades ago the best software ever made was made with assembly language. Not because assembly was inherently good at making software, but because you had to be good at using it otherwise it won't work. Today we have Hector Martin leave Asahi Linux because he wanted better integration with Rust into the Linux kernel. Again, not a bad language but does kinda make bad coders look good.

 

[LukeTbk]

. Today we have Hector Martin leave Asahi Linux because he wanted better integration with Rust into the Linux kernel. Again, not a bad language but does kinda make bad coders look good.

Not sure what the story in the link as to do with making bad coders look good (or that rust would be a good language for that aim... Rust is on the hard side of learn and use language wise, it can quickly become hard to even compile, it can make medium coder deliver better code by forcing them sure, something like Go is better at getting usable work from bad coder), it just someone venting about code editor indentation and formatting....

Decades ago the best software ever made was made with assembly language. Not because assembly was inherently good at making software, but because you had to be good at using it otherwise it won't work

I think it was a lot because of the consequence of using early compiler, using a compiler meant a slow program, so good program had to be written in assembly and "good" is relative, it could have appeared to be but easily filled with catastrophic error/hole at the same time. Not only because of what it meant regarding who was making them, just as being forced into it.

 

[erek]

this seems relevant,

Are AI Agents Compromised By Design?​ Gadi Evron 3 hours ago

5

Longtime Slashdot reader Gadi Evron writes: Bruce Schneier and Barath Raghavan say agentic AI is already broken at the core. In their IEEE Security & Privacy essay, they argue that AI agents run on untrusted data, use unverified tools, and make decisions in hostile environments. Every part of the OODA loop (observe, orient, decide, act) is open to attack. Prompt injection, data poisoning, and tool misuse corrupt the system from the inside. The model's strength, treating all input as equal, also makes it exploitable. They call this the AI security trilemma: fast, smart, or secure. Pick two. Integrity isn't a feature you bolt on later. It has to be built in from the start. "Computer security has evolved over the decades," the authors wrote. "We addressed availability despite failures through replication and decentralization. We addressed confidentiality despite breaches using authenticated encryption. Now we need to address integrity despite corruption."

 

[philb2]

Bruce Schnier is a highly respected info security analyst.

 

[DukenukemX]

I think it was a lot because of the consequence of using early compiler, using a compiler meant a slow program, so good program had to be written in assembly and "good" is relative, it could have appeared to be but easily filled with catastrophic error/hole at the same time. Not only because of what it meant regarding who was making them, just as being forced into it.

To give you an idea, AES-GCM Crypto Performance Up To ~74% Faster For AMD Zen 3 With Linux 6.19. That patch has 90% hand written assembly language.

 

[Nytegard]

Quite writing desktop apps in electron. It's "easier", but so bloated.

Companies want to save money, and easier languages allow them to hire more people, allowing faster development while at the same time driving down prices, and the public is happy as they get "better" products.

What I mean is, it's sort of like food. Food today is cheaper than it's ever been, tastier/addictive than it's ever been, but also filled with tons of chemicals and other garbage so it's also unhealthier than it's ever been.

When we had super slow computers where people had to use punch cards and assembly, developers had to know their stuff. Even as computers got faster and compilers started to be the norm, they still had to have an understanding of the system, as there were limitations that bound programmers. I remember one of my bosses telling me back in the early 2000s that he was happy that we finally reached a point that we never again would have to worry about efficiency, be it memory or computational speed, as any defect would eventually be compensated by better hardware.

You see programmers coming out of college, they don't understand even the basics of memory management. And who care about Big O Notation when you can brute force things. Even a few projects I've been on lately, there's been a push to move away from C++ to Python, because C++ developers are now becoming harder to find, whereas there is a plethora of Python devs.

And AI is only making development faster and cheaper, but not better.

Even in video games, you're now seeing many indie games take up gigabytes of space where if someone actually spent time writing a custom engine, could make the equivalent game in a few megabytes, while at the same time running at a higher framerate.