I'm lazy in a specific way. I'll spend four hours building something to avoid fifteen minutes of doing it by hand.
The thing I was avoiding was UAT.
It's not the bugs — API and browser tests already catch those. It's the soft, subjective pass: does the copy land, does the spacing hold, does the flow feel right. Which meant me, after every deploy, clicking through the whole journey by hand — job card, invoice, payment — just to look at it. So I handed the clicking to an agent that walks the journey and screenshots every step.
Self-documenting walkthroughs that never go stale
Then the support questions started. Cashiers would ask things like:
How do I cancel an incorrect money receipt?
Before, 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 walk it does for UAT — the click-through I built to get out of doing myself, now handed to whoever asked.
Most user docs are written once and quietly go stale the moment the UI moves. This is the opposite — built on the spot, always matching the app as it stands today, and shaped around the person who asked. A live walkthrough that's never out of date, because it's never written in advance.
I didn't set out to build a support tool. I was trying to get out of UAT.
Why it barely costs a token to run
People assume this costs a fortune in tokens. It doesn't — 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 · highlights · PASS/FAIL │
└────────────────────────────────────────────────────────┘
│ ▲ the click to perform
▼ here's the page │
┌────────────────────────────────────────────────────────┐
│ Qwen 3.5 35B · local · FREE — per-step decision │
│ │
│ TEXT snapshot (DOM/buttons) → picks the click │
│ VISION (pixels) → for what text can't see: │
│ error box · canvas · toast · dead click · │
│ stuck spinner · overlay over a button │
│ │
│ resolves known + visual surprises LOCALLY (free) │
└────────────────────────────────────────────────────────┘
│
▼ novel surprise Qwen can't resolve
┌────────────────────────────────────────────────────────┐
│ Claude · ESCALATION ONLY (rare) │
│ gets Qwen's 2-line text — NOT the image — decides, │
│ then hands the answer back to the run │
└────────────────────────────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────┐
│ PASS / FAIL · deterministic backend check │
│ no model vote · no vision vote │
└────────────────────────────────────────────────────────┘
The expensive model runs once (plus the odd escalation); everything per-run is local or free — and PASS/FAIL stays a deterministic backend check, no model vote and no vision vote. A full job-card-to-payment walkthrough burns ~70,000 tokens through Qwen 3.5 35B on my Mac Pro, so re-run it a hundred times and the bill stays flat at zero.
Look at that long enough and it's an org chart. I delegate to Claude, Claude delegates to Qwen, Qwen delegates to Python. Best team I've ever run.
Straight answers, for humans and crawlers alike
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 Mac Pro — 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.