Self-Healing Locators and AI-Generated XPath: What Works and What to Watch
Tools now generate locators, repair them when they break, and let language-model agents drive browsers. A sober look at what that means for XPath skills and locator quality.
Three separate things people call “AI locators”
- Locator generation: a tool inspects an element and proposes locators. DevTools “Copy XPath” is the primitive form; browser extensions, IDE assistants and recorders like Playwright codegen and Chrome’s Recorder are the modern ones, and language-model assistants now do it from a screenshot or DOM dump.
- Self-healing: at runtime, when a locator fails, the tool finds the element another way (often by comparing the old element’s attributes and position to the current DOM) and optionally rewrites the locator.
- Agentic browsing: a language model drives the browser through an accessibility tree or screenshots, deciding what to click without any stored locator at all.
Each has a different relationship with XPath.
Locator generation
Generated locators are only as good as the generator’s priorities. DevTools prefers ids and absolute paths. Playwright codegen prefers roles. Many extensions default to absolute or index-heavy XPath because it is the easiest thing to guarantee unique.
What to check on any generated XPath:
- Does it start from a stable anchor rather than
/html/body? - Does it use
[n]indexes that will shift? - Does it depend on a generated id or class hash?
- Would a human reading it know which element it targets?
A generated //*[@id="mat-input-7"] fails all four. A good generator, or a good prompt to an assistant, produces //label[normalize-space()='Email']/following::input[1] instead. If you use a language model for this, give it the robustness rules as part of the prompt and ask for the anchor to be named.
Self-healing
How it works. Healenium (open source, Java, from EPAM) and commercial tools such as testRigor, mabl, Testim, Functionize and the self-healing features in Katalon and similar platforms store a fingerprint of each element when a test passes: tag, attributes, text, neighbours, position. When a locator later fails, they search the current DOM for the closest match by that fingerprint, use it, and log or propose a replacement locator.
When it helps. Cosmetic churn: a class rename, a wrapper added, an id counter changing. The element is still there; only the locator broke. Healing turns a red build into a warning with a suggested fix.
When it hurts.
- The element genuinely changed or disappeared, and healing picks a lookalike. A “Delete” button healing to “Delete all” is a real failure mode. Guard destructive actions with assertions on the element’s text before acting.
- Healing hides locator debt. If every build heals a dozen locators and nobody fixes them, the fingerprints drift until healing starts guessing.
- Healed locators are often worse than the originals: many tools emit index-based XPath as the repaired locator.
Sensible policy. Enable healing in CI, fail the build if a healed locator is used more than N times without being fixed, and review proposed replacements against the same rules as hand-written ones.
Agentic browsing
Agents driven by language models mostly read the accessibility tree, not the DOM. Playwright’s MCP server, for example, exposes a snapshot of roles, names and states, and the model picks elements from that. No XPath is involved at runtime.
Two consequences:
- Applications with good ARIA roles and names work better with agents, which reinforces the industry push toward role-based locators for humans too.
- Agent-generated tests, when exported to code, still need durable locators. The agent’s choice (“the button named Save”) maps naturally to
getByRoleor//button[normalize-space()='Save'].
Agents are effective for exploratory runs and for generating first drafts. They are not yet a substitute for a deterministic regression suite with reviewed locators, because their behaviour varies between runs.
What this means for XPath skills
The value has shifted from writing locators to judging them. Whether a locator came from a colleague, a recorder, a healing tool or a model, someone has to decide whether it is anchored, index-free, readable and specific. That judgement is exactly the content of this site’s lessons, and it is more useful now, not less, because there are more locators of uncertain quality to review.
XPath also remains the lingua franca of the tools: Healenium stores and emits XPath, most recorders can output it, and every framework accepts it. Being fluent means you can read what the tools produce and fix it.
A review checklist for machine-generated locators
- Anchor: named container, landmark, heading, or test id. Not
/html/bodyand not a layout div. - No
[n]unless order is the requirement, and then scoped to a container. - No generated ids or class hashes.
- Text matched with
normalize-space()orcontains(., ...), nottext()=. - Unique on the page (1 of 1 in DevTools).
- Readable without a comment.