A 5-Agent Pipeline That Replaces the Flakiest Parts of UI Automation
UI test suites die because maintenance costs outpace writing speed. Splitting the problem into five single-purpose agents—each producing a verifiable artifact—lets teams automate the repetitive 80% without surrendering quality control. The agents are independently callable, so a team can drop one into an existing Playwright or Selenium stack without rebuilding everything.
UI automation breaks constantly because every step—element grabbing, script writing, CI hardening, visual checks, and maintenance—is manual and fragile. A single monolithic AI skill can't fix this. Instead, a chain of five narrowly-scoped agents, each with a single responsibility, forms a closed loop from page parsing to self-healing maintenance. The pipeline starts with a BFS crawler that outputs a standardized pages.yaml, feeds it to a generator that produces POM classes, test cases, and data in one shot, then passes the scripts through an enhancer that adds smart waits, popup handling, and captcha solving. A visual assertion agent adds pixel-level screenshot comparison across browsers and viewports, and an optional maintainer detects DOM changes and auto-repairs broken locators.
The architecture's core rule is that AI does the grunt work from 0 to 80, and a human verifies the final 20. Each agent can run independently, so teams can adopt only the pieces they need. The approach compresses weeks of manual scripting into minutes, but the output still requires a human to check locator strategies, data coverage, and baseline accuracy against the real application.
Merging test-data generation with script generation is a pragmatic design choice that reflects how tightly form fields and page actions are coupled in UI tests; splitting them would create an awkward handoff.
The insistence on prohibiting long XPaths and preferring data-testid then semantic locators is a concrete, enforceable rule that an agent can apply more consistently than a human team following a style guide.
Positioning the maintainer as optional acknowledges that many teams abandon UI automation before maintenance becomes the bottleneck; it's a realistic adoption curve rather than an all-or-nothing architecture pitch.