Will AI give us better software? It depends on our taste

AI slop isn’t AI’s fault 

We’re seeing more and more “AI slop” online and in the products we use. It’s the text, images, code and apps that go straight from the first prompt to release without a single edit. The results are generic, inaccurate and often don’t work. Some people are even starting to develop an “allergy” to AI-generated content. 

I see this in the apps and services I use myself. Lately, I’ve been running into bugs almost every day, and I regularly report them. Almost every time, support tells me it’ll take longer than usual to reply because they’re handling more requests. Maybe there really are more bugs. Or maybe AI has made bugs easier to report, so people report them more often. 

To be fair, we had bugs long before AI. Making mistakes is human, after all. But AI amplifies the problem. People can now produce far more code than they used to. It’s also opening up software development to people who have no formal IT training or experience working through a problem systematically and looking for what might go wrong. Users pay the price. That’s why we need to keep thinking like quality engineers, even when AI writes the code. 

However, this does not mean that AI is bad. AI is a tool. Slop is a consequence of how we use it: a single prompt, no review, no iteration. The same model can produce mediocre work or excellent work. The difference lies in what we do after the first prompt. 

Where we spend our time has changed 

Implementation used to take up most of the time between having an idea and delivering the finished product, estimated 60 to 80% of the time. We spent the rest of the time refining the result. 

Today, that balance has flipped. Implementation takes a few hours, sometimes just minutes, and we then spend around 80% of our time getting the result right. No one has measured the exact ratio yet, but the data points to a shift. In the Stack Overflow Developer Survey 2025, 66% of developers identified AI solutions that are “almost right, but not quite” as their biggest source of frustration. And according to Faros AI, code reviews took 91% longer in teams with high AI adoption. 

Getting a first version quickly still leaves plenty of work to do. More of that effort now goes into deciding whether the result is good enough. 

Taste is knowing what we’ll settle for 

“Taste” might sound like a matter of aesthetics. It’s also the judgment that lets us recognise when something falls short and put our finger on what’s missing. 

Someone with good taste does not accept the first answer as final. Does the code handle edge cases? Does the test actually verify anything? Is the text right for its audience? They keep refining the result until it meets their standard. Given enough rounds of review and revision, AI can help us produce something better than we could manage on our own. But it will adapt to the bar we set. If we settle for average, that’s what we’ll get. 

Where quality engineers come in 

For testers and quality engineers, quality is part of the job description. They’re used to finding where things break and defining what “done” means. Those habits now shape the results we get from AI. Here’s what they look like in practice. 

1. Give a clear brief. Describe the goal, the context, the constraints and the acceptance criteria, rather than just the task itself. The instructions don’t have to be complete in the very first prompt; we can refine them together with the AI, brainstorm, and let it ask follow-up questions about anything that is unclear or that it needs for its work. 

2. Skills and instructions for agents. First, iterate on the task until you achieve a high-quality result, then document the process as a 'skill.' However, even this is rarely finished on the first attempt; you need to revisit and refine it, ensuring it continues to yield good results even when the context or the model changes. 

3. Use deterministic tools where possible. What a script, for example in Python, can do, an LLM does not have to do. A script produces the same result every time and can be tested. We deploy LLMs where it makes sense: for handling text, context, and ambiguous instructions. 

4. Verification by a different model. Code review should be performed by a different model, ideally one from a different provider. Models tend to rate their own outputs more favorably than those of others, meaning the same model might easily 'approve' its own errors. 

5. A self-improvement loop with external checks. A loop in which an agent reviews and corrects its own output only works if it is backed by tests, acceptance criteria, and human oversight. 

That last point is crucial. When AI keeps revising its own output without an external check, errors can compound. Suppose each of five independent steps has an 80% chance of being correct. The chance of getting all five right is only about one in three (0.8⁵ ≈ 33%). Newer models still need guidance, too. According to the Veracode 2026 GenAI Code Security Report, they produce code with almost no syntax errors, yet without specific security instructions they introduce a vulnerability in roughly 44% of tasks. Although models have improved considerably over the past year, that figure is falling only slowly. 

However, we cannot rely solely on our own eyes. AI can produce code that looks clean and convincing but doesn’t do what it’s supposed to. At other times, it unnecessarily overcomplicates a solution and generates so many changes that a human would simply get lost in them. That is why we need a system of agents that check each other’s work, alongside a human who sets the rules and makes the final call whenever the agents disagree. 

Quality is not determined by AI, but by us 

So, will AI give us better software? It can, but it won’t happen on its own. The model delivers what we ask for, and it stops when we do. 

If we treat the first output as finished, we’ll add more slop to the world. If we keep refining the work, verify the results and build systems that bring out the best in AI, we can produce better software than we could before. A Quality Engineer is no longer just someone who finds errors at the end. He is the one who sets the bar and the system that forces AI to meet it. 

If you would like to learn more about the use of AI in software testing and quality management, please visit the page HERE.