Nate wires Playwright CLI into Claude Code so the agent can drive a real browser, then runs three live demos: QA-testing a self-built multi-page onboarding form (find bugs, fix them, re-test in a loop), scraping dentist phone numbers off search results, and operating inside a logged-in account. The recurring lesson is closed-loop iteration — the agent tests its own work, reads the screenshots and errors it produced, rewrites its script, and runs again until it passes.
qa-test), and pairing those scripts with a Claude Code skill makes the automation consistent and rerunnable.The premise is simple: give Claude Code control of a browser and you can automate almost anything — stress-testing an app, downloading reports from sites with no API, or filling out forms. Nate starts in a fresh Claude Code project and uses plan mode to have the agent research the options and install a browser-automation tool. He tried Chrome DevTools for a bit but landed on Playwright CLI, and his reasoning is about context economy: running /context shows the Chrome DevTools MCP consuming a large share of tokens because every tool ships with a description. Skipping the MCP server and using the CLI keeps the context lean while still letting the agent open pages, click, and screenshot.
"So, when you give a tool as powerful as Claude code, access to literally control a browser, if you think about it, you can actually automate anything."
The centerpiece demo is closed-loop testing. Nate asks Claude Code to build a multi-page onboarding form — one question per page, roughly twelve questions, with a progress bar — and explicitly says he does not want to test it himself. The agent builds the app, and even before being asked it takes screenshots of each page. Then, back in plan mode, Nate tells it to spin up a server, use its browser to fill in the fields and click through, note any bugs, and fix the site itself — in a headed browser so he can watch.
Watching live, the agent types a name, corrects itself, fills a phone number, picks options from dropdowns, and eventually glitches near the end. Rather than stop it, Nate lets it work. It shuts down, reviews the screenshots it captured during the run, and reports two real bugs: pressing enter on the notes text area didn't advance to the review step, and the review page never loaded (zero review items, an edit button intercepted by a stale overlay). It fixes those bugs, then — again unprompted — restarts the server and reruns the test. The second pass goes all the way through, the tests pass, and the agent ends the process.
"But literally every time that you use the script, it's going to get better."
Next Nate points it at the public web: search for dentists and capture phone numbers. He warns that the first attempt probably won't succeed — and that's the point. The instruction is to keep learning and updating the script until it's done. He steps away and comes back to a browser full of dentist offices and collected numbers. The interesting part is how it got there: Google blocked the automation, so the agent switched to DuckDuckGo by itself. On a second, more aggressive run ("don't stop until it finds five phone numbers") it grabs numbers off search results and, even when a number is already visible, still clicks through to each site's contact page.
"I literally stepped away to go get water and it actually I came back and I saw a browser open with some dentist offices up."
The question everyone asks: can this work where you have to be logged in? Nate has the agent lay out three approaches — a persistent browser profile using existing Chrome user data, a manual login handoff in headed mode, or connecting to an already-running browser — and picks the persistent-profile option. On the first run he logs in manually once; the session is saved so future launches are already authenticated. The task is to go into his Skool community's "wins" channel and like the posts.
It's not perfect at first: the agent likes and then unlikes posts, hits "liking too fast," and crashes during the page evaluation for the like action even though it correctly found the heart-shaped SVG buttons. Nate course-corrects in plan mode — the like button was being hit multiple times, and he explains how to sort the channel by newest and how to tell a post is liked (the thumbs-up turns yellow, not gray). After four or five iterations the script works: it sorts by newest, skips already-liked posts, and pages through the channel. The takeaway he stresses is that Skool is one of the least automation-friendly platforms, and it still worked.
"So the login persisted, it found the wins channel, it even found the heart-shaped SVG buttons, but it crashed during the page evaluate for liking."
Because the Playwright CLI automations can save cookies and stay logged in, Nate runs them as scheduled tasks from the Claude desktop app — chosen over Modal or Trigger because the scheduled runs behave agentically, walking through the browser like a live Claude Code session. He shows an autonomous "AIS agent" in his community that posts daily news roundups, responds to notifications, and once even made him a birthday post it wasn't told to make. These run headless in the background. He also notes the agent grows its own toolset: when it couldn't figure out how to vote on a poll, it worked out the clicks, turned that into a script, and updated its skill so it could vote autonomously next time.
Nate closes by noting Playwright CLI isn't the only option — there's Vercel's agent browser, "Open CLI," and others. The reason to use a CLI over an MCP is token savings, and when comparing CLIs the thing to weigh isn't raw speed but performance: how good the tool is at clicking around and, critically, learning to improve its script so it doesn't repeat mistakes. He's still testing alternatives but has been getting strong results from Playwright CLI.
"So, when you give a tool as powerful as Claude code, access to literally control a browser, if you think about it, you can actually automate anything."
"I literally stepped away to go get water and it actually I came back and I saw a browser open with some dentist offices up."
"it actually learned while it was going and it said that Google blocks the automation, so it switched to DuckDuckGo."
"But literally every time that you use the script, it's going to get better."
| Approx. Time | Topic |
|---|---|
| 0:00 | Intro — three browser-automation use cases |
| 0:40 | Installing Playwright CLI via plan mode |
| 1:20 | Why CLI over MCP — token cost of Chrome DevTools MCP |
| 2:40 | Use case 1: build a multi-page onboarding form |
| 5:00 | Automated QA — headed browser testing, bugs found |
| 7:00 | Self-fixing loop — test, validate, re-test until pass |
| 8:30 | Use case 2: searching for dentists, capturing phone numbers |
| 10:30 | Learning through failure — Google blocked, switch to DuckDuckGo |
| 12:00 | Use case 3: automating a logged-in Skool session |
| 14:30 | Course-correcting the like-posts script |
| 16:30 | Scheduled tasks and the autonomous "AIS agent" |
| 18:00 | Other CLIs and wrap-up |