← Back to context

Comment by embedding-shape

6 hours ago

Btw, after I wrote that initial article ("Cursor's latest "browser experiment" implied success without evidence"), I gave it my own try to write a browser from scratch with just one agent, using no 3rd party crates, only commonly available system libraries, and just made a Show HN about it: https://github.com/embedding-shapes/one-agent-one-browser

11 comments

embedding-shape

Reply
simonw  6 hours ago

This project is awesome - it really does render HTML+CSS effectively using 20,000 lines of dependency-free Rust (albeit using system libraries for image rendering and fonts).

Here's a screenshot I took with it: https://bsky.app/profile/simonwillison.net/post/3mdg2oo6bms2...

noosphr  5 hours ago

Yes, this is what Ai assisted coding is good at.

A poc that would usually take a team of engineers weeks to make because of lack of cross disciplinary skills can now be done by one at the cost of long term tech debt because of lack of cross disciplinary knowledge.

  • embedding-shape  3 hours ago

    > Yes, this is what Ai assisted coding is good at.

    This is where I wish we spent more energy, figuring out better ways to work with the AI, rather than trying replace some parts wholesale with AI. Wrote a bunch more specifically about that, while I was watching the agent work on the browser itself, here: https://emsh.cat/good-taste/ (it's like a companion-piece I guess)

dwroberts  5 hours ago

Would be interested to know what people think of the locking implementation for the net worker pool.

I’m no expert but it seems like a strange choice to me - using a mutex around an MPSC receiver, so whoever locks first gets to block until they get a message.

Is that not introducing unnecessary contention? It wouldn’t be that hard to just retain a sender for each worker and just round robin them

  • comex  3 hours ago

    I haven’t looked at the code, but what you’re describing doesn’t sound that bad. If the queue is empty then it doesn’t matter whether a worker is waiting on the lock or waiting on the receiver itself. If the queue is non-empty then whoever has the lock will soon complete the receive and release the lock. It would be better to just use an actual MPMC channel, but if the traffic on the queue isn’t too high then it probably doesn’t make a significant difference. With round robin in contrast, the sender would risk sending a job to a worker that was already busy, unless it took additional measures to avoid that.

  • storystarling  2 hours ago

    I suspect this is just an LLM hallucinating generic thread-safety boilerplate. In an async serverless runtime like Workers this pattern creates blocking risks and doesn't actually solve the distributed consistency problem.