AI is changing how software gets built, and it is changing it fast. Development teams can now ship in days what used to take weeks. If you work in quality assurance, this speed is not a threat to your job. It is a threat to your process, because a QA process designed for the old pace quietly becomes the bottleneck of the new one.
At SABO IT, code quality itself was never the thing that worried me. With experienced developers, code is reviewed by humans and by tools regardless of whether AI helped write it. That part of the pipeline has strong habits and strong guardrails, and it had them long before AI arrived.
The real problem has always been somewhere else: understanding business requirements.
Requirements are usually written by someone with deep business knowledge who does not realize how much of that knowledge lives only in their head. The text makes perfect sense to them. To everyone outside their domain, it is full of gaps and silent assumptions, and those gaps become misunderstandings, and misunderstandings become defects.
This problem brought me to BDD years ago. Gherkin scenarios: behavior written down in a form both business and engineering can read, shared examples instead of ambiguous prose. Those ideas still hold. But when development can move extremely fast, business analysis and test analysis have to keep the same pace, or the whole team is just producing well-tested misunderstandings faster than before.
So I started looking at the bottlenecks in our test process one by one, and asking where AI could genuinely remove work without removing judgment.
A colleague once told me he was surprised our team adopted AI so successfully, because he had always considered me skeptical and mistrustful towards it. I told him he was right; I really don’t trust AI and its outputs. But I also don’t trust developers and their outputs. I would be a poor tester if I took anyone at their word. My job is to verify what is being shipped, and that applies to AI exactly as it applies to people.
To be clear, this is not a rejection of AI; quite the opposite, I see a big opportunity in it. But AI cannot carry responsibility the way a human can, and in QA, responsibility is the product.
That belief became the one hard rule behind everything we built: a human must always be the gatekeeper of any output. AI drafts, reviews, suggests, and formats. It never gets the final word.
With that mindset, we built SaTI (Sabo Tester Intelligence), our internal AI-powered testing platform. Not to replace testers, but to let them spend their time on the parts that need a human brain.
The main flow follows the natural chain of QA work: requirements, test cases, test code.
It starts with the requirement. If you have ever built a feature from a requirement that made sense only to its author, you know how expensive that discovery is when it comes late. So this is where SaTI starts: analysts get an AI-powered review that scores the requirement, asks clarifying questions, and points out ambiguities and missing acceptance criteria before anyone builds on top of it. It is the cheapest place in the whole lifecycle to catch a misunderstanding.
A small real example. In requirement reviews, SaTI raises open questions and points at ambiguities it finds. My testers keep telling me the questions are spot on, good enough that they take them directly to the business analysts and stakeholders, and come back with a better requirement. Notice what happened there: the AI did not resolve anything. It made the right human conversation happen earlier. That is exactly the job I want it to do.
Approved requirements feed test case generation. If you have written test cases under time pressure, you know what gets cut first: the edge cases, the duplicate check, the second read. So we gave that work to a pipeline of specialized AI agents that draft test cases, critique their own drafts, check them against the project’s existing tests for duplicates, and iterate until the result is worth a human’s attention. Human-written test cases can also go through an AI review, which checks for style and, if linked to a requirement, for coverage.
Approved test cases flow to automation. Between an approved test case and running test code there is mostly routine work, and routine work is what AI should take. We built an MCP server that connects SaTI to a coding assistant. The assistant receives the test cases together with the testing framework and our project standards, implements the automation autonomously, and hands the result back for review. And true to the principle above, only a human can mark a test as implemented. The system enforces it; an AI agent attempting that transition is simply rejected.
How much time does this save? I will be honest in the same way the platform forces me to be: we have not measured it in a laboratory. What we see in daily use is that with the test generator, test analysis effort drops by roughly 60 percent, because the work changes from writing to reviewing. When the automation step is used as well, the savings grow further.
Around this main flow, two more tools solve problems every tester will recognize.
The bug reviewer. If you have ever written a bug report, you know that writing a good one is harder than it looks. You are deep in context at the moment of writing, so you skip things that feel obvious, and precisely those things turn out to be crucial for whoever debugs the issue weeks later. AI is genuinely good here. It reviews what you wrote, points out what is missing, and formats the report to the project template, while you stay the author.
The second tool supports session-based exploratory testing. If you’ve tried this, you know it takes discipline: a charter, structured notes, and a real debrief. It’s a powerful technique and my personal favorite, but that same discipline often makes teams skip it. In SaTI, an AI supporter follows the session, helps with the debrief, and automatically drafts bug reports from failed tests.
I keep seeing more places where this approach applies. The next one we want to tackle is test reporting. A good report for the right audience is hard to master, and I have definitely struggled in the past with making test results truly visible to stakeholders. With AI writing reports against a template, the hard part becomes what it always should have been: choosing what to present and having good data. The writing itself becomes a matter of review.
Which, if you have read this far, you will recognize as the pattern behind everything we do. AI produces, humans verify. It turns out that a tester’s professional mistrust is a very good foundation for building with AI.
Let us know which part of your QA process AI hasn’t helped with yet. That’s the kind of conversation we find most useful.
