It's often a sign of poor separation of concerns. Tight coupling and low cohesion.

On a good codebase with microservices, this should happen on rare occasions, but not every single time you add a new feature. Been there. Agreed those are particularly hard to work with using AI.

It's a very different experience with a messy codebase. In this case, the agent spends most of its time trying to gather the relevant context and it's like a game of whac-a-mole. The agent burns through tokens and can take a long time to resolve the issue with a lot of human intervention required. I would say it takes possibly just as long or longer than a human engineer would. Also, psychologically, the temptation for the engineer to trust the AI is massive because they don't want to load themselves up with all that ugly, complex context. They are more likely to let the agent create more hacks on top.

On a relatively well-structured codebase with loose coupling and high cohesion, the experience is usually very positive, mind-blowing, even; because it feels like the agent is reading your mind and fast-forwarding you. You don't need to correct it as much. And when you do, it's usually minor things.

The first case represents a net loss of value because tech debt is being added and compounding the complexity each time a problem is 'solved'. On the other hand, the second case is a significant speedup, for me, I would say it's at least a 5x speedup. I love using AI in this way. I'm in control and not at the mercy of the agent.

It's interesting that AI is finally forcing businesses to think about coding maintenance costs though.

When I started working on https://saasufy.com/ as a dev tool many years ago, I was frustrated that no big company cared about software maintenance costs and I really couldn't imagine a world where maintenance costs would be a problem (which is what my platform was addressing). So this is one positive thing from my perspective, I guess. But how much longer before people put 2-and-2 together and realize that architectural complexity is the leading cause? That's the real moment I'm still waiting for.

Will what's left of the socio-economic system be sufficiently capitalist that I will be able to capitalize on that? That's my next problem.

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.

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.

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.

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.

It does feel like everything is a scam nowadays though. All the numbers seem fake; whether it's number of users, number of likes, number of stars, amount of money, number of re-tweets, number of shares issued, market cap... Maybe it's time we focus on qualitative metrics instead?

- LLMs trained on OUR copyrighted works and OUR open source code which was licensed for human use (MIT license explicitly says for "Persons").

- A monetary system that has been centralizing opportunities and creating an asymmetric playing field due to the Cantillon Effect caused by government and institutional money creation.

Either of these points on its own entitles us to as much UBI money as we need.

I think even without AI or any technological progress, the monetary system is itself enough to create the kind of massive centralization that we've been seeing. People have been saying that for years before LLMs. People are now blaming AI for the fact that some people can't get jobs but it's not the root cause.

Software devs won't be able to get jobs as plumbers either because the plumbing sector in many countries has become insanely regulated... Society has been fundamentally corrupted.

I only see two ways forwards;

- Communism with UBI (closer to what we have now)

- Abolish all regulations and have Capitalism again.

Like for complex bugs in messy projects, it can get stuck and waste thousands of tokens but if your code is clean and you're just building out features. It's basically bug free, first shot. The bugs are more like missing edge cases but it can fix those quickly.

It's crazy how good coding agents have become. Sometimes I barely even need to read the code because it's so reliable and I've developed a kind of sense for when I can trust it.

It boggles my mind how accurate it is when you give it the full necessary context. It's more accurate than any living being could possibly be. It's like it's pulling the optimal code directly from the fabric of the universe.

It's kind of scary to think that there might be AI as capable as this applied to things besides next token prediction... Such AI could probably exert an extreme degree of control over society and over individual minds.

I understand why people think we live in a simulation. It feels like the capability is there.