Test automation has been marketed to businesses for decades as a panacea and a cost-saving miracle, but in practice, it has devolved into a bottomless debt pit. In most large-scale projects, the Total Cost of Ownership (TCO) for test infrastructure is rapidly approaching the actual value it provides—and sometimes even exceeds it. As noted by Egor Laptev, a QA Fullstack Java engineer at SENSE working for a major bank, the situation often borders on the absurd: more resources are spent maintaining tests than actually verifying the product. The moment a frontend team updates a layout, engineers vanish from reality for days to update locators, while every "red" morning in the CI system triggers hours of forensic investigation into the causes of failure.
The desire to delegate this drudgery to a neural network seems logical, but the expected magic has failed to materialize. A case study from SENSE, where an AI was fed over 2,000 tests on a stack of Selenide, Cucumber, and REST Assured, revealed a fundamental problem: current models are not replacements for engineers but merely tools to reduce debugging time, requiring constant supervision. Essentially, we are seeing an attempt to shift operational expenses from one line item to another without changing the final total on the invoice.
The Mechanics of Cognitive Hallucinations in the DOM
The primary bottleneck for LLM-based solutions in QA is their inability to handle context without the "crutches" of supervisor algorithms. In a Supervisor-Worker architecture, the orchestrator must pass the contents of relevant "Skills"—specific project protocols—to the workers in every request. If this data injection falters, the model begins to hallucinate, providing non-existent locators as real ones with disarming confidence.
AI eliminates some of the routine and saves hours, but on complex cases, it fails, loops indefinitely, and confidently presents non-existent locators as genuine.
As a result, businesses face a new type of hidden loss. Instead of spending thirty minutes manually digging through Allure reports and the DOM tree, an engineer spends the same amount of time verifying whether the assistant has invented "alternative physics" to fix a test. AI handles simple NoSuchElementExceptions well: it finds the locator in the Page Object via annotations, checks it against the DOM, and applies fixes. However, once iframes or overlapping elements enter the fray—where Selenide might "go blind" for non-obvious reasons—the AI starts looping. It repeatedly applies standard patterns where engineering intuition is required rather than statistical probability.
Economics on the Brink
For management, deploying such an assistant is a cold calculation of the break-even point. Writing a single scenario takes 2–3 hours, while updating 15 elements after a layout change can eat up to 4 hours of a specialist's time. AI promises to slash these costs but demands the deployment of heavy infrastructure in return—ranging from Moon in Kubernetes to complex agent-chain configurations.
Stripping away the marketing fluff, we are dealing with a tool that merely treats the symptoms of poor architecture. When a morning run yields 200 failed tests despite untouched code—due to infrastructure issues or stale data—AI can provide a diagnosis in 20 minutes instead of 30. However, the company continues to pay for unproductive labor: first for creating the tests, then for maintaining them, and now for the upkeep of the AI that maintains those tests.
The strategic risk here lies in "automation for the sake of automation." Companies hope that neural networks will allow them to continue ignoring the lack of stable locators and messy codebases. Yet, without changing the development architecture itself, an AI assistant only masks inefficiency, becoming an expensive bandage on the jagged wound of legacy code. Investing in the maintenance of something fundamentally designed to be unprofitable is a questionable strategy for those who know how to count their money.