I Made My AI Agent Stop Clicking Around Like a Confused Intern and It's 25x Faster Now

Somewhere in San Francisco there's a GPU farm quietly weeping every time an AI agent takes a screenshot "just to be sure" for the fourth time in a row. I know because I was the one making it weep. Then I stopped, and I have the receipts.

The setup nobody questions

Every agentic coding tutorial teaches you the same ritual: bolt a browser MCP server onto your agent, hand it click and navigate and screenshot tools, and let it drive your browser like your grandpa drives a rental car in a country where he doesn't read the road signs. Cautiously. One action at a time. Screenshot after every single move, just to check nothing's on fire.

It works. It also means every micro-click is a full round trip to the model: "here's what I see, here's what I'll do next, wait for permission, do it, screenshot again, repeat." Multiply that by a normal verification task and you've basically hired the world's most expensive intern to move a mouse for you, one pixel at a time, narrating each step out loud.

I run Claude Code against 30-plus repos daily, so "does the deploy actually work" is not a rare event in my life, it's basically a heartbeat. So when dev-browser showed up on GitHub claiming to be way more efficient than MCP-driven browsing, I didn't just nod and move on like a normal person reading a README at 11pm. I ran the exact same task through both and timed it, because vibes are not a benchmark.

What I tested

One page, four checks, nothing exotic:

1. Navigate to a live site
2. Grab the page title
3. Extract the nav links
4. Take a screenshot

This is not a synthetic benchmark designed to make one tool look bad. This is the actual bread-and-butter loop of "I shipped something, now prove it's alive," which happens approximately eleven thousand times a week in my terminal.

The results

	dev-browser (CLI)	MCP browser (claude-in-chrome)
Tool calls needed	1	4 (context, navigate, extract, screenshot)
Wall-clock time	~1.5 seconds	~40 seconds
Data dumped into context	~1 KB (you decide what gets logged)	~135 KB (full page text plus a base64 screenshot, whether you asked for it or not)
Verdict	fast enough to feel illegal	grandpa merging onto the freeway

Same site. Same four actions. One approach treats the browser like a script you run. The other treats it like a haunted house you tiptoe through with a flashlight, checking every room before entering.

Why the gap is this big (and it's not close)

MCP browser tools assume the model needs to see the page after every move because it might need to improvise. That's exactly the right instinct for genuinely unpredictable UI: some SaaS dashboard you've never met, a modal that appeared out of nowhere, "click the icon that looks vaguely like trash but might also be a recycling symbol, good luck." Visual, adaptive, one-step-at-a-time work.

It is the wrong instinct for "go here, read this, screenshot that," which is roughly 90% of what verification, scraping, and deploy-checking actually are. Most of the internet does not require improvisation. It requires you to show up and read the label.

dev-browser flips the whole premise. You write a tiny script:

const page = await browser.getPage("main");
await page.goto("https://example.com");
console.log(await page.title());
const links = await page.evaluate(() =>
  [...document.querySelectorAll("nav a")].map(a => a.href)
);
console.log(JSON.stringify(links));

...and the whole thing runs inside a sandboxed QuickJS runtime in one shot, with a background daemon keeping pages alive between scripts like a browser that never forgets what tab you were on. One tool call goes in, one filtered result comes out. No play-by-play commentary, no mandatory screenshot tax, no "let me just double check" after every keystroke.

Under the hood it's plain Playwright, so if you've ever written a scraper at 2am fueled by spite and energy drinks, you already know the API.

The plot twist: it drives your actual browser, cookies and all

Here's the part that made me sit up. dev-browser --connect doesn't spin up a fresh, lonely, logged-out browser with amnesia. It attaches to your real Chrome (or Chromium-based browser) over remote debugging and drives the one you're already logged into. Your cookies, your sessions, your fifteen SaaS dashboards you're too tired to re-authenticate into. All still there.

Chrome behaves itself: flip on chrome://inspect/#remote-debugging once, and dev-browser auto-discovers the port like a golden retriever that already knows where the ball is.

Brave, on the other hand, decided to be difficult. Its remote-debugging toggle opens a WebSocket-only CDP server that just... hangs. Forever. Staring at you. A known rough edge in Brave's implementation, not a me problem, I checked. The fix isn't a setting, it's a launch flag:

open -a "Brave Browser" --args --remote-debugging-port=9223

That flag evaporates the moment you launch Brave normally again, so the actual fix is a tiny wrapper app, an osacompile AppleScript stub that always launches Brave with the flag baked in, swapped into the Dock where the old icon used to live. Five minutes of setup, and Brave never gets to be difficult again. Petty? Maybe. Effective? Absolutely.

When you should still summon the MCP browser

I'm not telling you to delete your browser MCP and go live in the woods. I'm telling you to stop reaching for it out of habit. Keep it around for the jobs it's actually good at:

• Unfamiliar UI where you genuinely need to look before you click
• Visual debugging (layout bugs, "why is this button doing an interpretive dance")
• Multi-step forms where the selectors are unstable and you're reasoning from what's literally on screen

Everything else, verification, scraping, "did the deploy work," content extraction, repeated checks on pages whose structure you already know, hand it to the script. It'll get there before your coffee gets cold.

The actual takeaway

The default agentic-browsing pattern (MCP tools, one action per turn, screenshot after everything just in case) is built for the 20% of tasks that genuinely need eyeballs and improvisation. Most browser automation is not that. It's "go here, grab this, confirm that," and treating it like a supervised-clicking problem when it's actually a five-line scripting problem is how you end up paying luxury prices for a grocery run.

If your agent is still clicking its way through a UI it already understands the shape of, you're not being careful. You're just burning tokens to watch it think out loud.

---

Most AI agent tutorials hand the model a browser like a toddler with a TV remote. dev-browser flips that: you write the script, the agent calls it once, everything runs in one shot. The CLI blueprint in the welcome kit shows exactly how to structure tools like this so Claude stops taking screenshots between every keystroke.

→ Get the welcome kit