The 17th edition of the World Quality Report, published by Capgemini and OpenText and based on surveys of more than 2,000 senior executives across 22 countries, found that nearly 90% of organizations are now actively pursuing generative AI in their quality engineering practices. Only 15% have achieved enterprise-scale deployment. One reason the rest struggle: most teams still treat quality as a checkpoint at the end of the pipeline, not as something that has to be engineered into the product's architecture from the first commit.
Yevhenii Ustymenko builds exactly that kind of architecture as an IT SDET architect at AUTO1 Group, one of Europe's largest automotive retail platforms. He designed the foundational QA automation architecture for the core AUTO1 platform, covering major product verticals from merchant-facing applications to back-office systems—the same platform that was running when AUTO1's retail segment posted record revenue and unit sales in Q3 2025. Before AUTO1, at Upswot, a B2B fintech startup, he architected a data synchronization mechanism that became the basis for an international patent portfolio, including the U.S. and Canada, and a key asset in the startup's acquisition. In early 2026, he was invited to judge AITEX Summit: Winter 2026, a global online summit organized by the Association of Information Technology Experts, where over 30 judges from more than 20 countries evaluated data analytics and applied AI projects built by engineering teams worldwide.
We spoke with him about what separates quality engineering from quality control, where scaling products most often break down, and why he is now building an AI agent that writes its own tests.
Yevhenii, you were invited to judge AITEX Summit: Winter 2026, specifically for your track record of building quality architecture for complex B2B platforms. What did evaluating those products tell you about how the industry actually approaches quality versus how it thinks it does?
What stood out was the gap between how confident teams were in their products and how well those products actually held together under scrutiny. A lot of platforms looked solid at the feature level: individual functions worked, and interfaces were clean. But the moment you looked at integration scenarios—what happens when multiple components update simultaneously, when conflicting processes hit the same object, most teams had no structured answer. Not because the engineers were weak, but because nobody had designed for that. The typical response was a local fix: a rule for one component, a workaround for one scenario. It closes the immediate gap but gives the system no general principle for what comes next. My primary lens during judging was not whether a product worked, but whether it was built to stay working as load and complexity grow.
You started your IT career during the COVID-19 pandemic, working on one of Ukraine's first major e-commerce platform launches. What did that experience, early in your career, moving fast under pressure, teach you about the link between speed and architectural risk?
When you're building fast, shortcuts in architecture don't stay hidden for long. Everything that wasn't properly designed: inconsistent state handling, weak integration paths, processes that couldn't support simultaneous load, surfaced quickly once real users arrived. That period made one thing very clear: quality that isn't built into the product from the start doesn't get added later. The team just ends up in a permanent firefighting mode, fixing the same categories of failure in different places. Silpo's online launch during the first COVID lockdown was where I saw that clearly for the first time.
At Upswot, you co-authored a patent, "System and Method for Web Components Interaction and Data Updating." What was the actual business problem behind it?
Upswot aggregated financial data, KPIs, and analytics for banks and corporate clients. At any given moment, multiple components, services, and users were all writing to the same data from different points. On the surface, that looks like a UI inconsistency problem; one widget shows one number, another shows something different. The actual problem runs deeper: the client is making decisions based on data that contradicts itself, and they often don't know it. What the patented mechanism did was give the platform a single trusted logic for deciding which updates were authoritative; instead of treating all incoming changes as equal, the system validated a change's origin before acting on it. That distinction, at scale, is what stopped conflicting states from accumulating into something clients would actually see. After implementation, flaky tests related to state desynchronization dropped by 80–85%, time spent manually tracing data conflicts fell by roughly 40%, and time-to-market for new releases increased by approximately 1.5x. For a startup, those numbers translate directly into acquisition value—which is what happened.
At AUTO1 Group, your work on the CRM platform is connected to the record Q3 2025 results. What does quality engineering actually look like when it's supporting live sales operations?
Unpredictability in a CRM has a direct cost. When updates don't behave consistently, people stop trusting what the system shows them, and a sales team that second-guesses its own data starts making decisions more slowly, or not at all. At AUTO1, I built the quality architecture from zero: testing approaches that look at how parts of the system interact, not just whether individual features work. The risky moments in a system like that are never inside a single function—they're at the handoffs: between massive microservices, external data pipelines, and internal workflows. Get those stable, and the platform becomes something people use without thinking about it. That's the goal. This architectural shift wasn't just theoretical; it directly reduced critical production incidents by 79%, cut regression testing time from over 4 hours down to 30 minutes, and helped sustain a 99.85% platform uptime during peak sales periods.
Having evaluated products as both an AITEX judge and a QA consultant, what is the most common failure pattern you observe?
The most consistent failure I see is a mismatch between how teams measure quality and what actually matters when a system is under real production load. Teams track test coverage, automation percentages, bug counts. What they're not tracking is how the system behaves when three different services try to update the same record at the same time, or when a data change in one module needs to propagate correctly to six others for a business process to complete. Those scenarios don't fail during feature testing; they fail in production, at scale, usually at the worst possible moment. And by that point, the teams that built the system have often moved on to other features. The fix requires going back to architecture decisions made months earlier. I've seen this pattern in products at very different stages—early-stage startups and large enterprise platforms. Scale changes the consequences, not the root cause. The root cause is almost always that quality was treated as a verification layer rather than a design constraint.
You're currently implementing an AI agent for automated test generation at AUTO1. What problem does it actually solve?
Right now, keeping integration tests current is almost entirely manual work. Every time something in the product changes, an engineer has to understand what changed, trace the dependencies, and update the tests that cover it. It scales terribly. The agent I'm building does that analysis on its own, reads the product's structure, understands how components relate, and generates tests that verify the system works as a whole, not piece by piece. Think of it as the difference between an inspector who checks each part by hand and one who reads the full engineering schematic. Practically: faster error detection, less manual overhead, smaller risk window for every release.
Where do you expect the next significant engineering challenges in quality and testing to emerge?
Most testing is still organized around one assumption: verify what's already been built. That worked when systems were simpler. As B2B products grow—more users, more integration points, more concurrent processes—it stops working. What matters at that scale is knowing in advance which integrations are fragile, where data conflicts are likely, and which scenarios will break under load. That's the shift I'm most interested in and, honestly, the one most tooling hasn't caught up to yet.
ⓒ 2026 TECHTIMES.com All rights reserved. Do not reproduce without permission.
