Launch HN: BrowserBook (YC F24) – IDE for deterministic browser automation
14 comments
·December 11, 2025jackconsidine
Congrats on the launch
Please port to linux soon (sure it's relatively trivial on Electron :)).
Like the idea of the IDE. Seems like it'd make it easy to prototype and launch quickly.
RE: embrace the suck, yeah I'm with you. I prefer the brittleness of scripts to non-deterministic (potentially unhinged) workflows
cschlaepfer
Thanks! Yep, linux is coming soon - now that we have the first version of the IDE out the door we're going to get cross-platform going shortly.
doomerhunter
Interesting. Quick question in regards to the code generation : Do you dump the DOM to provide relevant context to build the automation or does the agent automatically tries to discover relevant segments (like a claude code) ?
Edit : Answered in the video, dump of a simplified version of the DOM. How is the discovery of the rest is performed ?
Super nice, can really see the use cases, even for security testing.
cschlaepfer
Appreciate it!
Yes exactly - today we send it a simplified version of the DOM, but we're currently building an agent which will be able to discover the relevant DOM elements.
timerol
> only available for Mac so far, sorry!
Is there a plan to change this? Building on Electron should make it manageable to go cross-platform. 2026 will be the year of the Linux desktop, as the prophecies have long foretold.
Off-topic, but Kernel refers to https://www.onkernel.com. A bit of an awkward name
jorrie
Yes! Going cross-platform is on the roadmap, but right now we're focused on building out the feature set and improving the form factor.
Also yeah, Kernel refers to onkernel - they call it that because they're running the browsers in a unikernel. They're a great product and you should give them a look if you need hosted browsers!
koakuma-chan
Why would something be only available for Mac? What are they using?
poly2it
I feel like I've seen a product similar to this quite recently on HN, but it was a standalone agentic workflow which was open source on GitHub. I can't seem to find it right now. Does anyone know what I'm referring to?
jasonjmcghee
There have been a bunch
https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...
huntaub
This is a super interesting product, guys. I get that agents aren't great for everything right now, but I'd expect that they'll continue to improve over time (like everything in the LLM space).
How do you see the product evolving as agents become better and better?
cschlaepfer
Thanks, and great question - we think about this a lot and think there are a couple of things here.
First, as models get better, our agent's ability to navigate a website and generate accurate automation scripts will improve, giving us the ability to more confidently perform multi-step generations and get better at one-shotting automations.
We expect browser agents will improve as well, which I think is more along the lines of what you're asking. At scale, we still think scripts will be better for their cost, performance, and debuggability aspects - but there are places where we think browser agents could potentially fit as an add-on to deterministic workflows (e.g., handling inconsistent elements like pop-ups or modals). That said, if we do end up introducing a browser agent in the execution runtime, we want to be very opinionated about how it can be used, since our product is primarily focused on deterministic scripting.
huntaub
> At scale, we still think scripts will be better for their cost, performance, and debuggability aspects
This actually makes a ton of sense to me in lots of the LLM contexts (e.g. seeing how we are starting to prefer having LLMs write one-off scripts to do API calls rather than just pointing them at problems and having them try it directly).
Thanks!
smt88
Agents have plateaued and will never be as good as deterministic code for browser automation. It's a fundamental issue with the way LLMs work.
null
Hey HN! We’re Chris, Jorrie, and Evan of BrowserBook, an IDE for writing and debugging Playwright-based web automations. You can download it as a Mac app here: https://browserbook.com, and there’s a demo video at https://www.youtube.com/watch?v=ODGJBCNqGUI.
Why we built this: When we were going through YC, we were a company that automated back-office healthcare workflows. Since the interoperability ecosystem in healthcare is so fragmented, we started using browser agents to automate EMRs, practice management software, and payment portals directly through the web. When we did, we ran into a ton of problems:
Speed: High latency on LLM calls vs. a scripting approach
Cost: We burned through tokens with all the context we needed to make the automations reasonably accurate
Reliability: Even with detailed instructions, context, and tools, agents tended to drift on multi-step tasks in unpredictable ways
Debuggability: When drift did occur, we were essentially playing whack-a-mole in our prompt and re-running the whole automation to debug issues (see above: speed and cost issues made this quite painful)
More and more we were just giving our agent scripts to execute. Eventually, we came to the conclusion that scripting is a better approach for web automation for these sort of use cases. But scripting was also too painful, so we set out to solve those problems with BrowserBook.
Under the hood, it runs a standalone TypeScript REPL wired directly into an inline browser instance, with built-in tooling to make script development quick and easy. This includes:
- A fully interactive browser window directly in the IDE so you can run your code without context switching
- A Jupyter-notebook-style environment - the idea here is you can write portions of your automation in individual cells and run them individually (and quickly reset manually in the browser), instead of having to rerun the whole thing every time
- An AI coding assistant which uses the DOM context of the current page to write automation logic, which helps avoid digging around for selectors
- Helper functions for taking screenshots, data extraction, and managed authentication for auth-required workflows.
Once you’ve created your automation, you can run it directly in the application or in our hosted environment via API, so you can use it in external apps or agentic workflows.
At its core, BrowserBook is an Electron app, so we can run a Chrome instance directly in the app without the need for cloud-hosted browsers. For API runs, we use hosted browser infra via Kernel (which is a fantastic product, btw), relying on their bot anti-detection capabilities (stealth mode, proxies, etc.).
Scripted automation can be unpopular because scripts are inherently brittle; unlike “traditional” software development, your code is deployed in an environment you don’t control - someone else’s website. With BrowserBook, we’re trying to “embrace the suck”, and acknowledge this “offensive programming” environment.
We’ve designed from the ground up to assume scripts will break, and aim to provide the tools that make building and maintaining them easier. In the future, our plan is to leverage AI where it has shown its strength already - writing code - to minimize downtime and quickly repair broken scripts as the deployed environment changes.
Browser agents promised to solve this by handing the reins to an LLM which can handle inconsistency and ambiguity. While we think there are some applications where browser agents can be genuinely helpful, tasks that need to be done reliably and repeatedly are not one of them.
We’d love for you to try it out! You can download BrowserBook from our website here: https://browserbook.com (only available for Mac so far, sorry!) And of course, we’d appreciate any feedback and comments you have!