For anyone who has spent real time in a QA role, the dirty secret of test automation is easy to name: writing the tests was never the hard part. Keeping them alive was.

Software teams have gotten faster at almost everything else. Deployment speed has gone from a weekend affair to something that happens in minutes. Yet test suites are still stuck in 2015 — high-maintenance, brittle, and one UI redesign away from falling apart.

We ran into this constantly. A designer tweaks a button's class name. A developer refactors a form to improve accessibility. A product manager turns a three-step checkout into two steps. None of these changes break the actual product experience — if anything, they usually improve it. But they break the tests every time, forcing us to drop everything, dig through DevTools, find the new selector, and patch it back together.

Multiply that across dozens of test suites and hundreds of components, and you get what most engineering teams shrug off as "just how automation works." We didn't want to accept that anymore, so we went looking for what AI-driven, self-healing test automation could actually do for a real production codebase — not the marketing version, the working version.

The Real Question Isn't "Can It Run?"

For years, the benchmark for good test automation was simple: does it execute reliably? Can it click the right buttons, fill the right fields, and confirm the right outcomes?

That bar is no longer high enough.

Modern applications don't sit still. Frontend frameworks push updates constantly, teams redesign interfaces to improve usability, and accessibility work — a genuinely good thing — often restructures the very DOM elements that traditional automation scripts depend on. A test suite that can only run against a frozen, unchanging UI isn't really testing your product anymore. It's testing a snapshot of your product from three sprints ago.

So the question we started asking internally wasn't "can our automation execute?" It was: can our automation adapt? Can it identify changes and adjust to them without a human babysitting every release?

Shifting that framing changed our entire approach to the problem.

Why Manual Test Authoring Stops Scaling

Think about how most teams still build UI automation today. An engineer opens the application, pulls up Developer Tools, explores the HTML, and manually hunts for a selector that's reliable but not so brittle it snaps the moment a class name changes. Then they write an assertion, move to the next page, and do it all again.

Initially, it works well. The problem shows up later, once the application grows past the size where one or two people can hold the entire UI in their heads.

At that point, scaling the approach becomes a burden. Every redesign means re-discovering selectors. Every refactor means re-validating assumptions the tests were quietly built on. QA engineers end up spending more time keeping old tests functional than building new coverage for the features that actually shipped this week. That's a bad trade, and most teams know it — they just don't have an obvious way out.

We wanted an actual way out.

Bringing AI Into the Browser: The Foundation of Self-Healing Test Automation

Our answer was to rethink automation architecture from the ground up, using AI agents that don't just read source code from a distance — they get into the browser and interact with the real, live application the way a person would.

We built an architecture using the Playwright Model Context Protocol (MCP), which lets an AI agent log directly into real browser sessions. Rather than guessing at structure from a static codebase, the agent works inside authenticated environments and rendered interfaces.

In practice, the agent behaves like a sharp QA engineer doing hands-on exploration on day one with a new feature — except it never tires or cuts corners. It walks through screens and picks out:

• Interactive elements: buttons, links, modals, dropdowns — anything a user would actually click.
• Form controls: including how they behave when validation kicks in.
• Tables and dynamic layouts: the kind that tend to break naive automation.
• Structural hierarchy: read from headings and accessibility metadata rather than guessed from visual layout alone.
• Durable locator patterns: the kind that won't snap the next time someone renames a CSS class.

That last point matters a lot. Traditional automation tends to be fragile because selectors are chosen for momentary convenience rather than durability. Working through accessibility trees and semantic structure, AI agents arrive at more stable choices by default — their reasoning is focused on what an element is, not where it happens to sit on the page.

Once this is in place, the workflow flips completely. QA engineers aren't the ones combing through markup for the right locator anymore. The AI handles discovery, validates what it finds against the live application, and generates the interactions automation actually needs. Hours of manual exploration per feature shrink to closer to a quick review pass.

The tests that come out aren't disconnected or abstract. They're rooted in how the application behaves today, not how someone remembers it behaving a while back. Practically, that means a higher share of newly generated tests pass clean on the first run, needing slight modifications instead of a complete rewrite.

Teaching AI to Write Tests Like Your Team, Not Like a Generic Bot

Here's something we learned early: getting an AI agent to generate a working test is useful, but if the test doesn't resonate with your team's coding style — if it ignores your naming conventions and internal patterns — you've mostly swapped one maintenance headache for another.

So we didn't stop at "can the AI produce a passing test." We built what we think of as a skill architecture: a project-specific playbook that captures how a given testing team actually works. Their conventions. Their preferred structure. The patterns they settled on after years of trial and error with fragile tests.

Paired with an extensive knowledge base built around established Playwright best practices, the system isn't relying solely on team-specific quirks — it has a solid technical foundation beneath it. Combining the two, the AI stops generating generic, cookie-cutter scripts that need a full rewrite before they're usable. Instead, it starts producing code that looks like it belongs in your codebase from the first draft.

That's a nice quality-of-life improvement on its own. But the bigger payoff is what it sets up for later.

Where This Is Actually Headed

Once you've encoded a team's testing conventions and behavior patterns into something an AI system can reference, you're not just improving how new tests get written. You're laying the groundwork for AI to help maintain tests over time — the exact problem that started this whole conversation.

As frontend components shift and evolve, the same underlying skill system that helps generate a test today can, in principle, help an AI agent diagnose why a test failed tomorrow, figure out what changed, and repair the broken locator largely on its own — without pulling a human into a debugging session every time something moves half a pixel.

That's the direction we think quality engineering is genuinely heading. Not a world where AI simply runs pre-written scripts faster, but one where the automation itself understands the application well enough to notice when things change and adjust accordingly, instead of just breaking loudly and waiting for someone to fix it.

To be clear, none of this replaces the judgment of experienced QA engineers — knowing what to test, understanding user intent, deciding which edge cases actually matter to the business, spotting a subtle regression no automated check would ever catch. That's still deeply human work, and we don't see that changing anytime soon.

What's changing is the grunt work underneath it: selector hunting, endless small repairs, and hours spent re-validating things that should have just worked. AI-driven automation isn't here to replace quality engineering teams. It's here to strip away the tedious parts of the job so those teams can spend their time on the parts that actually require a human brain — the parts that were the real point of quality engineering all along.