The Automation Promise Nobody Kept

The Promise That Got Us Hooked

Remember the first time you saw a browser open by itself and click through your application? For those of us who started with Selenium over a decade ago, that moment felt like genuine magic. You wrote some Java or Python, and a real browser did real things. It was slow. Setting up WebDriver was its own special kind of pain. But it worked. And it felt like the beginning of something important.

The pitch was simple and irresistible. Write the test once. Run it everywhere. Catch bugs before users do. Free up your team to do meaningful work instead of clicking through the same login flow for the hundredth time. That pitch spoke to something deep in us. Not just efficiency, but dignity. The idea that skilled engineers should not spend their days on repetitive manual work when a machine could do it.

We bought that pitch wholeheartedly. We built frameworks, hired automation engineers, integrated with CI pipelines. We did everything right. And then we spent the next several years maintaining those tests instead of benefiting from them. The tool that was supposed to save us time became the thing that consumed it.

Shinier Tools, Same Heartbreak

Cypress came along and fixed real problems. No more WebDriver setup. Faster execution. Better debugging. Time travel through your test steps. It felt like a breath of fresh air. Playwright followed with multi-browser support and a more reliable architecture. Appium brought mobile into the picture. Detox gave React Native developers a fighting chance. Each new tool was genuinely better than what came before.

But here is the part nobody puts in the conference talks. The core frustrations survived every generation.

• ●You still spend more time maintaining tests than writing new ones. Industry surveys consistently show that 60% to 70% of automation effort goes into maintenance, not creation.
• ●You still fight with selectors that break when the UI changes. A developer refactors a component, changes a class name, or restructures the DOM, and tests that were perfectly fine yesterday now fail for reasons that have nothing to do with actual bugs.
• ●You still manage separate toolchains for web and mobile. Cypress for the web app. Appium for the Android build. XCUITest for iOS. Separate skills, separate maintenance budgets, separate mental models for what is fundamentally the same application.
• ●You still have that one test that fails every Tuesday afternoon for reasons nobody can explain, and everyone just reruns the pipeline and pretends it did not happen.

The tools got better. The fundamental experience of living with them did not. And if you have been through enough tool migrations to feel this in your bones, you are not being cynical. You are being honest.

The Two Modes of Testing Nobody Separates

Here is something that has bothered me for years, and I have never seen a tool handle it properly.

When you test a login flow, you want to know one thing: does the user get logged in? You do not care if the button moved from the left side of the form to the right. You do not care if the font changed from 14px to 16px. You do not care if someone added an icon next to the password field. The function works or it does not. Small UI changes should be invisible to this kind of test. It should be resilient, forgiving, focused purely on whether the thing does what it is supposed to do.

But then there is visual testing. And here you want the exact opposite. You want to catch every single pixel. That button moved twelve pixels? Flag it. The font weight changed from medium to semibold? Flag it. The padding between elements shifted by four pixels? Flag it. Your design team worked hard on those details. Visual consistency matters, and you need strict, unforgiving verification.

These are two fundamentally different testing modes. One demands grace. The other demands exactness. And almost every tool on the market treats them as the same thing, or forces you to buy completely separate products and maintain completely separate test suites to handle each one. The result? Teams pick one mode and neglect the other. Usually, functional tests win and visual quality slowly degrades without anyone noticing until a customer screenshots the problem on Twitter.

One Tool for Everything: Why It Matters More Than You Think

The hidden cost of the current landscape is not just the subscription fees for three or four different tools. It is the cognitive overhead.

Your team learns Cypress for web. Then Appium for Android. Then XCUITest for iOS. Then Percy or Chromatic for visual regression. Each tool has its own syntax, its own debugging workflow, its own way of reporting failures, its own community, its own set of workarounds for its own set of quirks.

When a test fails, the first question should be “what is broken?” Instead, the first question is often “which tool is this, and how do I read its output?” That extra layer of translation slows everything down. It turns debugging from a focused investigation into a context switching exercise.

And then there is the human cost. You cannot specialize in everything. The engineer who becomes an expert in Cypress rarely has the bandwidth to also master Appium. So you end up with silos. Web automation people. Mobile automation people. Visual testing people. Three groups maintaining three systems that all test the same product but never talk to each other.

The dream has always been simple. One tool. One language. One way of thinking about testing. You describe what you want to verify, and the tool handles the mechanics across every platform, in every mode. That dream felt naive for a long time. The technical barriers were real. Web and mobile are genuinely different platforms with different rendering engines, different accessibility models, and different interaction paradigms.

Why AI Actually Changes the Equation This Time

I will be honest. When I first heard “AI testing tools,” I rolled my eyes. I had seen enough hype cycles to be skeptical. Every few years the industry gets excited about a new paradigm that is supposed to make everything effortless, and every few years we end up right back where we started, just with fancier dashboards.

But something is genuinely different this time, and it took me a while to understand why.

The reason traditional tools cannot deliver on the “one tool for everything” promise is architectural. They rely on selectors. DOM queries. XPath expressions. Platform specific element hierarchies. A web button is found through CSS selectors. A mobile button is found through accessibility IDs or UI Automator queries. They are fundamentally different mechanisms for doing the same thing: finding a button and clicking it.

AI agents do not work this way. An AI agent with vision capabilities looks at the screen the way you do. It sees a button that says “Log In.” It does not care whether that button is a div with an onClick handler, a native iOS UIButton, or an Android MaterialButton. It does not care if it was built with React, Flutter, or SwiftUI. It sees what a human sees and interacts the way a human would.

This is not a minor technical detail. It is the architectural shift that makes “one tool for web and mobile” possible for the first time. Not through clever abstraction layers that paper over platform differences, but by removing the dependency on platform specific element identification entirely.

• ●For functional testing, an AI agent can focus on intent. “Click the login button and verify the dashboard appears.” If the button moves, changes color, or gets a new icon, the agent still finds it, because it understands what it is looking for, not where it used to be. A CSS class rename is no longer a test failure. A redesigned form is no longer a week of maintenance work.
• ●For visual testing, the same AI can switch to pixel level comparison mode. Capture what the screen looks like. Compare it to the approved baseline. Flag every meaningful difference. Ignore rendering noise like antialiasing variations across operating systems. The precision is there when you need it.
• ●For cross platform coverage, the same test definition works across web, iOS, and Android. Not because the tool abstracts away the differences with adapter layers, but because it operates at the visual level where those differences do not exist. A login screen is a login screen, regardless of the platform rendering it.

This is the part that made me stop being skeptical. Not the marketing slides. Not the demos. The architectural argument. Vision based interaction is the only approach I have seen that addresses all three frustrations at once: one tool for web and mobile, forgiving functional tests, and strict visual verification. Everything else is an incremental improvement on a fundamentally limited approach.

The Frustration That Drove Us to Build Something Different

I want to be direct about something. Most “AI testing tools” on the market today are not actually doing what I described above. Many of them are traditional selector based tools with an AI layer on top. They use AI to generate selectors, or to suggest test steps, or to provide natural language interfaces that ultimately compile down to the same brittle element queries underneath.

That is helpful. It saves time on test creation. But it does not solve the fundamental problem. If the AI generates a CSS selector and that selector breaks next sprint, you are right back where you started. The maintenance burden has not gone away. It has just been relocated.

The tool I have been looking for my entire career would work differently. It would understand my application visually. It would test functionality by intent, not by selector. It would verify visual design with precision. It would work the same way on my website and my mobile app. And it would not fall apart every time my frontend team ships a redesign.

I looked for this tool for years. I tried every new framework that promised to be different. I sat through demos and proof of concepts and pilot programs. And every time, somewhere in the fine print, I found the same old limitations wearing new clothes. The tool either relied on selectors under the hood, or it only worked for web, or it could not handle visual verification, or it required so much configuration that the setup cost wiped out any productivity gain.

What “Good Enough” Actually Looks Like

If I could describe the ideal testing workflow, after ten years of doing this the hard way, it would look something like this:

This is not a fantasy. Every piece of this is technically achievable with current AI capabilities. The question is whether anyone is willing to build the tool from the ground up around these principles instead of bolting AI onto an existing selector based architecture.