There's a new wave of browser automation tools that let you write act("click the submit button") instead of page.click('#checkout-btn'). Stagehand, Browserbase's open-source SDK, is the most visible — 33 million weekly sessions processed across 1,000+ customers in 2025, a $40 million Series B in June, and a complete v3 rewrite in February that runs 44% faster than v2. LambdaTest rebranded to TestMu AI in January specifically to chase this category. Momentic raised $15M. The pitch is the same everywhere: stop writing selectors, let the AI figure out what to click.
It's a compelling idea. The industry has spent years fighting selector brittleness — Forrester says 28% of test failures come from broken locators. If an LLM can look at a page and find the right button by intent rather than by CSS path, that's a real improvement over #app > div:nth-child(3) > button.primary.
Except now your test has a different problem: it's non-deterministic by design.
When you write act("click the submit button"), you're asking a language model to interpret a page's DOM, decide which element you probably meant, and click it. Most of the time it picks right. Sometimes it doesn't — it clicks a different submit button in a modal that just appeared, or it picks a visually similar element that happens to have the word "submit" in its aria-label.
This isn't a bug in the tool. It's the nature of the approach. An LLM's interpretation of "the submit button" depends on the full context of the page, which changes as the app changes. The whole point was to handle UI changes gracefully. But "handles changes gracefully" and "behaves consistently" are in tension.
A traditional selector either matches or it doesn't. An LLM selector always matches something — the failure mode isn't "element not found," it's "wrong element found, test passes anyway." That's worse. A hard failure you investigate. A silent wrong-element pass you never notice until the flow it was supposed to protect breaks in production.
The practical objection to LLM-driven selectors is usually latency: an API call to resolve each step adds hundreds of milliseconds. Stagehand v3 cut that down meaningfully, and it'll keep getting faster. Latency is a solvable problem.
Trust isn't. When a test suite is the thing standing between your deploy and your users, you need to know that a green run means the flows actually work. If the selector resolution is probabilistic, a green run means the flows probably work, as interpreted by a model that may have changed since the last run.
Eighty-one percent of development teams now use AI in their testing workflows. But the World Quality Report found 50% of QA leaders using AI cite maintenance burden and flaky scripts as a key challenge. The tools aren't fire-and-forget yet. Introducing another source of non-determinism — in the selector layer, of all places — makes that problem worse, not better.
The selector problem exists because test frameworks make you name the thing you want to interact with. That's inherently fragile — names change, IDs get generated, classes get refactored.
Record-and-replay skips the problem entirely. You don't name elements. You click them, and the recorder captures what you clicked — the tag, the text content, the role, the position in the DOM. When the recording replays, it uses that captured context to find the same element. If the element moved or got renamed, the replay fails with a clear error: "could not find the element you clicked at step 4." Not a probabilistic best-guess. A deterministic match-or-fail.
That's the tradeoff Test Chain makes. You don't write act("click submit") and hope the model picks the right button. You click the button once, the proxy captures what you clicked, and it replays that exact interaction every time. When the UI changes enough that the element can't be found, the test breaks loudly — which is what you want, because it means the flow your users depend on actually changed, and someone should look at it.
AI-native selectors are solving a real pain point. But they're solving it by trading one kind of brittleness for a subtler, harder-to-detect kind. The test suite that never breaks isn't a sign of good tooling — it might be a sign that your selectors are quietly matching the wrong things.