Show HN: ProofShot – Give AI coding agents eyes to verify the UI they build (github.com)

161 points by jberthom ↗ HN
I use AI agents to build UI features daily. The thing that kept annoying me: the agent writes code but never sees what it actually looks like in the browser. It can’t tell if the layout is broken or if the console is throwing errors.

So I built a CLI that lets the agent open a browser, interact with the page, record what happens, and collect any errors. Then it bundles everything — video, screenshots, logs — into a self-contained HTML file I can review in seconds.

  proofshot start --run "npm run dev" --port 3000
  # agent navigates, clicks, takes screenshots
  proofshot stop
It works with whatever agent you use (Claude Code, Cursor, Codex, etc.) — it’s just shell commands. It's packaged as a skill so your AI coding agent knows exactly how it works. It's built on agent-browser from Vercel Labs which is far better and faster than Playwright MCP.

It’s not a testing framework. The agent doesn’t decide pass/fail. It just gives me the evidence so I don’t have to open the browser myself every time.

Open source and completely free.

Website: https://proofshot.argil.io/

93 comments

[ 2.6 ms ] story [ 107 ms ] thread
Great to see this but exe.dev (not sponsored but they are pretty cool and I use them quite often, if they wish to sponsor me that would be awesome haha :-]) actually has this functionality natively built in.

but its great to see some other open source alternatives within this space as well.

what about mcp cdp ?

my claude drive his own brave autonomously, even for ui ?

Looks nice! Does it work for desktop applications as well, or is this only web dev?
Web only for now. It runs headless Chromium under the hood. Desktop and mobile are the #1 request. Mobile path would be iOS Simulator or Android emulator integration. Desktop would need accessibility APIs or OS-level screenshot capture. It’s on the roadmap. Feel free to leave an issue on the repo if that's critical for you
Taking screenshots and recording is not quite the same as "seeing". A camera doesn't see things. If the tool can identify issues and improvements to make, by analyzing the screenshot, that's I think useful.
What does this do that playwright-cli doesn't?

https://github.com/microsoft/playwright-cli

Maker here. Playwright is great, I use it too. The difference is really about who’s driving. ProofShot is meant for agents that just need shell commands, start to open the browser and begin recording, exec to interact with the page, stop to bundle everything up. You get video, screenshots, console errors, server logs, and an interactive HTML viewer in one artifacts folder you can drop on a PR with proofshot pr. With Playwright the agent needs to write a test script, run it, collect screenshots, parse output separately… it’s a lot of glue code. Also agent-browser’s element references are ~93% smaller than Playwright’s accessibility tree, which adds up when you’re paying per token.
> With Playwright the agent needs to write a test script, run it, collect screenshots, parse output separately… it’s a lot of glue code.

It most certainly does not require any glue code. Playwright cli gives you basically all of this out of the box.

https://github.com/microsoft/playwright-cli?tab=readme-ov-fi...

ProofShot isn’t a Playwright alternative, it’s built on agent-browser (from Vercel Labs), which is a different runtime. The value isn’t “can control a browser” — playwright does that fine, and in fact agent-browser is built on top of Playwright, hence so is ProofShot :) The value is bundling video + screenshots + console errors + server logs + action timeline into a single viewer.html and uploading it to the PR. That’s what saves me review time. If your workflow doesn’t need that bundle, playwright-cli works great.
This is basically what antigravity (Google’s Windsurf) ships with. Having more options to add this functionality to Open code / Claude code for local models is really awesome. MIT license too!
How would this play with mobile apps?

I'd love to see an agent doing work, then launching app on iOS sim or Android emu to visually "use" the app to inspect whether things work as expected or not.

I'm going the opposite of everyone else is saying.

This is sick OP based on what's in the document, it looks really useful when you need to quickly fix something and need to validate the changes to make sure nothing has changed in the UI/workflow except what you have asked.

Also looks useful for PR's, have a before and after changed.

Thanks! Yeah the before/after PR thing is exactly what proofshot pr is built for.
I'm currently experimenting with running a web app "headless" in Node.JS by implementing some of the DOM JS functions myself. Then write mocks for keyboard input, etc. Then have the code agent run the headless client which also starts the tests. In my experience the coding agents are very bad at detecting UX issues, they can however write the tests for me if I explain what's wrong. So I'm the eye's and it's my taste, the agent writes the tests and the code.
I use AI agents to build UI features daily. The thing that kept annoying me: the agent writes code but never sees what it actually looks like in the browser. It can’t tell if the layout is broken or if the console is throwing errors.

I give agent either a simple browser or Playwright access to proper browsers to do this. It works quite well, to the point where I can ask Claude to debug GLSL shaders running in WebGL with it.

Do you use Chrome DevTools MCP or how does it work?
Likewise, and often the playwright skill will verify using DOM API instead of wasting tokens on screenshots
+1

All the power to you if you build a product out of this, I don't wanna be that guy that says that dropbox is dead because you can just setup ftp. But with Codex/Claude Code, I was able to achieve this very result just from prompting.

I mean, this is a free and open source project, so I don't think they're trying to make it into a product
Agreed. Anthropic added a plugin accessible under `/plugins` to CC to make it even easier to add MCP Playwright to your project. It automatically handles taking screenshots.

It's not perfect though - I've personally found CC's VL to be worse than others such as Gemini but its nice to have it completely self contained.

This project desperately needs a "What does this do differently?" section because automated LLM browser screenshot diffing has been a thing for a while now.

Fair point, clearly the first question everyone has. Will add a comparison section to the README.
Gemini on Antigravity is already doing this.
I find the official Chrome DevTools MCP excellent for this. Lighter than Playwright, the loop is shorter, and easy to jam into Electron too.
chrome devtools mcp really clutters your context. Playwright-cli (not mcp) is so much more efficient.
DevTools MCP is great for live debugging in the moment. ProofShot is more about generating a proof bundle after the fact, something you can review on a PR without having been there when the agent ran. Different use cases I think.
This would be _extremely_ valuable for desktop dev when you don't have a DOM, no "accessibility" layer to interrogate. Think e.g. a drawing application. You want to test that after the user starts the "draw circle" command and clicks two points, there is actually a circle on the screen. No matter how many abstractions you make over your domain model, rendering you can't actually test that "the user sees a circle". You can verify your drawing contains a circle object. You can verify your renderer was told to draw a circle. But fifty things can go wrong before the user actually agrees he saw a circle (the color was set to transparent, the layer was hidden, the transform was incorrect, the renderer didn't swap buffers, ...).
I had claude build a backdoor command port in the Godot application I'm working on. Using commands, Claude can interact with the screen, dump the node tree, and take screen shots. It works pretty well. Claude will definitely iterate over layout issues.
Have you written this up anywhere? I have dropped my projects due to work/family commitments but see this as potentially removing some of the friction involved.
Yes agree. Web only for now since it runs on headless Chromium. Desktop and mobile are the #1 request though. For mobile the path would be driving an iOS Simulator or Android emulator. For native desktop, probably accessibility APIs or OS-level screenshots. Definitely on my radar, will see if anyone wants to contribute since I am doing this on my free time.
This is really cool. Have you thought of maybe accessing the screen through accessibility APIs? For Android mobile devices I have a skill I created that accesses the screen xml dump as part of feature development and it seems to work much better than screenshots / videos. Is this scalable to other OS's?
Yes for now focused on web but accessibility tree dumps seems like a good alternative to screenshots for native apps. For web, agent-browser already uses compact element refs, but for mobile the a11y approach could be way more efficient. Would you be open to sharing more about how you set that up?
I've always found screenshots on PRs incredibly helpful as a reviewer. Historically I've had mixed success getting my team to consistently add screenshots to PRs, so this tool would be helpful even for human code.

At work, we've integrated claude code with gitlab issues/merge requests, and we get it to screenshot anything it's done. We could use the same workflow to screenshot (or in this case, host a proofshot bundle of) _any_ open PR. You would just get the agent to check out any PR, get proofshot to play around with it, then add that as a comment. So not automated code reviews, which are tiresome, but more like a helpful comment with more context.

Going to try out proofshot this week, if it works like it does on the landing page it looks great.

Yes exactly. I'm actively maintaining it so if you miss anything just drop an issue on Github and I'll look into it
That is not UI, that's just some web pages with JS.
I've been using playwright-cli (not mcp) for this same purpose. It lacks the video feature, I guess. But at least is local and without external dependencies on even more third parties (in your case, vercel). Perhaps you could allow to use a local solution as an alternative as well?
agent-browser runs locally (it’s a Rust CLI + Node daemon on your machine), so there’s no cloud dependency on Vercel, it’s just built by the Vercel Labs team. Everything stays local :)
Thanks! I do share screenshots and paste them manually for front end stuff, nice idea though.
I use the Claude Chrome extension for this. Works wonderfully. It lets Claude click through features itself, etc.
I am fed up of getting gaslit by coding assistants. "Your AI agent says it's done." really is a problem! Nice packaging here.

I built something similar[0] a few months ago but haven't maintained it because Codex UI and Cursor have _reasonable_ tooling for this themselves now IMO.

That said there is still a way to go, and space for something with more comprehensive interactivity + comparison.

[0] - https://magiceyes.dev/

I usually ask Claude Code to setup a software stack that can build/run whatever I am working on. Then I let it browse a website or navigate through screens. I also use Playwright to get screenshots of the website I am building. For e.g. apps or whatever application you are building, there should be a way to get screenshots too I guess.

Added benefit is that when Claude navigates and finds a bug, it will either add them to a list for human review or fix it automatically.

Pretty much a loop where building and debugging work together;-)

Once Claude Code

This is actually interesting. Feels like we’re moving from “generate UI” to “validate UI,” which is a completely different problem. Curious how you handle edge cases where something looks correct but breaks in interaction?
The agent drives interactions through proofshot exec — clicks, typing, navigation and each action gets logged with timestamps synced to the video. So in the viewer you can scrub through and click on action markers to jump to specific moments. It captures what happened during interaction, not just what the page looked like at rest. I had recordings where the agent struggled (for instance when having to click toggle buttons). It was fascinating to watch, the agent just tried again and again like a toddler figuring out how to use a keyboard and after 3 tries figured it out on his/her own (trying not to misgender the babies of future AGI).