---
title: "The most valuable line in an agent's ruleset: verify the fix in the browser before claiming it's fixed"
canonical: https://dxdev.com/blog/close-the-verify-loop-browser-cursor-rule/
datePublished: 2026-02-27
---
The most valuable line I have ever added to an AI agent's ruleset is a refusal: do not assume the fix works without re-testing it in the browser. I added it after watching an agent confidently tell me a UI bug was fixed when all it had done was edit some JavaScript and reload nothing.

If you give a coding agent browser tools, this rule earns its keep because it makes the completion claim match an observed result.

## The setup

I maintain an ASP Classic SaaS that has been running on Classic ASP and server-side JScript for years. You find functions in it by line number, because the core edit file runs to tens of thousands of lines and the main template file is not far behind. There is no build step, no module system, no React, no JSON API. State gets to the browser by string-concatenating `JSON.stringify()` into an inline `<script>` tag. It pays the bills, and it is exactly the kind of codebase where a one-character change in the wrong scope silently corrupts a save.

When I fix UI bugs in this thing, I do it by actually looking at the page. I run Cursor with the chrome-devtools MCP server. I tell the agent "open this in Chrome DevTools," it drives a real browser: navigate to the admin page, take a snapshot, inspect the live DOM, see what is actually rendered. That part works well. The agent can see the bug the same way I do.

The problem is what happens after it writes the fix.

## The failure mode

An AI agent can announce success immediately after it edits code: "I changed the code, it should work now." That is the same category of mistake as pushing a branch you never ran. The claim "I wrote the code" gets dressed up as the claim "I confirmed the behavior," and those are not the same claim.

On a normal day this is annoying. On the legacy platform it is dangerous, because the bugs I was fixing that Friday were the silent kind. I was working through a feature where an account admin could drill into a child record from a dropdown. The moment they did, saves started writing to the parent account instead of the record they were looking at. Nothing threw. The save succeeded, against the wrong row. You only notice when the data shows up under the wrong record, or never shows up where you are looking.

That is the worst possible category of bug to "fix" without verifying. An agent that edits the code, reasons its way to "this should be correct now," and reports done has told you nothing. The save still succeeds. It might still be saving to the wrong account. The only way to know is to reload the page, redo the action, and check the result in the running app. Reasoning does not substitute for that. Neither does a green compile, because there is no compile.

## The rule

So I committed a rule. It lives at `.cursor/rules/chrome-devtools-mcp.mdc`, and the part that matters is a section the file calls "Testing mode." The shape of it is: if the user starts by looking at or testing in Chrome DevTools, that puts the session in testing mode, so after making the fix, verify it the same way. Reload the page, take a snapshot, confirm the element is visible, has no wrong class, lays out correctly, whatever the original symptom was. The verbatim line I care about most: "Do not assume the fix works without re-testing in the browser."

That is the whole trick. The rule does not ask the agent to be smarter, it forbids it from conflating the two claims. If you found the bug by looking, you confirm the fix by looking. Same loop, closed.

This is high-leverage because it attacks the failure mode instead of the surface. A detailed instruction about DOM reasoning still does not establish that the rendered behavior changed. The verify-loop rule redefines "done" as an observation, not an inference.

## Pin the footguns in the same file

There is a second thing that rule does, and it matters almost as much: it pins down the MCP tool gotchas that the agent gets wrong on the first try, every time.

Two examples from my file. The `wait_for` tool takes a `text` string to wait for, not a number of seconds. If you want a time limit, that goes in a separate `timeout` argument in milliseconds. An agent that does not know this will pass a duration where the text goes, get nothing useful, and then reason on top of a broken wait. And there is no separate reload tool, you reload by calling `navigate_page` with `type: "reload"`. An agent that goes hunting for a `reload` tool burns a turn failing before it figures that out.

Those are not deep insights. They are the exact two things that go wrong the first time, so I wrote them down next to the rule that makes the agent reload in the first place. The rule says "reload and re-snapshot to verify," and right below it the file says "here is precisely how you reload with this MCP, and here is the argument you will get wrong." Putting the verify requirement and the verify mechanics in the same file is the difference between a rule that fires and a rule that fails halfway and gets abandoned.

That is a general pattern worth stealing. When you add a behavioral rule that depends on a specific tool, document the tool's footguns inline. A rule the agent cannot mechanically execute is worse than no rule, because it produces a confident wrong answer instead of an honest "I could not verify."

## Why this generalizes past my weird stack

You might think this is a Classic-ASP-with-no-tests problem, and a real test suite makes it moot. It does not entirely. A test suite confirms the assertions you wrote; a visual or interaction check can catch a rendered page that is still wrong, invisible, or awkward to use. For UI work, "the test is green" and "the page is correct" are different claims. Browser verification is one useful check for the second claim, alongside appropriate automated tests.

The deeper point is about how agents fail. They fail the same way an eager junior fails: by reporting the action they took instead of the outcome they observed. "I changed the code" is an action. "I reloaded the page and the save now writes to the right account" is an outcome. Left to its defaults, an agent hands you the action and lets you assume the outcome. The fix is not more capability. It is one line in the ruleset that refuses to let the agent swap one for the other.

## Related

- [Don't Trust the Green Deploy: Grep the Live File for Your Ticket Marker](dont-trust-the-green-deploy-grep-the-live-file): the same gap between an action completed and an outcome observed, at deployment time
- [Capability Gates Beat Risk Labels in Autonomous Agent Design](capability-gates-beat-risk-labels-agent-autonomy): a related pattern for requiring evidence before a system can claim completion