How to verify coding agent work before it reaches users

Write the acceptance check before asking for the fix

Consider an illustrative UI bug: clicking Save twice during a slow request creates duplicate project records. A useful task says that one submission may be active at a time, the control should communicate that state, and a failed request should allow another attempt. This is an example to reason about, not a reported Uno incident.

"Fix duplicate projects" leaves several decisions open. Should pressing Enter behave the same as clicking? Can the user edit while saving? Does the server already support idempotency? Answer the questions that affect acceptance, and let the agent investigate the code needed to implement those decisions.

For this example, check a rapid second click, keyboard submission, and recovery after an error. Also verify the saved result. A disabled-looking button can still coexist with another submission path that sends a duplicate request.

Match each claim to evidence that can establish it

For the Save example, a screenshot of a disabled button supports the presentation claim. A recorded request count supports the duplicate-submission claim. A real persistence check supports the claim that one record was created. Choose the smallest combination that covers the actual failure.

Keep mocked browser tests and service integration checks identifiable. Both can be useful. They answer different questions, and a reviewer needs to know which dependencies the test replaced.

Make the old behavior fail the new test

Where practical, run the regression test against the starting revision before evaluating the fix. If it already passes, inspect whether it reaches the faulty path. A test can repeat the implementation's own assumption and overlook the behavior the user reported.

For an app with suitable accessible labels, an assertion might look like this. Adapt the route and names to your application. The fixture must keep the first save request pending long enough to inspect the in-flight state.

await page.goto("http://127.0.0.1:4311/projects/new")
await page.getByLabel("Project name").fill("Review fixture")
await page.getByRole("button", { name: "Save project" }).click()
await expect(
  page.getByRole("button", { name: "Saving project" })
).toBeDisabled()

This snippet checks one visible condition. Extend the test to count submissions and to resolve or reject the held request. Playwright's web assertions retry until their condition passes or the assertion times out, which is useful when rendering follows asynchronous work. They cannot supply missing acceptance conditions.

A separate server check may be needed for duplicate requests from another client. Decide whether that is in scope before calling a browser-only fix complete.

Open the branch the agent actually changed

Confirm the running server's checkout and revision before interacting with it. With several local agents, a familiar address can point at another branch's server. Record the application port and the commit tested alongside the browser evidence.

Exercise the failure with realistic timing. A fast local response can hide a race that appears on a slower network. Inspect the loading state and the error state, then retry. Use a phone-width viewport if the form's controls or layout change at that width.

When a browser check fails, preserve enough context to investigate it. Playwright Trace Viewer lets reviewers inspect recorded actions and snapshots after a run. Review traces before sharing them: fixtures and network activity can contain information that does not belong in a public issue.

Read the patch after seeing the behavior

Check whether the implementation covers every entry point. In the example, preventing a second button click may leave keyboard submission untouched. Check how the pending state resets after errors and whether navigating away leaves stale state behind.

Look for unrelated edits, changed permissions, swallowed errors, and dependencies added to solve a small problem. Ask why a large patch is necessary when the brief described a narrow fault. Size alone does not establish risk, but every extra behavior needs an explanation and appropriate review.

A second agent can review the diff against the original acceptance conditions. Give it the brief and evidence, and ask for specific failures with file locations. Treat its findings as review input that must be checked, just as you would a human review comment.

Require a handoff another person can reproduce

Ask the agent to report the changed behavior, tested revision, commands and outcomes, and steps for checking the app. A skipped integration suite belongs in the handoff with the dependency it required. A failed check needs an explanation and a decision about whether the work is ready.

In Uno, read the session's summary, open its artifacts, and compare the diff with the requested outcome. The session guide keeps test results and normal release review part of that process. Completing a turn does not approve a deployment.

Finish review with a precise statement: the pending state was checked, duplicate submissions were counted under a held response, and error recovery was exercised. If the persistence integration could not run, record that remaining check and who will perform it.