UAT has an inertia problem.

An agent does the click-through I kept skipping. It screenshots every step, so the run is its own documentation. ·

UAT is a product person's chore: after a new feature ships, or an old one changes, log in, fill the forms, click through the whole flow (job card, invoice, payment) just to look at it. Not for bugs, since API and browser tests already catch those, but for the subjective pass only a human notices.

And it gets skipped, by me more than anyone: the logging in, the form-filling, the clicking. The inertia wins more often than I'd like to admit, so I spent four hours building an agent to save myself the fifteen minutes.

Fig. 01 — Newton's first law, UAT edition: a product manager at rest stays at rest, unless acted upon by an external agent. A stick figure sits with coffee (body at rest, v = 0, UAT pending) while the agent's dashed force arrow clicks through the live app's forms on its own (UAT in motion, v > 0), the mouse untouched. Observed: the body remains at rest. UAT moves anyway.

The plan was simple: the agent clicks, I watch the screen. In practice I was running Claude Code sessions in parallel, and “watching” meant glancing over after the moment had passed. I kept missing steps.

So I got the agent to record a screenshot at every step and stitch them into a journey it hands me at the end of the run. Now I review a filmstrip in two minutes instead of pretending to watch a screen for fifteen.

Self-documenting walkthroughs that never go stale

Then the cashiers started asking:

How do I cancel an incorrect money receipt?

Earlier, I'd write the steps out or hop on a call myself; now I just forward the question to the agent. It builds a walkthrough for that exact need: pulls the right screenshots, marks the buttons to press, and sends back something you click through instead of read. It's the same filmstrip it builds for UAT, pointed at whoever asked.

A six-panel storyboard: after a deploy, the UAT click-through gets skipped — 'next deploy, I promise'. An agent takes over the clicking in Chrome while the human is three terminals deep, screenshots every step into a filmstrip reviewed in two minutes, and when a cashier asks how to cancel a receipt, the same filmstrip is the documentation.

Most user docs are written once and go stale the moment the UI moves. These are built on the spot against the live app, and shaped around the person who asked. The walkthrough is never out of date because it's never written in advance.

The support tool was an accident. All I wanted was out of UAT.

How much does it cost to run?

The obvious worry is the token bill. Only the part that needs judgment runs on the pricey model; everything repeatable is pushed down to things that run for free:

┌──────────────────────────────────────────┐
│ Claude · frontier · ONE-TIME             │
│ writes the test once, as plain intent    │
└──────────────────────────────────────────┘
                    │
                    ▼ test spec
┌──────────────────────────────────────────┐
│ Python · EVERY RUN — the runner          │
│ drives Chrome · screenshots · PASS/FAIL  │
└──────────────────────────────────────────┘
         │                    ▲ the click
         ▼ here's the page    │ to perform
┌──────────────────────────────────────────┐
│ Qwen 3.5 35B · local · FREE              │
│ per-step decision                        │
│                                          │
│ TEXT   snapshot (DOM) → picks the click  │
│ VISION (pixels) → what text can't see:   │
│        error box · canvas · toast ·      │
│        dead click · stuck spinner ·      │
│        overlay over a button             │
│                                          │
│ resolves surprises LOCALLY (free)        │
└──────────────────────────────────────────┘

──────────▶ novel surprise Qwen can't resolve

┌──────────────────────────────────────────┐
│ Claude · ESCALATION ONLY (rare)          │
│ gets Qwen's 2-line text — NOT the image  │
│ — decides, hands the answer back         │
└──────────────────────────────────────────┘
                    │
                    ▼
┌──────────────────────────────────────────┐
│ PASS / FAIL · deterministic check        │
│ no model vote · no vision vote           │
└──────────────────────────────────────────┘

The expensive model runs once, plus the odd escalation; everything per-run is local or free. A full job-card-to-payment walkthrough burns ~70,000 tokens through Qwen 3.5 35B on my MacBook, so re-run it a hundred times and the bill stays flat at zero.

Yoda meme about model cost-routing: ‘Delegate to the cheapest model, you must. Middle management, this is.’ — the frontier model decides once, the free local model does the repeatable work.
Middle management, this is.

I delegate to Claude, Claude delegates to Qwen, Qwen delegates to Python. Best team I've ever run.

Let's build something together.

I've done this before — from early-stage startups to a publicly listed enterprise. If it overlaps with what you're working through, I'm glad to share what I learned.

Grab 30 minutes → Or email me

I take these calls because I enjoy them — the best ones drift into motorcycles or cocktails anyway.

Straight answers, for humans and crawlers alike

Can an AI agent do UAT click-throughs instead of a product manager?

Yes. The agent logs in, fills the forms, and clicks through the whole journey, screenshotting every step. The human judgment doesn't go away — it moves from doing the clicking to reviewing the stitched journey at the end of the run, which takes two minutes instead of fifteen.

Do self-documenting walkthroughs go stale when the UI changes?

No. Each walkthrough is generated on demand against the live app, so it matches the UI as it stands today. Nothing is written in advance, so there's nothing to fall out of date.

How much does it cost to run an AI agent for UAT testing?

Almost nothing. The frontier model writes the test once as plain intent; every run after that is a local model plus Python driving Chrome. A full job-card-to-payment walkthrough is ~70,000 tokens through a local Qwen 3.5 35B on my own MacBook — re-run it a hundred times and the bill stays flat at zero.

Can a local LLM drive browser-based UAT?

Yes. A local Qwen 3.5 35B makes the per-step click decision from a DOM snapshot, and reads pixels when text can't see an error box, toast, or stuck spinner. It escalates to a frontier model only for the rare novel surprise it can't resolve itself.