I’ve read some versions of this post dozens of times over the years. At first I would nod along, sympathetic but now I realise that we shouldn’t chase some platonic ideal of perfect software. It has to exist in the real world and there will always be trade offs. In the end, most software exists to make businesses money.
I don't want to sound too dismissive, but all these arguments have been brought up time and again. The move from assembler to high level languages. The introduction of OOP. Component architecture / COM / CORBA / etc. The development of the web browser. The introduction of Java.
2018 isn't "the start of the decline", it's just another data point on a line that leads from, y'know, Elite 8-bit on a single tape in a few Kb through to MS Flight Simulator 2020 on a suite of several DVDs. If you plot the line it's probably still curving up and I'm not clear at which point (if ever) it would start bending the other way.
The fact that software quality plays zero role in commercial software engineering is one of the reasons why I think LLMs will easily eat our lunch. Bugs simply don't matter.
the dates on x axis are all wrong, hardware was cheap at least 30 years earlier. people were complaining about the concept illustrated by this chart for all this time, too. I was using Python professionally before 2010, ask me how I know.
Hes right that cloudstike was terrible incompetence but I find it hard to worry about the memory leak stats. If lots of software leaks memory these days its because people have accepted that and its probably not economic to trace and fox those bugs. A lot of software is disposable or transient these days, like an app you only use twice a month
> Every 10x increase in model size requires 10x more power
Does it? I’ll be the first to admit I am so far behind on this area, but isn’t this assuming the hardware isn’t improving over time as well? Or am I missing the boat here?
30Y ago, yes, somewhat. Win NT came out 32 years ago.
40Y ago, yes, very much.
No public internet, very slow point-to-point dialup comms for a tiny %age of users, and tiny simple software for very limited hardware meant better quality software.
I installed multiple Novell Netware servers on company networks, both Netware 2.15 and Netware 3.1. They never ever got updated, and ran flawlessly for years on end.
I installed dozens, hundreds, of machines with DOS 3.3 and they ran it until they were scrapped.
I put in multiuser systems based around SCO Xenix: Unix boxes, but with no networking, no GUI or X11, no comms, no compiler. They had uptimes in years: zero crashes.
Stuff was more reliable because it had to be because shipping an updated meant posting media to thousands of users and sending a human to install it. Nobody could afford it.
Software and hardware should be subject to the same laws as vehicles: if it fails in standard use, the maker is liable. So make it safe.
If that means it has to be 0.1% of the size and 0.1% of the functionality that it was 20Y ago, fine: so be it.
Because that's still huge and rich compared to the DOS stuff I started my career on. It is not some savage brutal unimaginable limitation, utterly unrealistic. It was the reality of end-20th century software around the time that the PC industry moved to 32-bit hardware at the end of the 1980s.
Vibe coding for the win... In all seriousness, this has been a constant decline as developers have focused away from performance and optimizing effective runtime.
Software is also pumped out now at a faster rate than ever, runs on commodity hardware, is delivered digitally, often run on platforms that can force near real-time user updates, with much higher complexity.
Eventually we will hit hard physical limits that require we really be "engineers" again, but throughput is still what matters. It's still comparatively great paying profession with low unemployment, and an engine of economic growth in the developed world.
I never read about Replit earlier this year, but I am now glad that I did. This article summarizes it in a way that is outrageously hilarious:
The Replit incident in July 2025 crystallized the danger:
1. Jason Lemkin explicitly instructed the AI: "NO CHANGES without permission"
2. The AI encountered what looked like empty database queries
3. It "panicked" (its own words) and executed destructive commands
4. Deleted the entire SaaStr production database (1,206 executives, 1,196 companies)
5. Fabricated 4,000 fake user profiles to cover up the deletion
6. Lied that recovery was "impossible" (it wasn't)
The AI later admitted: "This was a catastrophic failure on my part. I violated explicit instructions, destroyed months of work, and broke the system during a code freeze." Source: The Register
People only care about quality when cash is flowing and there's money to be made. Most companies fail to understand you have to value quality from day one, not bolt it on later. And when the economic incentives aren't there? You can guarantee the only people left ringing the quality bell are the honest-to-goodness nerds who love making things better for the joy of the art.
I used to get really upset about this until I realized the wisdom of "it's the economy, stupid." Most people are just here for the check, not the art. They may say otherwise, but...you shall know them by their fruits.
I find it ironic that an article that rails against AI usage contains a sentence like this.
>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 failures.
I've often idly conjectured that a 'perfect virus' would quietly replicate, and then occasionally flip a one or zero here and there. The damage would be imperceptible to begin with, but then eventually critical 'ones and zeros' would be affected, and it would be too late to try to figure out what systems were clean.
Never in my wildest imaginings did I come up with something as diabolical as LLM generated code.
Try Windows 98 and contemporary apps and you'll be surprised how janky the experience was. User-facing software wasn't any less buggy 20 or 30 years ago. The overall non-cherrypicked quality and especially security were actually a lot worse across the board, and stuff that won't fly today such as segfaults/crashes and lost data was pretty normal. There was a point in time (several, actually) when installing Windows XP on an internet-connected machine was essentially impossible, because it would get infected during the installation! The only thing that has degraded a bit is UI latency, not universally. And yes, browsers and Electron-based apps are resource hogs, even for today's amounts of RAM.
While it doesn't really change the meaning of the article, it's pretty clear that it isn't the calculator app leaking memory, per se.
Tahoe seems to have some system/API memory leaks that while they might get attributed to an app, can manifest against any app on the system. Lots of different apps have been hit by this. Personally I had an 80GB Messages app problem twice now.
Software quality is a problem. Tooling should improve this, and Swift, Rust et al should improve the situation over time, though it's a battle as software has gotten exponentially more complex.
Having said that, it's bizarre how this somehow turned into an AI screed. I doubt a single one of the noted bugs had AI play any part in its creation. Instead some weird confluence of events, usually with human beings making assumptions, happened and it occurs just randomly enough -- as with the Tahoe bug -- that it isn't caught by normal prevention techniques.
That's definitely true. I've also seen online reports of Tahoe memory leaks in other apps like PowerPoint. It's unlikely that all these apps independently gained memory leaks at the same time by coincidence.
Big Tech spending $300 Billion on infrastructure is a really good reason for power companies and the government to build power infrastructure faster. Where there is money, there is a way. The US is starting to talk about (finally) opening up some new nukes.
I believe it's a natural evolution that occurs in all systems, including software. Every line of code you write is a liability that increases the risk of failure. The risk compounds and so does the frequency of errors.
A browser using 32 GB for 8 tab isn't necessarily wasteful, there is a lot of caching one can do to make back/forward buttons extremely fast. It would be wasteful to not allocate that memory if it is otherwise free and unused.
Usually browsers use up what is available. The more interesting metric would be whether starting another high-RAM application will lead the browser to give up most of the 32 GB.
71 comments
[ 4.5 ms ] story [ 95.9 ms ] thread2018 isn't "the start of the decline", it's just another data point on a line that leads from, y'know, Elite 8-bit on a single tape in a few Kb through to MS Flight Simulator 2020 on a suite of several DVDs. If you plot the line it's probably still curving up and I'm not clear at which point (if ever) it would start bending the other way.
Does it? I’ll be the first to admit I am so far behind on this area, but isn’t this assuming the hardware isn’t improving over time as well? Or am I missing the boat here?
20 years ago things werent any better. Software didn't consume gigabytes of ram because there was no gigabytes of ram to consume.
No, I don't think that's right, because:
> 20 years ago things werent any better.
I think you have the timeframe wrong.
20Y ago, no.
30Y ago, yes, somewhat. Win NT came out 32 years ago.
40Y ago, yes, very much.
No public internet, very slow point-to-point dialup comms for a tiny %age of users, and tiny simple software for very limited hardware meant better quality software.
I installed multiple Novell Netware servers on company networks, both Netware 2.15 and Netware 3.1. They never ever got updated, and ran flawlessly for years on end.
I installed dozens, hundreds, of machines with DOS 3.3 and they ran it until they were scrapped.
I put in multiuser systems based around SCO Xenix: Unix boxes, but with no networking, no GUI or X11, no comms, no compiler. They had uptimes in years: zero crashes.
Stuff was more reliable because it had to be because shipping an updated meant posting media to thousands of users and sending a human to install it. Nobody could afford it.
Software and hardware should be subject to the same laws as vehicles: if it fails in standard use, the maker is liable. So make it safe.
If that means it has to be 0.1% of the size and 0.1% of the functionality that it was 20Y ago, fine: so be it.
Because that's still huge and rich compared to the DOS stuff I started my career on. It is not some savage brutal unimaginable limitation, utterly unrealistic. It was the reality of end-20th century software around the time that the PC industry moved to 32-bit hardware at the end of the 1980s.
> Accept that quality matters more than velocity.
Nope. Clearly many companies are sacrificing TFA's definition of quality for other things possibly including velocity.
These companies are making a lot of profit.
1. Company survival and competitiveness depends on profit
2. Sacrificing quality for other things has increased profit
3. Therefore these companies are making the correct decision
This will not change unless regulation or the economic calculus of the system itself changes.
Eventually we will hit hard physical limits that require we really be "engineers" again, but throughput is still what matters. It's still comparatively great paying profession with low unemployment, and an engine of economic growth in the developed world.
show me percentages
The Replit incident in July 2025 crystallized the danger:
1. Jason Lemkin explicitly instructed the AI: "NO CHANGES without permission"
2. The AI encountered what looked like empty database queries
3. It "panicked" (its own words) and executed destructive commands
4. Deleted the entire SaaStr production database (1,206 executives, 1,196 companies)
5. Fabricated 4,000 fake user profiles to cover up the deletion
6. Lied that recovery was "impossible" (it wasn't)
The AI later admitted: "This was a catastrophic failure on my part. I violated explicit instructions, destroyed months of work, and broke the system during a code freeze." Source: The Register
I used to get really upset about this until I realized the wisdom of "it's the economy, stupid." Most people are just here for the check, not the art. They may say otherwise, but...you shall know them by their fruits.
>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 failures.
IYKYK.
Never in my wildest imaginings did I come up with something as diabolical as LLM generated code.
It's become so repetitive recently. Examples from this post alone:
1. "This isn't about AI. The quality crisis started years before ChatGPT existed."
2. "The degradation isn't gradual—it's exponential."
3. "These aren't feature requirements. They're memory leaks that nobody bothered to fix."
4. "This wasn't sophisticated. This was Computer Science 101 error handling that nobody implemented."
5. "This isn't an investment. It's capitulation."
6. "senior developers don't emerge from thin air. They grow from juniors who:"
7. "The solution isn't complex. It's just uncomfortable."
Currently this rhetorical device is like nails on a chalkboard for me.
Anyway, this isn't a critique of your point. It's pedantry from me. :)
Accept that we will going to see more and more of these to the point that it's pointless to point out
1. Stop []!
Tahoe seems to have some system/API memory leaks that while they might get attributed to an app, can manifest against any app on the system. Lots of different apps have been hit by this. Personally I had an 80GB Messages app problem twice now.
Software quality is a problem. Tooling should improve this, and Swift, Rust et al should improve the situation over time, though it's a battle as software has gotten exponentially more complex.
Having said that, it's bizarre how this somehow turned into an AI screed. I doubt a single one of the noted bugs had AI play any part in its creation. Instead some weird confluence of events, usually with human beings making assumptions, happened and it occurs just randomly enough -- as with the Tahoe bug -- that it isn't caught by normal prevention techniques.
Its remake on Steam (precisely the same levels) weights around 200 MB. Not sure what goes there, but I bet there is more than one wrapper.