Show HN: Libretto – Making AI browser automations deterministic
Here’s a demo: https://www.youtube.com/watch?v=0cDpIntmHAM. Docs start at https://libretto.sh/docs/get-started/introduction.
We spent a year building and maintaining browser automations for EHR and payer portal integrations at our healthcare startup. Building these automations and debugging failed ones was incredibly time-consuming.
There’s lots of tools that use runtime AI like Browseruse and Stagehand which we tried, but (1) they’re reliant on custom DOM parsing that's unreliable on older and complicated websites (including all of healthcare). Using a website’s internal network calls is faster and more reliable when possible. (2) They can be expensive since they rely on lots of AI calls and for workflows with complicated logic you can’t always rely on caching actions to make sure it will work. (3) They’re at runtime so it’s not interpretable what the agent is going to do. You kind of hope you prompted it correctly to do the right thing, but legacy workflows are often unintuitive and inconsistent across sites so you can’t trust an agent to just figure it out at runtime. (4) They don’t really help you generate new automations or help you debug automation failures.
We wanted a way to reliably generate and maintain browser automations in messy, high-stakes environments, without relying on fragile runtime agents.
Libretto is different because instead of runtime agents it uses “development-time AI”: scripts are generated ahead of time as actual code you can read and control, not opaque agent behavior at runtime. Instead of a black box, you own the code and can inspect, modify, version, and debug everything.
Rather than relying on runtime DOM parsing, Libretto takes a hybrid approach combining Playwright UI automation with direct network/API requests within the browser session for better reliability and bot detection evasion.
It records manual user actions to help agents generate and update scripts, supports step-through debugging, has an optional read-only mode to prevent agents from accidentally submitting or modifying data, and generates code that follows all the abstractions and conventions you have already in your coding repo.
Would love to hear how others are building and maintaining browser automations in practice, and any feedback on the approach we’ve taken here.
- alexbike - 6092 sekunder sedanThe network-request-first approach is the right call. DOM parsing is fragile because it's scraping a rendering artifact — any style refactor, framework upgrade, or A/B test can silently break it. Intercepting the actual API calls the browser is already making is closer to testing the contract, not the presentation.
The healthcare context makes this especially sharp. Those portals are notoriously inconsistent and rarely built for automation. Would be curious how you handle cases where the app uses WebSockets or chunked responses instead of clean REST calls.
- etwigg - 8875 sekunder sedanThanks for this! We have clear answers for things that are 100% and 0% automated, but it’s always that 80%-99% automated slice where the frontier is, great idea.
- seagull - 11374 sekunder sedanI've wanted something like this for ages, excited to try this out!
- messh - 12359 sekunder sedanhow does it differ from playwright-cli?
- gbibas - 9525 sekunder sedanCool. Thank you for sharing. While AI tools are extremely powerful, packages like this help create some good standards and stepping stones for connectivity that the models haven’t gotten around to yet. Thanks again.
- arpadav - 9116 sekunder sedanthis looks awesome
- devstatic - 12499 sekunder sedanthis is interesting
- KaiShips - 6276 sekunder sedan[dead]
- - 10539 sekunder sedan
- surgical_fire - 9886 sekunder sedanFor a moment I throught it was something about libretro. As an avid RetroArch user the headline picked my interest.
Then I clicked and realized it's just some other AI shit.
Nördnytt! 🤓