3 Ways I Use AI to Auto-Generate Playwright Locators

A test automation engineer with 18 years of experience described three ways he uses AI to auto-generate and maintain Playwright locators, including feeding DOM snapshots to an LLM to suggest resilient selectors, generating flagged fallback locators when primary selectors break, and translating BDD-style natural language scenarios into first-draft Playwright code. He cautioned against silent self-healing that rewrites test suites, arguing AI should remove tedious locator selection work while leaving test design judgment to humans.

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. 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. js // 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. 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." 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 https://kdp.amazon.com/amazon-dp-action/us/dualbookshelf.marketplacelink/B0HJLR1W6Y .