“Software is degrading for obvious reasons” is just painfully lazy. Where are the metrics of degradation? Where are the claims of specific reasons, and the evidence of causality?

If the complaint is vibe coding makes bad software, I largely believe it, but I absolutely believe that vibe arguing makes tissue paper arguments. “Everyone knows” and “it’s obvious” are flimsy things to rest arguments on.

I’m writing dramatically better software for all the reasons this post says obviously make worse software.

Testing has gotten much easier, and bug fixing has gotten much easier. I looked at a pre-AI project I did a couple of years ago: test to code LOC was 0.15:1. The projects I work on now are around 1.3:1. The old project had no accessibility considered at all, the new ones are nicely done aria and beyond. Old project is stuck on old libraries because upgrading is a major pain. New projects take new libraries (after cooldown) no matter the effort.

So I’m left thinking that perhaps some people, too lazy to use the new powers of new tools, churn out the same or worse quality code/essays.

But I am seeing a lot of very high quality software that simply wouldn’t have been possible before, and I believe the same could be done with essays by leveraging these tools to research and find real data beyond “it’s obvious”. But that does take a lot more work.

> “Software is degrading for obvious reasons” is just painfully lazy.

Not nice to call the author lazy when they've linked to the reasons and even made a youtube video about it. https://www.bitlog.com/2026/05/19/why-are-we-getting-worse-a...

There is plenty of evidence. For example:

https://www.youtube.com/watch?v=MR4i3Ho9zZY&t=37s

The reason is clear - without scarcity of compute or memory, performance is no longer a feature. That works until all the laziness compounds into a crawling bloat.

This is regarding desktop software. With services, microservices is basically a performance anti-pattern that is used without any due diligence in most cases.

> I looked at a pre-AI project I did a couple of years ago: test to code LOC was 0.15:1. The projects I work on now are around 1.3:1.

Lines of code is a poor metric for measuring, both for application code and testing code

> I looked at a pre-AI project I did a couple of years ago: test to code LOC was 0.15:1. The projects I work on now are around 1.3:1.

Goodhart's law etc.

> But I am seeing a lot of very high quality software that simply wouldn’t have been possible before

Personally, I haven't seen too much of that. What I've seen is software that _looks_ pretty, has a shiny interface, a well-designed animated website made with god knows what, but under the hood it's a bit of an alpha mess....

Dawg, you clearly haven't used any consumer-grade software in the past 5 years. Everything across the board is a worse experience and there in some cases are limitations that make no sense. Use any app such as Spotify or Uber Eats, its a worse experience than it was 5 years ago, hands down. Everyone outside of our bubble knows it.

When your software crashes and doesn't do what it's told I will think back on the thousands of bullshit tests Claude wrote and feel less bummed out about it. (Maybe.)

Test cases doesn't mean shit works. It means test cases pass.

About 50% of the test cases I've ever seen are pointless.

> But I am seeing a lot of very high quality software that simply wouldn’t have been possible before

cite 1