The locator is the problem. Not the patch list.

What Selenium actually is, at the protocol layer

Selenium WebDriver is a wire protocol. Your test sends an HTTP request to a driver process, the driver translates it to the browser's native automation API, and the browser does the thing. For Chrome, that driver is chromedriver listening on port 9515. For Firefox it is geckodriver. The protocol itself, codified at w3.org/TR/webdriver2, is a list of endpoints with names like /session/{id}/element.

Look at the endpoint list and the philosophy is right there: you POST to /element with a "using" key (id, name, css selector, xpath, link text, partial link text, tag name) and a "value" string. The protocol presumes you know how to identify the element. The locator is the primitive. Everything Selenium 5 added on top, including the BiDi WebSocket layer for events, leaves that primitive intact.

That is fine until the page changes. Every selector you wrote is a guess that the page's structural identity is stable. The structural identity is rarely stable. The patch list is a response to that fact, not an alternative to it.

The patch list every senior team has tried

If you have run a Selenium suite for more than a year, you already know the playbook. None of these are wrong. They are all good. The point is that they are all patches, and they all live on top of an input surface that still expects a locator string on every step.

Each one is real engineering. Adopting the Page Object Model does centralise locators; pinning chromedriver does eliminate the worst class of version drift; BiDi does give you events the old protocol could not. But the test in your file still reads: driver.find_element(By.XPATH, "//button[normalize-space()='Continue']").click(). Tomorrow marketing renames the button to "Sign in." The XPath stops matching. The patch list does not save you; it only tells you which patch to add next.

What an alternative input surface looks like

The accessibility tree is already a labelled, role-tagged structure of every interactive element on the page. Browsers compute it for screen readers. Playwright MCP exposes it via a tool called browser_snapshot. Every node has a role ( textbox, button, link), an accessible name (the visible label or aria-label), and a short ref ID like e7. That is enough to identify any interactive element on the page without writing a CSS selector or an XPath.

Assrt is built on this idea. It is a small Node MCP server that spawns a local Playwright MCP process and exposes eighteen tools to a model (Claude Haiku 4.5 by default, Gemini 3.1 Pro optionally). The tools live in the TOOLS array starting at line 16 of assrt-mcp/src/core/agent.ts: navigate, snapshot, click, type_text, select_option, scroll, press_key, wait, screenshot, evaluate, create_temp_email, wait_for_verification_code, check_email_inbox, assert, complete_scenario, suggest_improvement, http_request, and wait_for_stable. Notice what is not there: any verb that takes a CSS selector or an XPath. The two element-targeting tools (click, type_text) take a human-readable description and optionally a ref. They do not take a locator string.

The agent's contract with the model is in the system prompt at line 198 of the same file. The relevant block, headed Selector Strategy (Playwright MCP refs), lives at lines 213-218 and reads, almost verbatim:

## Selector Strategy (Playwright MCP refs)
1. Call snapshot to get the accessibility tree
2. Find the element you want to interact with in the tree
3. Use its ref value (e.g. "e5") in the ref parameter
4. Also provide a human-readable element description for logging
5. If a ref is stale (action fails), call snapshot again to get fresh refs

That is the entire flaky-test recovery contract. Five sentences. The fifth is doing nearly all of the work. Every Selenium retry framework, every page object base class, every visual regression harness exists to compensate for the absence of that line. With it, the agent re-reads the page on every action; it never depends on a stale identifier. There is no global retry decorator and no centralised locator file because there are no locators to centralise.

The same test, both ways

One test, written twice. Left: a typical pytest + Selenium WebDriver port of "sign in and create a project." Seven locators, three of them XPath. Right: the same intent expressed as a Markdown plan file. The agent reads it line by line and calls real Playwright MCP under the hood.

# tests/test_create_project.py
# A typical Selenium WebDriver test, the way every "automation
# test selenium" guide teaches it.

import os
import pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

@pytest.fixture
def driver():
    options = webdriver.ChromeOptions()
    options.add_argument("--headless=new")
    drv = webdriver.Chrome(options=options)
    drv.implicitly_wait(0)
    yield drv
    drv.quit()

def test_create_project(driver):
    driver.get("https://app.example.com/login")
    wait = WebDriverWait(driver, 10)

    # Locator #1: email field. Will rot if the design system
    # renames the input or wraps it in a new shadow root.
    email = wait.until(EC.presence_of_element_located(
        (By.CSS_SELECTOR, "input[name='email']")))
    email.send_keys(os.environ["DEMO_EMAIL"])

    # Locator #2: password. Same fragility.
    pw = driver.find_element(By.CSS_SELECTOR, "input[name='password']")
    pw.send_keys(os.environ["DEMO_PASSWORD"])

    # Locator #3: submit button. Watch for marketing renaming
    # "Continue" to "Sign in" next quarter.
    driver.find_element(By.XPATH,
        "//button[normalize-space()='Continue']").click()

    wait.until(EC.url_contains("/dashboard"))

    # Locator #4: the new-project button.
    driver.find_element(By.XPATH,
        "//button[normalize-space()='New project']").click()

    # Locator #5: the project-name input.
    name = wait.until(EC.presence_of_element_located(
        (By.CSS_SELECTOR, "input[aria-label='Project name']")))
    name.send_keys("smoke")

    # Locator #6: the Create button.
    driver.find_element(By.XPATH,
        "//button[normalize-space()='Create']").click()

    # Locator #7: assertion target.
    heading = wait.until(EC.presence_of_element_located(
        (By.XPATH, "//h1[normalize-space()='smoke']")))
    assert heading.is_displayed()

The line count is not the point. The locator count is. The Selenium file has seven independent reasons to break next quarter; the Markdown file has zero. If marketing renames "Continue" to "Sign in", the agent's snapshot returns a button named "Sign in", and the model picks that ref because the scenario says "Press Continue" but the closest semantic match is the only sign-in button on the page. (You can be stricter than that with an explicit pass-criteria block; see the FAQ.)

What happens on the wire, one step at a time

The model never sees a screenshot for routine clicks (it can request one). It sees the accessibility tree as text, picks a ref, and calls a tool. The tool calls a real Playwright MCP method, which speaks CDP to a real Chromium binary. If the click fails, the model re-snapshots. The diagram below traces one round-trip of one click.

On a stale-element error, the agent does not retry the same ref. It calls snapshot again; the page returns a fresh tree; the click goes to the new ref. This is not a feature anyone implemented as a retry framework. It is what happens when the system prompt says "if a ref is stale, call snapshot again to get fresh refs" and the model takes that instruction literally. The line is at assrt-mcp/src/core/agent.ts:218.

What you give up, and where Selenium still wins

This is not a "Selenium is dead" piece. The honest tradeoffs:

• Language portability. Selenium has first-party bindings for Java, Python, C#, Ruby, JavaScript. Assrt is a Node MCP server. Tests run from Claude Code, Cursor, an editor with an MCP client, or the CLI. If your QA team writes Java, that is friction.
• Browser matrix. Selenium drives Chrome, Firefox, Edge, Safari, IE 11, plus mobile via Appium. Assrt drives whatever Playwright MCP drives (Chromium reliably; Firefox and WebKit when configured). If you must test IE 11 on Windows Server 2019, Selenium Grid wins.
• Determinism on stable suites. An LLM in the loop introduces a small amount of non-determinism. For tests that already pass 99% of the time with selector-based code, swapping in a model is a downgrade. The Assrt migration target is the 1% that always flakes, not the 99% that already works.
• Cost shape. A Selenium run is free at the unit-economics level once you own the CI runner. An Assrt run pays per-token to the model provider. With Claude Haiku 4.5 the average #Case is a few cents; for a thousand-test suite, monthly bills are real and should be budgeted.

Where Selenium does not win and never will: the locator-rot problem. It is structural. No best-practice list eliminates the input surface that produces it. The choice is whether to keep paying the patch tax forever or to route the suites that hurt most onto a substrate where the patch tax is zero.

Toggle a real selenium failure against the Assrt path

The most common Selenium failure mode in real production suites. One side is what your CI dashboard looks like the morning after a frontend rename. The other side is what actually happened in the test that did not break.

How to verify the claim in your own node_modules

Three commands. None require an Assrt account.

1. npm install assrt-mcp — pulls the MIT-licensed package from the public registry.
2. grep -n stale node_modules/assrt-mcp/dist/core/agent.js — prints the exact line that says "If a ref is stale (action fails), call snapshot again to get fresh refs." Same string lives in your install as on the page above.
3. grep -c 'name: "' node_modules/assrt-mcp/dist/core/agent.js — counts the eighteen tool names in the TOOLS array. Confirms you are running an agent that dispatches to a fixed, inspectable contract — not a black-box DSL.

If those three commands give you the file paths, line numbers, and counts described in this piece, the rest of the architecture follows. The rest is just running it against your own URLs.