AI Development with Quality and Awareness
Why AI agents are a tool — not a silver bullet
AI can now support a large part of the development workflow, if not carry it out entirely. On top of that, applications no longer have to be built exclusively by (experienced) developers: with the right AI agents, almost anyone can do it. With the right prompts or agents, test cases even fall out from the very start (verified and extended on every change), the code is analysed statically and of course compiled, and a security check is run afterwards. So quality is sustainably taken care of, right? One could even argue that such an AI agent produces better results than most junior developers — and many times faster, too. From that it follows almost automatically that from now on we have to lean heavily on AI in order to stay competitive.
But if we take a step back, we may see that there has to be a middle path between “let only the agents work” and “better use no AI at all.” Let’s look at that together in detail.
The junior trap
That many AI agents focused on software development write better code than junior developers — and need far less time to do it — can almost be taken as a given. But every professional software development effort needs someone who reviews the code produced and, where necessary, checks it against particular functional or technical requirements — senior developers come into play here. There has to be someone — and I mean an actual human — who keeps an overview of the project (from a technical perspective) and is allowed and able to make technical decisions. Ultimately someone has to take, or be able to take, technical responsibility for the implementation, and from today’s vantage point it is still hard to shift that responsibility onto an AI agent (though that too may come).
We were just in the middle of letting AI agents do the work of our junior developers (because it’s faster and probably better). But that brings consequences that we at least have to consider:
- Senior developers have to review and assess more code than without AI support (because the output of the AI agents is far higher).
- The role of the junior developer, as it has been lived so far, could become obsolete as a result.
- Without those junior developers — who invested a lot of time in the many and ever-growing aspects of software development and had to solve countless problems — there can be no senior developers in the future.
- But if there are (at least) fewer senior developers in the future, who then reviews the code and ultimately takes technical responsibility?
That sketches the worst-case scenario, of course, but a lot currently suggests that this direction is being taken, at least in part.
Who tests the tester?
“How could that bug make it all the way into production — we have a unit test for it, don’t we?” Hands up, who has never found a unit test that was implemented incorrectly or did not (fully) implement the checks that were actually needed? A unit test has to do one thing before it can even be a good unit test: it has to fail once! Only when you have verified that the implemented unit test actually fires in the failure case can you be reasonably certain it will also fire on an actual malfunction of the tested functionality. A test case that is “green” from the outset tells you exactly nothing.
That’s where the review — or, in test design, the “four-eyes principle” — comes into play again: test cases have to be quality-assured as well! As always, a risk-based approach makes good sense here (as almost always in QA). You probably won’t peer-review every test case, but the essential ones have to be checked. AI can, if steered correctly, create and run many — and of course good — test cases in a fully automated way, but I wouldn’t rely on that without also reviewing the test cases critically. Here too there have to be professionally and technically well-trained human staff who take on these tasks now and in the future.
Human oversight
The EU AI Act (Article 14) mandates human oversight for high-risk systems. Now one can of course argue that not every system has to be classified as high-risk, and that this mandated rule therefore doesn’t always apply — fair enough, again a very clear risk-based approach. And yes: if I vibe-code my own little app, I’ll put much less emphasis on code quality and test coverage and can live with any bugs.
But even for non-high-risk systems in a commercial setting, it would be problematic if, due to bugs in production, e.g. personal data were leaked — because (still) it is the company and its management that are liable in such incidents, not the AI that (perhaps) wrote most of the code of these systems.
The “social media” pressure
When you see, hear or read posts about AI on “social media,” you certainly get the impression that this technology is infallible: frameworks, applications and entire SaaS platforms are conjured up in a matter of hours or days. Just recently I saw yet another post in which a developer claimed that his AI agent, while he himself slept, had built an application (in just 2 or 3 hours) that would have taken a developer several days. What he doesn’t tell you is how much time he spent analysing and refactoring the code, and which features were implemented inadequately or not at all. And understandably, this builds pressure on companies: “Everyone else is now obviously so much faster with AI, so we have to keep up.” And which activities can and always could be cut? Correct: quality! In the form of poor UX, lousy performance or outright bugs — which then, of course, have to be fixed by and with AI again, because nobody took the time to get an overview of the codebase.
AI: the “silver bullet”?
Who still remembers the 2000s, when UI test automation (back then with Mercury WinRunner) emerged and everyone started automating their tests like crazy? Thanks to “capture/replay,” the business side could pitch in diligently too (or so the Mercury advertising claimed) — the “silver bullet” to solve all quality problems in one blow! Endless time and resources then flowed into building and maintaining such automated test-case portfolios, and it took several years before many companies had to realise that UI test automation does of course add value, but only when used in a targeted, measured way and as a complement to many other testing activities — and that it is by no means the “silver bullet” it was once made out to be.
So how should we deal with AI?
In my view, you have to see AI as a tool: tools have always improved, and thereby significantly changed, productivity, quality and the way we work. In recent years we have been handed a new tool that we first have to learn to use correctly. But we developers, testers, and people in general are still the ones who use this tool and who are — or should be — responsible for the result! Statements like “the AI said so” or “no idea what the code actually does, but it works” simply have no place in professional software development, not now and not in the future either! Software development is and remains an immensely demanding craft, carried out by well-trained and experienced craftspeople.
At rzfz.ai, we will of course use this new tool in a targeted way and increase our efficiency with it — but we won’t throw our core values overboard in the process: we build high-quality, performant, secure, usable and tested products. We know our codebase and take responsibility.
Source: EU AI Act — eur-lex.europa.eu
Published in QualityNews H1/2026