If you've maintained a Playwright suite for more than a few months, you know the real cost isn't writing tests — it's the constant locator rot. A designer tweaks a class name, a component gets refactored, and suddenly a dozen tests are red for reasons that have nothing to do with actual bugs.
After 18 years in test automation — including building enterprise-scale frameworks — I've found that AI-assisted locator generation is one of the highest-leverage places to bring LLMs into a QA workflow. Here are three approaches I actually use, not just demo-ware.
1. AI-Assisted Locator Discovery from the DOM
Instead of hand-picking a data-testid or fighting brittle CSS selectors, I feed a snapshot of the relevant DOM section to an LLM and ask it to propose the most resilient locator strategy — prioritizing accessible roles and text over implementation-specific attributes.
// Instead of guessing at a selector manually:
const button = page.locator('.btn.btn-primary.mt-2.submit-btn-v2');
// Ask an AI-assisted step to suggest something resilient:
const button = page.getByRole('button', { name: 'Submit Order' });
The win isn't that AI "knows" your app — it's that it consistently nudges you toward Playwright's built-in resilient locator patterns (getByRole, getByLabel, getByText) instead of the CSS-selector habits many teams fall back into under deadline pressure.
2. Self-Healing Locators via Fallback Chains
When a primary locator fails during a run, rather than failing the test outright, I use an AI step to analyze the current DOM and suggest a fallback locator that matches the original intent of the interaction — then logs the drift so a human confirms it later.
This isn't "magic self-healing" that silently rewrites your test suite (which I'd actually caution against — silent healing can mask real regressions). It's a flagged suggestion: "Your original locator broke; here's what looks like the same element now; confirm before I update the source."
3. Locator Generation from Natural-Language Test Steps
For teams writing BDD-style scenarios ("User clicks the 'Add to Cart' button"), I use AI to translate that natural language directly into a first-draft Playwright locator + action, which a human then reviews and commits.
When the user clicks "Add to Cart"
becomes a suggested:
await page.getByRole('button', { name: 'Add to Cart' }).click();
This dramatically speeds up onboarding less-experienced testers into a Playwright framework, since they're writing intent, not fighting Playwright's API surface on day one.
The common thread across all three: AI isn't replacing test design judgment — it's removing the tedious, error-prone parts of locator selection so testers can focus on what to test, not how to write a selector.
I go deeper into all of this — plus patterns for AI-assisted test generation, flaky test triage, and building a production-grade framework end to end — in my book, Playwright Test Automation with AI.
Top comments (1)
The accessible-role-first part is what makes this practical. AI can help propose selectors, but keeping the fallback chain biased toward user-visible semantics should reduce the chance of a test "healing" into a selector that still passes while pointing at the wrong element.