How do you give a browser to an AI coding agent?
Short answer: you give an AI coding agent a browser in one of three ways: a browser automation MCP server (Chrome DevTools MCP or Playwright MCP), browser tests in your own stack (Pest, Playwright), or an app with a browser embedded per agent, such as CanvasCode. Whichever path you pick, the reason is the same: an AI coding agent that only reads code is deducing the visual result, and layout deduction gets it wrong.
What an AI agent cannot see by reading code alone
CSS does not execute in anyone's head: cascade, specificity, narrow viewports, real content longer than sample content. An AI agent reads the diff, the diff looks right, and the page has the menu overlapping the title on mobile. In a real case on this site, a width overflow on mobile survived three rounds of blind fixing, with the agent rereading code and declaring it solved; in the first round where the agent took a screenshot, the bug closed. The house rule became: a visual bug only closes after being seen.
The screenshot shows the layout, the console shows the error
The screenshot answers "how it looks": overflowing elements, clipped text, a button out of place. The console answers "why": the JavaScript error that broke rendering never shows in the picture, only in the log. An AI agent equipped with both closes the loop alone: a strange screenshot leads to the console, the console points to the error, the error becomes a fix, a new screenshot confirms. Without the full pair, half of the diagnoses become guesses.
How do you give a browser to an AI coding agent?
Three paths. Browser automation over MCP (Chrome DevTools MCP, Playwright MCP): works with any CLI, requires configuring an MCP server per project. Browser tests in your own stack (Pest, Playwright): great for regression, less so for exploration. Or an app with an embedded browser per agent: in CanvasCode, each AI agent has its own browser on the canvas, which opens the page, clicks, types, scrolls, reads the console and hands the screenshot back to the agent, with no per-project setup. The right path depends on how visual your work is.
What changes in the workflow when the agent can see the screen
The stopping point changes. Without a browser, the AI agent stops at "I edited the files"; visual verification falls to you, and the back-and-forth (you look, you describe the problem, the agent tries again) takes longer than the fix itself. With a browser, the agent stops at "I looked and it is right", and your review starts from a screen that has already been checked once. The gain is not the screenshot: it is the back-and-forth that stops existing.
Does the same apply to native apps?
Partly. For the web, an embedded browser solves the whole problem. For native apps (SwiftUI, for example), the equivalent is capturing the simulator screen, which works but with more friction: slower builds, navigating to the right screen, no JavaScript console. Honesty requires saying it: the screenshot-console loop is a web-specific advantage, and that is where an AI agent with a browser pays off most.
What are the limits of letting an agent browse?
Two that matter. Cost: every screenshot enters the model's context as an image, and a long visual session burns tokens noticeably faster than text. Safety: an agent that clicks needs clear limits in logged-in areas and on destructive actions (paying, deleting, publishing); the sensible default is browsing freely in a local environment and asking for human confirmation outside it. Neither limit cancels the gain; both ask for the browser to come with rules.