AGI was just 1 bash for loop away all this time I guess. Insane project.
Readit Newsgregpr07 commented on We put a coding agent in a while loop github.com/repomirrorhq/r... · Posted by u/sfarshid
gregpr07 commented on Closer to the Metal: Leaving Playwright for CDP browser-use.com/posts/pla... · Posted by u/gregpr07
re: ms -- thank you for calling that out. i've been thinking we had been collectively sleepwalking into ms owning everything (again). they've owned everything once before -- it wasn't great!
related side-note: have you had to interact with the core chrome / cdp devs?
re side-note: if you know anyone who would be willing to interact connect me :)
gregpr07 commented on Closer to the Metal: Leaving Playwright for CDP browser-use.com/posts/pla... · Posted by u/gregpr07
direct CDP has been used by the scraping community for a long time in order to have a cleaner browser environment that is harder to fingerprint. for example nodriver (https://github.com/ultrafunkamsterdam/nodriver) was started in Feb 2024 and I suspect this technique was popular before that project started.
I really like both nodriver and pydoll. I am definitely keeping the option of switching to them open, but we just wanted to have full control for now and see how painful CDP-use is to maintain first and then reconsider.
gregpr07 commented on Closer to the Metal: Leaving Playwright for CDP browser-use.com/posts/pla... · Posted by u/gregpr07
Exactly what I was thinking. Instead of attempting to contribute back to Playwright to fix those hangups, or even creating a private patch to do so as a POC, they went right to building their own framework from scratch.
That isn't how you launch a product.
I mean... Playwright was built and is maintained by Microsoft, so I don't think VC money argument really makes sense here.
By the very nature of how Playwright is built we can't contribute to it - it runs inside a JS subprocess and does not expose a bunch of CDP apis that we NEED (for example to make cross origin iframes work).
gregpr07 commented on Closer to the Metal: Leaving Playwright for CDP browser-use.com/posts/pla... · Posted by u/gregpr07
gregpr07 commented on Closer to the Metal: Leaving Playwright for CDP browser-use.com/posts/pla... · Posted by u/gregpr07
Care to share your thoughts on muscle-mem, the recent, related "meta-tool" for caching "agent trajectories"? https://github.com/pig-dot-dev/muscle-mem
I think it's awesome (we are close friends with Erik from Pig so slightly biased) - one extreme is Browser Use, which is just an agent that does everything for the first time, the other extreme is Workflow Use, which is almost deterministic. I think the winner product lies somewhere in the middle - Browser Use + Cache is easier to do for browser trajectories than for pure images! We will definitely try this direction!
Very cool.
1) How do you deal with timings? If a step includes clicking on a link or something that needs loading, then if you just fire off the generated playwright code at at once, some steps might fail because the xpath is not there yet. So to be safe, i'm guessing you would have to wait using the difference in the timestamps in the json.
2. For self healing, we worked on something similar, and we found it's very easy to get off the rails if one step fails because if your assertions of if the fix was correct are off, then the next and next steps will also fail etc. The most stable way was to just regenerate all steps if a step fails in 2 attempts (2 runs of the flow) consecutively. If the xpath is broken for a step, very likely the subsequent ones won't be worth healing individually.
1) we made this sick function in browser use library which analyses when there are no more requests going through - so we just reuse that!
2) yeah good question. The end goal is to completely regenerate the flow if it breaks (let browser use explore the “new” website and update the original flow). But let’s see, soo much could be done here!
What did you work on btw?