Nothing Works and Everyone Is Euphoric: The AI-Driven Software Decay

These tools combined with silicon valley motto of moving fast and breaking stuff fast created the perfect storm

> They have raised upper management’s expectations for team output.

That is the worse part, it's not great at all dealing with this kind of expectations

You can build software fast, but the more time you take the more you can be confident about it being correct.

This was true already before AI code generation, but AI code generation means the definition of “fast” has shifted like crazy. An experienced engineer can now build in an hour what would have taken them a week.

But it (right now) does nothing for the confidence about being correct - you still have to put in the extra time to ensure the software is correct to your desired degree of confidence.

Unfortunately for people who like their software to be correct (stable, performant, bug free, etc), it seems like way too many software developers right now are happy to take the gains of the former but ignore the tradeoffs of the latter.

(at the same time software quality for mainstream consumer goods like the kind of thing OP complains about in their post has been down the drain for a long time now, and it seems likely many of the examples they give are pre-AI)

Software quality is tied to the market incentives and always has been. AI isn’t going to make someone care about writing robust software and that is why we don’t see better software all of a sudden. The market doesn’t rewards apps that don’t break on every update, it doesn’t reward cobbling together multiple independent solutions, as opposed to using Microsoft as a one stop shop. If people could have gotten away with this in the early days of computing they would have, but computers were too low powered, and the knowledge too scarce.

There is a saying

Any idiot can build a bridge that stands, but it takes an engineer to build a bridge that barely stands

We found the limits of what it takes to make software stand, and what software paper cuts people are willing to deal with

> I opened Slack on macOS, the icon kept bouncing in the dock for a few seconds. I got impatient, switched to Ghostty, and started typing. Just then, the Slack window appeared, stole focus from Ghostty and the git pull command was sent to the group chat.

One of my absolute favourite features on KDE Plasma with Wayland is the global setting to control what can steal focus. It works wonderfully, and I always miss it when I have to use my work mac or windows computers.

See here for docs, under "Focus stealing prevention" - https://docs.kde.org/trunk_kf6/en/kwin/kcontrol/windowbehavi...

> I opened Slack on macOS, the icon kept bouncing in the dock for a few seconds. I got impatient, switched to Ghostty, and started typing. Just then, the Slack window appeared, stole focus from Ghostty and the git pull command was sent to the group chat.

I still don't understand how a full focus stealability debounce is not the norm. If I am in the middle of writing, or interacting with one UI bit in any way, no other app should be able to steal focus, full stop. Add an annoying popup if you want, make angry computer noises, flash icons, I don't care. 99.9, if not 100% of the time, it's completely unrelated to what I'm doing and can absolutely wait. While some OSs have something along these lines, they also give the tools to bypass it (I'm looking at you, Cisco AnyConnect! Being connected after clicking on connect is not an emergency!)

Imagine you're working in a terminal and an app decides to steal STDIN. Why do we accept that for a GUI?

For me, the problem was never the writing of the code. Building something takes care and rigor. Software development got where it is through years of accumulated practice: habits first, then safeguards, then structures that had actually been proven. Now people set the code aside and just describe their problem, and they have no real sense of what comes back, because nobody can review output produced that fast. Nobody is even keeping up with the systems we built to help us keep up. So we ship without quite knowing what we shipped, and the sloppiness follows from that.

Isn't that how it's gone before, though? People used to make beautiful furniture by hand and leave something of themselves in it. Now it comes out of a factory, nobody knows exactly which part they made, they just fit pieces together, and it isn't built to last. Software is at that same point: nobody knows exactly what they've made or how. They describe the problem, assume they've found the solution, ship it, and there is no undoing it. The sloppiness will keep compounding. But that is also the point where people start thinking much harder about how to make it good again. A cycle, I suppose.

> If coding has been solved, why does software keep getting worse?

Because the premise that coding has been solved is false. :-)

I agree that software becoming worse (in some sense) but I don't blame AI.

My experiences as a user haven't really changed. Streamers fail to cast to TVs. Browsers are devices which reliably and efficiently propagate red console text and 500s from companies to you. I still see bluescreens on public touchscreens.

Uncle Bob nailed one reason why the industry isn't getting better: the growth of programmers is exponential, such that half of all programmers have less than n years experience (5?).

I offer two additional reasons:

Firstly, you hone your skills doing individual algorithms on a single thread, where it's OK to get it wrong and change it as many times as you like.

When you get a job, you don't even realise you're in a distributed system and the getter/setter model you practiced on is woefully inadequate for interacting with partner systems, cqrs, event-sourcing, auditability, idempotency or whatever else is required.

In short, 10 years of practicing writing for-loops and data-structures will not translate into building a system that customers can access via their phone and multiple tabs of a browser, at the same time as a database schema is being updated.

Secondly, while I don't think there is any realistic alternative to agile development, it seems that nontechnical POs have captured the software lifecycle. 'Focus on happy path only, for the MVP' is how you build buggy software. Good developers can learn that this will guarantee the need for a rewrite in the futur […]

LLMs can't parse the entire codebase at once, understand it, and then make decisions based on that understanding.

The hard part of programming almost is never how ONE function or ONE class works. It's how they all interact in a much larger picture. You can try to mitigate this, but it's a pretty fundamental concept that software is big and just too large for an LLM context window.

Until that's solved, coding has not been 'solved' by '''AI'''. They're useful for greenfield stuff, but new software was always easier to smash out quickly than working on older code.

Plus, it's not like they're building understanding like a person does regardless, even if the context window was somehow enormous.