Closing the Feedback Loop Changes Everything

I refactored some components in our internal admin panel last week. The code looked fine. Tests passed. I shipped it.

Then someone opened it on a phone. Half the layout was broken.

This is the oldest story in frontend development. You change something, it looks fine on your screen, and it’s broken somewhere else. The feedback loop between “I changed the code” and “I can see what happened” has a gap in it.

I plugged that gap with chrome-devtools-mcp and Claude Code. And it kind of changed how I think about building UI.

What chrome-devtools-mcp does

It’s an MCP server that connects Claude Code to Chrome DevTools. That means Claude can look at your running page — the actual rendered DOM, computed styles, console errors, network requests. Not your source code. The real thing in the browser.

Setup is straightforward:

// .claude/mcp.json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp"]
    }
  }
}

Launch Chrome with remote debugging, point Claude at your localhost, and you’re connected.

The feedback loop problem

Building frontend has always been a cycle:

1. Write code
2. Switch to browser
3. Inspect the result
4. Switch back to editor
5. Fix something
6. Repeat

Every step is a context switch. Every context switch costs you time and focus. When you’re debugging a mobile layout issue, you’re also juggling the device toolbar, resizing the viewport, scrolling to the right section, comparing against the design.

With AI coding assistants, this loop got faster for steps 1 and 5 — the writing part. But the AI was still blind. It could generate CSS all day, but it couldn’t see whether the button actually ended up in the right place. You had to be its eyes.

What changes when you close the loop

When Claude can see the browser, the conversation changes.

Instead of me describing “the cards are overlapping on mobile,” I say: “check the layout at 375px width.” Claude takes a screenshot through DevTools, sees the overlap, inspects the computed styles, finds that a flex container is missing flex-wrap: wrap, and fixes it.

One prompt. No context switching. No copy-pasting error messages. No describing visual bugs in words, which is honestly one of the worst things about working with AI on frontend code.

For our admin panel refactoring, this meant I could say things like:

• “The sidebar collapses wrong on tablet. Take a look.”
• “Something is off with the table headers. They don’t align with the data columns.”
• “Check if the modal looks right on small screens.”

Claude would inspect, find the issue, fix it, and I could verify. The loop went from minutes to seconds.

Why this matters beyond frontend

The feedback loop principle isn’t just about CSS. It applies to anything you build.

When you write an API and immediately test it — that’s a closed loop. When you write infrastructure code and run terraform plan — closed loop. When you write a query and see the results — closed loop.

The places where software development feels painful are almost always where the loop is open. Where you change something and can’t immediately see what happened. Deployment pipelines that take 20 minutes. Staging environments that don’t match production. Code reviews that happen days later.

Every tool that closes a feedback loop is a multiplier. Hot module replacement closed the loop for frontend iteration. Docker closed it for “works on my machine.” CI/CD closed it for deployment confidence.

MCP + DevTools closes it for AI-assisted frontend development. The AI can finally see what it’s building.

Getting started

If you’re using Claude Code:

1. Install: npx chrome-devtools-mcp
2. Launch Chrome with --remote-debugging-port=9222
3. Add the MCP config to your project
4. Ask Claude to check your running app

It works with any web app. React, Rails with Hotwire, plain HTML — doesn’t matter. If it runs in Chrome, Claude can see it.

The gap between writing code and seeing results just got a lot smaller.