This. The core problem is that people assume that all software is necessarily unreliable.
The fact is because they themselves are not capable of producing perfectly reliable software, they assume that everyone else is the same. With this narrow-minded worldview, you would expect software to require constant updates as the maintainer is essentially playing a never-ending game of whac-a-mole.
Not all technologies change. Often, low-level engine APIs are very stable and essentially never change... So why should the software built on top change?
According to OP, the kind of reliable software that we need in the AI slop era would fall in the category of 'dead project'. So they are doomed to create AI slop on top of other AI slop. Good luck to them.
Preventing these kinds of concurrency issues is exactly why I built https://socketcluster.io years ago. Though it solves the problem at the app layer rather than the storage layer.
But not many developers care about these race conditions it seems.
It's not just an issue with SQL but a more general issue with many programming languages and approaches.
This is a great example because it shows how concurrent executions can lead to significant issues.
A no-code platform packaged as an AI tool for building data-driven applications and serving as a data store for AI to tell it interact with your data; https://saasufy.com/ - Tested with Claude Code and pi.
This is why I built https://saasufy.com/ - There are 23 generic HTML components which can be assembled to provide a flexible way to render any kind of data and flexible form elements to flexibly update the data (or show errors when validation fails). It's fully declarative so there is very little room for errors. I find that this helps a lot when working with LLMs. There are no complex bugs. The only kinds of bugs you might encounter are syntax or UX related. No weird race conditions or complex technical issues.
That's why I built https://saasufy.com/ as an agent tool for building data-driven realtime apps.
I started working on it piece by piece about 14 years ago. It was originally targeted at junior developers to provide them the necessary security and scalability guardrails whilst trying to maintain as much flexibility as possible. It's very flexible; most of Saasufy is itself is built using Saasufy. Only the actual user service and orchestration is custom backend code.
Also, I designed it in a way that it would help the user fast-track their learning of important concepts like authentication, access control, schema validation.
It turns out that all of these things that junior devs need are exactly what LLMs need as well.
I tested it with Claude Code originally and got consistently great results. More recently, I tested with https://pi.dev with GPT 5.5 and it seemed to be on par.
I agree with most points in the article but I disagree with the idea of coding as planning. Coding is a really bad way to plan; it maximizes sunk cost fallacy. People tend to code the first approach which came to their heads and they are resistant to revisit an approach once it has been transformed into code. Sometimes ideas which work well in the short term don't work well in the long term.
When you start coding as a way to scope out a problem, you're biasing yourself to think of everything in terms of abstractions which you invented for problems which you don't yet fully understand. My experience is that this distorts your own thinking; you are injecting your own biases into your learning process and locking down on decisions too early due to suck-cost bias.
Having a solution all coded-up and working after a couple of days creates the illusion that you've built something solid and maintainable and that any additional functionality needs to be added on top. Before you know it, the prototype has become the foundation.
It's like if I took you to some random country and told you to build a house and you started chopping wood and putting up the walls straight away. You might immediately have noticed that it's hot so you would put lots of windows... Good... But what you don't know yet is that this country gets hit by powerful cyclones once a year on average and your wooden house won't survive the first one. You started with the wrong material. It might work really well for the first few months until a point when it won't work at all and you'll have to rebuild the entire thing from scratch.
Code was never the scarce resource. Your neighbors' nephew could code a working website that would service the corner shops needs since ten years ago.
The value is and always will be the support and community behind the code.
HN isn't valuable because of a code repo, but because of the community of users and a steady hand cultivating the continued participation thereof. But this too has no real moat, something could change the zeitgeist and tomorrow it joins friendster and TheGlobe.com
Virtual machines are the wrong abstraction. Anyone who has worked with startups knows that average developers cannot produce secure code. If average developers are incapable of producing secure code, why would average non-technical vibe-coders be able to? They don't know what questions to ask. There's no way vibe coders can produce secure backend software with or without AI. The average software that AI is trained on is insecure. If the LLM sees a massive pile of fugly vibe-coded spaghetti and you tell it "Make it secure please", it will turn into a game of Whac-a-Mole. Patch a vulnerability and two new ones appear. IMO, the right solution is to not allow vibe-coders to access the backend. It is beyond their capabilities to keep it secure, reliable and scalable, so don't make it their responsibility. I refuse to operate a platform where a non-technical user is "empowered" to build their own backend from scratch. It's too easy to blame the user for building insecure software. But IMO, as a platform provider, if you know that your target users don't have the capability to produce secure software, it's your fault; you're selling them footguns.
Sounds like they got sick of if after working on it so much. It's really frustrating and tiring when you get everything essentially right but it doesn't work out because of slightly off timing or for some absurdly complex set of reasons that you can never pin down. That's the recipe for burnout.
(1) Tried to bring back the old symbolic AI in 2010s on my own account but people kept knocking down my door because they needed help with one or another neural net. I got an autoencoder in front of customers as part of a highly successful product.
(2) Worked for a startup trying to teach RNNs to read clinical notes; people typecast me as the idealist but I would have preferred the cynical business plan of a product for medical offices to "rebill" insurance to maximize revenue, like the value is clear and nobody dies if it screws up.
(3) Worked at another startup that was training CNNs to read all sorts of documents and datasets you see in corporate environments. That summer I had a methodology I called "predictive evaluation" and a sheaf full of notes that proved that variations of the system we had wasn't really going to work (but they did get it to work enough for one at least one customer) and there was that meeting when we talked about BERT and I said "that seems to avoid all my objections" but the team was through with developing new models and my methodology would have underestimated what BERT could do because it didn't give credit for getting the right answer by the wrong method! Turned out transformers also fixed problems those RNNs had too!
I don't mind AI. What I don't like is the complete saturation of communication channels with the same mainstream ideas and products over and over. This started long before AI slop.
Yep. Then you run into the issue of where to store the secret encryption key.
Security researchers always need to give an answer whenever there's a security incident and the answer can never be "too much centralization risk" even when that is the only reasonable answer. You can't remove centralization risk.
IMO, the future is; every major centralized platform will be insecure in perpetuity and nothing can be done about it.
The fact is because they themselves are not capable of producing perfectly reliable software, they assume that everyone else is the same. With this narrow-minded worldview, you would expect software to require constant updates as the maintainer is essentially playing a never-ending game of whac-a-mole.
Not all technologies change. Often, low-level engine APIs are very stable and essentially never change... So why should the software built on top change?
According to OP, the kind of reliable software that we need in the AI slop era would fall in the category of 'dead project'. So they are doomed to create AI slop on top of other AI slop. Good luck to them.
reply