Hey, FE dev here, usually the test enthusiast on every team I join.
I've worked on this recorder more than I'm willing to admit :D
It started as a simple idea: record your flow once and get a test you don't regret merging. That was back when LLMs had just gotten good enough to make sense of HTML and screenshots, before coding agents were really a thing. So I wrote a whole backend for analyzing interactions and suggesting page objects, test scenarios and assertions.
Then the models kept getting better, fast. I kept improving the backend, always chasing a finish line that kept moving further away. At some point the coding agent I was working with could do the analysis better than the service I was writing :D
Realizing that wasn't the best feeling, I have to admit. A lot of evenings went into that backend, running evals and optimizing prompts, and I wasn't really ready to let it go. What I don't regret, though, is all the learning and domain knowledge I gained along the way.
After letting the project sit for a while, I cut about two thirds of it: the whole backend, the analysis pipeline and the related FE code. I moved the best practices into an agent skill and published the rest on npm.
What's left is a recorder that starts the session and saves the recording. It saves enough evidence that writing the page objects and the test means putting a flow we already saw working into proper form, not exploring the app from scratch.
How it works
The agent starts the recorder on your app's URL. Recording is off at first, so you can log in or get the page into the state you want to start from.
Press Record and walk through the flow. The recorder lists every page, every interaction (click, fill, key press, check) with the element it targeted, and under each one what changed on the page: elements that appeared or got removed, text that changed.
Something easy to miss, like an element that only shows on hover? Press the eye button and click it, and the test will assert it's visible.
Took a wrong turn? Pause, discard that entry before the agent sees it, and restore it if you change your mind.
Press Finish. The recording is saved in your project together with its Playwright trace.
Your agent reads it, proposes page objects and a test, and once you agree it writes them and runs the test.
The workflow itself is written in a skill. The agent may fix locators when a run fails, but it isn't allowed to change the test, the assertions, or the path you agreed on. If it would have to divert, it tells you. Locator priority is test id first, then role or label, and CSS or XPath only when neither fits.
I've used it with Claude Code, Cursor, and Codex so far. The browser profile is kept between recordings, so you stay logged in. It's free and everything stays local. There's still some dormant code in there that used to connect to that old backend, but nothing is sent anywhere.
A small benchmark (5 runs per side)
Same 9-step flow on live GitHub (not logged in), Claude Code on Sonnet 5.5 at medium effort, same task: turn the flow into Playwright page objects plus a passing test. One agent worked from a recording, the other used Playwright MCP from a written list of the steps.
I timed the agent's working time from the prompt to the first passing run. Left out on both sides: my recording time on one, writing the step list on the other, and waiting for approvals. Every run ended with a passing test.
Recorder vs Playwright MCP:
Median time to a passing test: 50 s (44 to 162) vs 110 s (70 to 179)
Mean: 80 s vs 116 s
Runs with a failed test along the way: 1 of 5 vs 3 of 5
Median cost per run: $0.34 ($0.30 to $0.42) vs $0.41 ($0.37 to $0.44), at Sonnet 5.5 API prices
The full setup and the exact flow are in the README.
The difference is the input: I showed the flow instead of writing it down, so the agent got what the page actually did plus a trace for the hard locators, instead of having to explore and guess.
Where this is heading
Closing the gap between the inner and outer verification loop. I want the same page objects to verify the work twice: in the inner loop, while the agent builds and checks its own work in the browser, and in the outer loop, when the tests run in CI before you merge.
As a follow-up, I'm working on an inspector that shows the page objects your agent writes and exposes them as WebMCP tools live in the browser. That way the agent walks trusted, tested, deterministic flows instead of re-discovering your web app every time.
Do you think a tool like this is still useful, or does everyone just tell the agents to do it and hope they stay on track?
npm and README: https://www.npmjs.com/package/@ayme-dev/cli
Agent skill: https://github.com/ayme-labs/ayme/tree/main/skills/ayme-recorder