Closing The Frontend Loop For Coding Agents

The missing loop is the browser

Sawyer Hood describes the agent loop as observe, think, act, and evaluate. That framing matches what I see in day-to-day coding agent work. The agent gets useful when it can evaluate the result instead of stopping after a patch.

Backend and CLI tasks usually have obvious checks. Run the test. Run the type checker. Run the command again. Frontend tasks are messier because the result depends on the live browser: current route, cookies, extension state, local tunnel domain, hot reload, request timing, layout, and console output.

A screenshot helps, but it is not enough. The screenshot can show that the page still looks wrong. It cannot tell the agent whether the click handler ran, whether the request body was stale, whether the server returned 401, or whether a console exception stopped the UI after a good response.

The loop I want

Before an agent edits frontend code, I want this sequence:

1. page_summary
2. click or fill
3. get_network
4. get_logs
5. diff
6. screenshot only if visual state matters
7. then edit

The order matters. page_summary gives the agent the current page structure and selectors. click and fill reproduce the user action in the real tab. get_network and get_logs explain the hidden browser failure. diff checks whether the DOM changed after the action or hot reload.

I save screenshots for visual state: layout, clipping, contrast, modal position, and review evidence. I do not want screenshot-first debugging when a small structured result answers the question.

What DevSnoop adds

DevSnoop gives the agent a local Chrome bridge. The agent talks to http://127.0.0.1:9400/. The native host forwards the command to the Chrome extension through Native Messaging. The extension runs the command in the browser and returns structured JSON.

curl -s -X POST http://127.0.0.1:9400/ \
  -H 'Content-Type: application/json' \
  -d '{"command":"page_summary","params":{},"tabID":123}'

I am intentionally keeping this smaller than a full browser runtime. DevSnoop is not Playwright, and it does not prove the product is correct. It gives coding agents the evidence I want during local development: page summaries, selectors, UI actions, logs, network failures, DOM diffs, and screenshots when needed.

The evidence changes the next edit. No request means check event wiring or validation. Wrong payload means check state mapping. Good response with broken DOM means check rendering. Console exception means check the crash.

A prompt I use

Before editing, close the browser loop.

Use DevSnoop against the current Chrome tab:
- page_summary
- reproduce the flow with click/fill
- get_network
- get_logs
- diff
- screenshot only if visual state matters

Then tell me which file you will edit and why.

I want the agent to connect the browser evidence to the code edit. Without that step, it can still patch the closest visible component.

Where this fits

Keep Playwright and end-to-end tests for repeatable test suites. Keep unit tests for logic. Keep type checks for code contracts.

DevSnoop fits the local implementation loop. The page is already open. The bug is already in front of you. The agent needs to observe and operate the same browser tab you are using, then bring back enough evidence to avoid a blind edit.

I wrote more about the request side in debugging the request versus debugging the feature and capturing fetch request bodies before editing.