Point a usability study at your live site and you spend the first twenty minutes fighting the site instead of testing it. Cloudflare throws an interstitial. The login form triggers a rate limit after three attempts. A CAPTCHA blocks the checkout you actually wanted to walk. None of that has anything to do with whether the flow is usable. It is just the production perimeter doing its job.
Run the same study against your dev build on localhost and those obstacles disappear. No bot detection, no rate caps, no third-party scripts refusing to load on an unfamiliar IP. You get a clean path through the flow, and the person or agent doing the review can focus on the interface.
Why the dev build is the right target
Three concrete reasons, beyond dodging bot-blockers.
First, your dev build is the version you can change. If the study finds that the password field rejects a valid email on blur, you want to fix the code that caused it, not file a ticket against a deployed artifact and wait for the next release. Testing where you can edit shortens the loop to minutes.
Second, dev builds carry test data you control. You can seed an empty cart, a half-filled profile, or an account with 200 saved items and walk each state on purpose. On production you get whatever real data happens to exist, which usually is not the edge case you needed to check.
Third, and this is the part most teams miss, an agent testing your dev build can read the repo behind it. It does not just report that the submit button does nothing. It can trace the handler, see the missing await, and tell you the root cause. That is the difference between a symptom and a fix.
The setup, step by step
Start your dev server as usual, so the app is running at something like localhost:3000. Open a new browser tab in Chrome or Edge and go to start a new review. There is nothing to install and no signup, so you are capturing within seconds.
Walk the flow you want to study. At each screen worth flagging, click Capture screen, share the browser window, and drop a numbered pin on the exact control in question. Then dictate what you observed. Speaking it is faster than typing when you are mid-flow, and the browser handles the transcription. If you are on Firefox, you type the comment instead.
Do not narrate the obvious. "The Continue button is greyed out even though both required fields are filled" is worth capturing. "This is the checkout page" is not. Pin the spot, state what should happen, state what happened.
When you have walked the flow, click Publish. You get a public link at /r/<slug> and the same review as clean markdown at /r/<slug>/markdown. That markdown is the file your agent reads.
Handing the study to the agent
The review link gives a person the story: pinned screenshots, comments, resolve buttons. The markdown version gives your agent an ordered list of screens, pins, and observations it can parse without guessing. Feed it that file inside Cursor, Claude Code, or whichever agent you run, and it maps each observation to a location in your code.
This is where testing on the dev build pays off twice. The agent has both the screenshot showing the broken state and read access to the source that produced it. Ask it to explain why the Continue button stays disabled, and it can find the validation logic, spot that the field checks for length before trim, and propose the one-line change. You get a cause, not a complaint.
If you want the agent to run the walkthrough itself rather than just read yours, that is a related workflow covered in have your agent run a usability test. Either way, the output stays in a form the agent acts on directly.
What the study catches that a production run misses
Because you seeded the data and controlled the environment, the findings are reproducible. When you write "cart with 12 items, remove one, total does not update," the agent can recreate that exact state and confirm the bug before touching the fix. A production finding often reads "saw a weird total once," which nobody can reproduce and nobody fixes.
You also catch layout problems the agent can trace to a component. A pin on an overlapping label plus the markdown note plus repo access is enough for the agent to find the flex container and the wrong gap value. Compare that to a screen recording, which shows the same thing but forces the agent to watch a video it cannot read. The reasons a recording fails as agent input are worth understanding before you record.
The broader practice of studying a build this way, capturing observations as structured items an agent can turn into fixes, is what AI usability testing is built around. Running it against your own dev environment is simply the cleanest place to start.
Next time you are about to test a flow, check the URL first. If it says localhost, you have already skipped the bot-blockers and handed your agent the source it needs. Start the server, open a tab, and walk the flow.