But it’s pretty clear that most people are not. For whatever reasons (mgmt pressure, trying to get ahead, skill issues, etc) they half ass it, accept the 10% (silent) fail rate and blame the bad outcomes on the AI as if that absolves them. Or, adopt the attitude that 10% fail is fine, and people who say otherwise are being picky, or are anti-ai luddites or whatever. You should accept that things will suck.

I have definitely seen more bafflingly-poor OSS software that just plain doesn't work frequently now than before.

But it's mostly software that wouldn't have existed before because it's trying to do super-niche things. So on the "hobby" side of things, whatever.

But from a "trying to develop software as a business that you want to be a going concern," quality from people who should know better is less tenable than it used to be.

Yes but that's the big thing, now isn't it? These are nice tools, used wisely. But their unwise use, oh boy...

The problem is one needs to be in a situation where the incentive is towards quality rather than speed. But that situation rather rare now - thirty years ago, Microsoft won the office wars with crap that had features. And nothing has fundamentally changed in web development since the LPad crisis.

The problem is those companies whose incentive is to allow bugs where it's the involuntary users who suffer will bite you no matter what quality you make your own software.

There's definitely still AI/LLM integration happening, but is kept out of specific areas of the business.

Manufacturing lines have tight tolerances. Science has 95% confidence intervals (or greater). HFT has fractional pennies to steamroll up. But “business” (broadly), leadership, macro decisions 3+ steps removed from the coal face can safely operate at wider tolerances.

I cringe whenever I see “xx.xx% growth” on a report as if the value in that hundredth of a percent place is going to sway anyone’s opinion one way or the other. It’s superfluous, wasteful and I would argue, harmful.

The U.S. Marines teach the “70% solution” which says that making a decision that is 70% correct now is better than making a 100% correct decision later.

The speed of your OODA loops is critically important, and cannot be overlooked or expensed in favor of determinism, predictability etc for its own sake. (After all “no plan survives first contact”)

The main argument for LLM-driven development is much simpler: "It will get better".

The current state of LLM coding is about a year old. Imagine if we dismissed human coding efforts after a year. Rust, Python2 -> Python3 transition, Python type checking, Windows, C++, … nothing of that was done in a year and emerged in perfection in the first year. Everything takes ages to mature into a usable product. LLM coding is still in the "throw mud at the wall and see what sticks" stage, give it some more years and see how it will develop and what approaches actually work at. For the time being, LLMs are just the most useful development tool in the history of development tools, that's a pretty solid start in such a short time.

The point is that it boils down to writing the tests correctly, regardless of who is implementing the actual code. Hand-written code without test coverage has the same problems as AI generated code.

One can be simultaneously a developer and a user. Distributed systems [0] weren't invented five years ago, after all. ;)

"Github owns this part that we rely on for correct operation and we can do fuckall about it when it fails." is a well-defined ownership model.

[0] ...implying the existence of distinct parts that can be independently developed and independently fail...