We Used AI to Make Playwright Tests More Context-Aware
Anyone maintaining a growing Playwright test suite knows the pattern. A small UI update changes a locator, dozens of tests fail, and engineers lose time fixing automation even though the product still works.
A more useful application of AI is emerging through Playwright and the Model Context Protocol. Instead of generating test code from a written prompt alone, an AI model can inspect the running application, understand the current page structure, and use real labels, fields, and validation messages when drafting tests.
The model handles the reasoning, MCP carries browser actions and application context, and Playwright performs the actual interactions. When something fails, the model can review accessibility snapshots, browser traces, console messages, and network activity together. This makes it possible to suggest a better locator or identify whether the real issue comes from the frontend, backend, authentication, or network.
The important boundary is that AI should suggest changes, not silently rewrite tests. Engineers still review and commit the final Playwright specifications, while CI continues to run deterministic tests without an AI model in the execution path.
For small teams, this could reduce the maintenance burden that grows with every new feature. The real value is not autonomous testing. It is giving developers a context-aware assistant that can inspect, draft, diagnose, and explain.
How much time does your team currently spend repairing UI tests after product updates?
The suggest-don’t-rewrite boundary is sensible, but I reckon the harder risk is a false repair.
A model can find a new locator that makes the test pass while quietly changing what the test exercises. If a checkout button disappears, selecting the nearest remaining button is not maintenance—it is masking a regression.
I’d want every suggestion to show the original test intent, the relevant UI change, why the replacement represents the same user action, and whether the assertions remain unchanged. Then track accepted suggestions, rejected suggestions and later reversals, not only repair time.
The title says you used this approach. Do you have before-and-after numbers for maintenance time or suggestion acceptance yet?