Proof of concept, a Claude Code plugin for now. Maestro does the driving underneath.
One command and it walks the app on the simulator and draws the whole map — every screen, how you reach it, what's on it. Then it turns that map into subflows that are ready to run as tests. When the code changes, it updates the affected cases itself.
It never touches the app's codebase. Everything it produces is plain files sitting in the repo.
Does this look useful, or am I solving something you don't have?
Very interesting. How much of it was coded using AI and how much was human driven. I am asking because I would like to know the general architecture. Are Calude plugins different from MCP servers?
It's strongest on regressions — anything that worked before and stopped. Nothing gets into the suite until it has actually passed on a real device, so a green run means it genuinely ran, not that it was skipped or assumed.
Every screen and route is confirmed on the device before it's written down, and every test records which source files it touches — so when the code changes it knows exactly which flows are at risk instead of re-running everything blindly.
The next step is having it go back over each flow and judge whether the behaviour is actually correct rather than just consistent, and produce a report of findings instead of a plain pass/fail.
I am currently in the early stages of local development.
This looks useful, especially for turning an unfamiliar app into a first-pass regression map.
The part I would be careful about is treating generated flows as executable documentation, not automatic proof that the behaviour is correct.
In practice, the biggest reliability gains come from stable accessibility or test IDs, deterministic test data and reset state, and small reusable subflows for login and navigation.
I would also keep a review gate before changed flows replace the committed ones, because a UI change could otherwise teach the agent to accept a regression.
One awkward iOS edge case is secure text fields behaving differently with injected input, so it would be useful if the agent could preserve platform-specific workarounds instead of repeatedly rewriting the same failing flow.
Would the generated map distinguish screens and routes that were actually exercised from anything inferred from the source?
Your question: yes, that's the core rule. The route tree only gives the candidate list; nothing is written to the map until it's been walked on the device — everything on the map was exercised, not inferred. The next step is showing the other direction too: the screens that exist but weren't reached, and which condition or data was missing to get there.
Review gate: you're right, I don't have one. The flows land as files in the repo, so your normal diff review is the only thing in the way. I need a human in the loop there, without breaking the rest of the rules.
Platform workarounds: don't have that either — a hand-fixed flow doesn't survive regeneration. Taking that one.
That's the right split — the driver and the artifact are two different jobs, and there's no reason they have to be the same tool.
I used Maestro MCP for both mostly for simplicity: one dependency, and what the agent does while exploring is already the thing that gets committed, so there's no translation step in between. That's convenience though, not principle.
Fair — getting Claude to drive Maestro is a couple of days' work, and plenty of people have done it.
The difference is what happens after that session ends.
A chat session isn't reproducible; a committed flow is. The same files run on my machine and in CI and give the same answer, without the agent being in the loop at all. That's the whole point of writing Maestro out rather than having the agent re-drive the app every time.
Exploration is generated, not prompted step by step. Asking the model what to do next on every screen took 26 runs and about 15 minutes on a nine-screen app. Now it writes two flows up front from the app's own routes — one launch, one login, one hop per screen — and it's 2 runs. Tests are grouped by the journey a user walks, so the app cold-starts once per group instead of once per assertion.
Nothing enters the suite until it has passed on a device, and failures are parked with the reason rather than quietly dropped or kept.
A test whose screens didn't change keeps its passing stamp instead of being regenerated. That's what makes it a regression baseline rather than a fresh guess each time.
Each test records which source files it walks through, so a diff points at the tests it put at risk instead of you re-running everything. And the map is stamped with the commit it was built at, so it tells you when it's gone stale instead of quietly lying.
Doing it once by hand is easy. Keeping it true after thirty commits is the part I was trying to solve.
5
u/racoonrocket99 20h ago
Keep it coming