BrowserBook
The Browser Automation IDE
230 followers
The Browser Automation IDE
230 followers
BrowserBook is an AI-powered IDE for building fast, reliable browser automations. It pairs a Jupyter-style notebook with a context-aware AI coding assistant and an inline browser, enabling developers to write, test, and debug automations all in one place. With built-in auth management, data extraction, screenshot tools, and API deployment, you can go from idea to production-ready automation in minutes, not hours.
Hooper
I've been waiting for an IDE that has an actual browser in it with the DOM. Despite all the LLM tools these days, I still spend so much time switching between the console, the browser, and vscode. Really cool to finally see it here!
BrowserBook
@mike_wu3 Thank you, Mike, these were exactly our thoughts when we were context-switching between claude code/cursor/browser as we were building our own automations.
We also think that documenting the intent of these automations will become more and more important as we start to focus on the maintenance aspect, hence the notebooks form factor with interleaved markdown!
BeerMe
I’ve been tinkering with BrowserBook since the alpha launch, and it’s been awesome. Writing browser automations used to be the worst. I either had to tediously write them by hand or use a non-deterministic browser agent. Browser book gives me the best of both, all the power of AI with all the reliability of hand written code. There are many more things I want to build with it. Super excited to see how everyone uses it. Congrats team!
BrowserBook
@gray_newfield Appreciate it Gray! We're always happy to help support any more automations you need to build!
Finally a tool for this that is not just a low-code drag and drop wrapper. Love the dev-first approach. How do you guys handle stuff like Cloudflare turnstiles or captchas in the inline browser?
BrowserBook
@govindsajit Thanks Govind!
In general, we see Cloudflare turnstiles/captchas are less of an issue in the inline browser, since it's just a Chrome instance running on your local machine; so a lot of the bot detection red flags you might get with headless/cloud-based browsers (e.g., user agent mismatches, known datacenter IPs, etc.) aren't there. When you do encounter captchas, the browser is fully interactive, so you can handle them manually.
Where you would handle these manually in the IDE, we use Kernel for remote browser infrastructure when running via API, and we leverage a lot of their anti-bot-detection capabilities to manage captchas/turnstiles on-the-fly.
🔥 Congrats on the launch — this hits a sweet operational nerve.
As a founder who lives knee-deep in back-office workflows, notarizations, banking funnels, and endless browser-based steps: this is the first automation IDE that actually feels built for the real world.
Most tools either give you:
no-code magic that collapses the moment a DOM element wiggles, or
full DIY Playwright hell where half the job is debugging selectors at 2am.
BrowserBook lands right in the middle — the craftsman’s bench, not the toy shop, not the steel factory.
Inline browser, deterministic scripts, and the “snapshot → API” flow make this genuinely production-ready.
Already seeing a dozen use cases inside our own ops:
banking flows
government portals
document retrieval
multi-step compliance checks
If you keep shipping at this pace, this becomes the go-to automation stack for any startup with messy browser workflows.
Well done. 👏
HYBRD
Congratulations on the launch, team! Excited to give this a whirl, it looks awesome.
BrowserBook
@hybrd_ben Thanks, Ben! We're looking forward to any and all feedback!!
Congrats on the launch! What's been the most popular use case so far?
HYBRD
Do you guys plan on doing anything at all with browser agents? I feel like they’re useful for adapting on the fly for intermittent things like popups or modals that would get in the way of a normal workflow
BrowserBook
@mats_terwiesch1 appreciate the question - we are exploring ways to bring agentic behavior into BrowserBook down the road, but for now we’re focused on making deterministic automation as smooth and reliable as possible.
You’re absolutely right and we think agents can really shine when dealing with intermittent UI issues like popups, modals, etc. Our view is that if/when we introduce browser agents, we want them to be purpose-built for those specific classes of problems, not a catch-all layer that adds unpredictability to every workflow.
Regardless of the automation approach someone uses (scripts vs agents), DOM changes and breakages will always happen. Where we see a big opportunity (and what we're working on now) is making that recovery process dramatically better through things like self-healing notebooks, which can understand errors and the context that caused them, and generate fixes on-the-fly.
In other words: letting scripts stay deterministic, but giving users agentic tools to automatically resolve the “unknown unknowns.”
Totally appreciate you bringing this up, this is definitely a direction we’re excited about, but we want to introduce it thoughtfully.