There are a lot of people now making software for the first time. In many ways it's wonderful. We have to admit however, that the raw volume of bad software has gone up.
We seem to call that bad software slop these days. Well, we seem to call a lot of things slop. You can probably find someone who calls anything within 1000 miles of AI slop but lets reserve the term for "poorly made software".
With that lens, it's not surprising that the volume of slop is up. Making quality software is a difficult task, AI or not. For some products the barrier is 100% in the code being written. Getting the software to work is hard. This might be the kind of software that does real time signals processing or some other complex coding challenge.
For many others, most others even, the barrier is in the complete package. The software works but it just kind of sucks. It might be the way it looks, it might be the way that workflows are strung together. It might also be that the software that was written has very little to do with the problem it was written to solve. The common cure to slop seems to be "develop taste". Personally I hate this kind of advice. It borders on gatekeeping because nobody ever backs up what taste is, let alone how to develop it.
Well here's my theory: You build taste by using the software you create.
This isn't a new idea. In the world of software this has long been called dogfooding. The idea is you eat your own dog food, which in this case is your software. Engineers aren't the best at naming things.
The idea is that you use your product and gain first hand experience in what doesn't work the way you intended. This is distinctly different from testing your own product. You need to be using the product in the same way as your target user. Using it as if someone else wrote it.
As you use the product, you can make the tweaks to improve things. With AI that loop is faster than it's ever been. You can reorder steps, add in explanations and put information where it's most needed.
Doing this for a long time will help you build a familiarity with what good looks like. You might still need to formalize it with some self study but as far as 'taste' goes, I don't know a better way to develop it.
Similar advice exists in other fields. Authors need to write a terrible first book. You need to make a lot of bad YouTube videos before you find your groove. You have to consume what you create and find all the things that are wrong with what you made. Then have the confidence to then take all of those thing and work out how to improve them.
This "use your own product" mentality obviously doesn't work for all software. If I am writing software for fire fighters to help with routing I am not going to start fires and drive to them to test out my algorithm. At the same time, I would almost never recommend someone built that kind of software as their first product.
This is where I think the feeling of "slop" has come about. It's an admirable thing to want to build things to help other people. To do it well though, to really help them, you need to understand both their world, and how to build good software. That takes time, attention and a whole lot of reps.
Without those reps you get slop. Software that exists but doesn't work quite right. People feel that whoever built it "just doesn't get it". It feels lazy as if you're asking your users to do work you should have done yourself.
So to tie this up into advice. Build some things for yourself, software you actually use regularly to learn what's good and what isn't. Pay close attention to what needed changing and try to that less next time. This is the fastest path to improvement. Feedback and repetitions and nothing builds those faster than software you use yourself.