Live data from Hacker News

Show HN: Stagehand – an open source browser automation framework powered by AI

github.com

31–40 of 89 posts

Re: Show HN: Stagehand – an open source browser automation framework powered by AI

#31
post #6

This looks very cool and makes a lot of sense, except for the idea that it should take the place of Playwright et al. Personally I'd love to use this as an intermediate workflow for producing deterministic playwright code, but it looks like this is intended for running directly. I don't think I could plausibly argue for using LLMs at runtime in our test suite at work...

It's funny you mentioned "deterministic Playwright code," because in my experience, that’s one of the most frustrating challenges of writing integration tests with browser automation tools. Authoring tests is relatively easy, but creating reliable, deterministic tests is much harder.

Most of my test failures come down to timing issues—CPU load subtly affects execution, leading to random timeouts. This makes it difficult to run tests both quickly and consistently. While proactive load-testing of the test environment and introducing artificial random delays during test authoring can help, these steps often end up taking more time than writing the tests themselves.

It would be amazing if tools were smart enough to detect these false positives automatically. After all, if a human can spot them, shouldn’t AI be able to as well?

Re: Show HN: Stagehand – an open source browser automation framework powered by AI

#32
Cool to see another open source AI browser testing project! There’s a couple of others I’ve heard of as well:

Skyvern: https://github.com/Skyvern-AI/skyvern

Shortest: https://github.com/anti-work/shortest

I’d love to hear what makes Stagehand different and pros/ cons.

Of course, I have no complaints to see more competition and open source work in this space. Keep up the great work!

Re: Show HN: Stagehand – an open source browser automation framework powered by AI

#34
post #26

This looks awesome. What I would love to see either as something leveraging this, or built in to this, is if you prompt stagehand to extract data from a page, it also returns the xpath elements you'd use to re-scrape the page without having to use an LLM to do that second scraping. So basically, you can scrape new pages never before seen with the non-deterministic LLM tool, and then when you need to rescrape the page…

Agree. The worst part of integration tests are how brittle they often are. I don't want to introduce yet another thing that could give false test errors.

But of course, the way it works now could also help reduce the brittleness. With an xpath or selector, it quickly breaks when the design changes or things are moved around. With this, it might overcome this.

So tradeoffs, I guess.

Re: Show HN: Stagehand – an open source browser automation framework powered by AI

#35
post #26

This looks awesome. What I would love to see either as something leveraging this, or built in to this, is if you prompt stagehand to extract data from a page, it also returns the xpath elements you'd use to re-scrape the page without having to use an LLM to do that second scraping. So basically, you can scrape new pages never before seen with the non-deterministic LLM tool, and then when you need to rescrape the page…

there’s also llm-scraper: https://github.com/mishushakov/llm-scraper

disclaimer: i am the author

Re: Show HN: Stagehand – an open source browser automation framework powered by AI

#36
post #6

This looks very cool and makes a lot of sense, except for the idea that it should take the place of Playwright et al. Personally I'd love to use this as an intermediate workflow for producing deterministic playwright code, but it looks like this is intended for running directly. I don't think I could plausibly argue for using LLMs at runtime in our test suite at work...

Hi! Kosta from Octomind here.

We built basically this: Let an LLM agent take a look at your web page and generate the playwright code to test it. Running the test is just running the deterministic playwright code.

Of course, the actual hard work is _maintaining_ end-to-end tests so our agent can do that for you as well.

Feel free to check us out, we have a no-hassle free tier.

Re: Show HN: Stagehand – an open source browser automation framework powered by AI

#37
post #26

This looks awesome. What I would love to see either as something leveraging this, or built in to this, is if you prompt stagehand to extract data from a page, it also returns the xpath elements you'd use to re-scrape the page without having to use an LLM to do that second scraping. So basically, you can scrape new pages never before seen with the non-deterministic LLM tool, and then when you need to rescrape the page…

Yeah, I think someone opened a similar issue on GitHub: https://github.com/browserbase/stagehand/issues/389 Repeatability of extract() is definitely super interesting and something we're looking into

Cache the response for a given query-page hash pair maybe? So the LLM will only be consulted when the page content hash changes, the previous answer be reused otherwise

Re: Show HN: Stagehand – an open source browser automation framework powered by AI

#38

Does this open up the possibility of automating an existing open browser tab? (Instead of a headless or specifically opened instance of chrome?)

Afaik no. But if it's access to authenticated resources that you want, you can do so by copying over cookies.

Re: Show HN: Stagehand – an open source browser automation framework powered by AI

#40

Earlier quoted context omitted.

The purpose of using Playwright is to basically write deterministic workflows in deterministic automation code. We have basic prompt caching right now that works if the DOM doesn't change (as you mention), but also the best way to reduce token cost is to reduce reliance on AI itself. You have the most control over how much you want to rely on AI v. how much you want to write repeatable Playwright code.

That seems like a pretty tough sell over bare playwright. Unless the UI is constantly changing, the cost of verifying tests are still successful seems like it would eclipse the cost of an engineer maintaining the test pretty quickly. Some minimal model that could be run locally and specifically tuned for this purpose might be pretty fruitful here compared to delegating out to expensive APIs.

I think a hybrid solution where you use AI if the X path fails or if the test as a whole fails would be ideal. Then cache the results and use them until it fails again.
Post reply on HN