[HN Gopher] Show HN: One Human + One Agent = One Browser From Sc...
       ___________________________________________________________________
        
       Show HN: One Human + One Agent = One Browser From Scratch in 20K
       LOC
        
       Related: https://simonwillison.net/2026/Jan/27/one-human-one-agent-
       on...
        
       Author : embedding-shape
       Score  : 117 points
       Date   : 2026-01-27 13:13 UTC (9 hours ago)
        
 (HTM) web link (emsh.cat)
 (TXT) w3m dump (emsh.cat)
        
       | embedding-shape wrote:
       | I set some rules for myself: three days of total time, no 3rd
       | party Rust crates, allowed to use commonly available OS
       | libraries, has to support X11/Windows/macOS and can render some
       | websites.
       | 
       | After three days, I have it working with around 20K LOC, whereas
       | ~14K is the browser engine itself + X11, then 6K is just
       | Windows+macOS support.
       | 
       | Source code + CI built binaries are available here if you wanna
       | try it out: https://github.com/embedding-shapes/one-agent-one-
       | browser
        
         | jacquesm wrote:
         | Those are excellent constraints.
        
         | chatmasta wrote:
         | Did you use Claude code? How many tokens did you burn? What'd
         | it cost? What model did you use?
        
           | embedding-shape wrote:
           | Codex, no idea about tokens, I'll upload the session data
           | probably tomorrow so you could see exactly what was done. I
           | pay ~200 EUR/month for the ChatGPT Pro plan, prorating days I
           | guess it'll be ~19 EUR for three days. Model used for
           | everything was gpt-5.2 with reasoning effort set to xhigh.
        
             | soiltype wrote:
             | Thank you in advance for that! I barely use AI to generate
             | code so I feel pretty lost looking at projects like this.
        
             | forgotpwd16 wrote:
             | >I'll upload the session data probably tomorrow so you
             | could see exactly what was done.
             | 
             | That'll be dope. The tokens used (input,output,total) are
             | actually saved within codex's jsonl files.
        
             | storystarling wrote:
             | That 19 EUR figure is basically subscription arbitrage. If
             | you ran that volume through the API with xhigh reasoning
             | the cost would be significantly higher. It doesn't seem
             | scalable for non-interactive agents unless you can stay on
             | the flat-rate consumer plan.
        
         | bhadass wrote:
         | very impressive!
         | 
         | it's amazing how far we've come in 20 years. i was a (very
         | minor) contributor to khtml/konqueror (before apple got
         | involved w/ webkit) in the early 2000s, and back then it was
         | such a labor intensive process to even create a halfway working
         | engine. like, months of work just to get basic rendering
         | somewhat correct on a very small portion of the web (which was
         | obv much smaller)
         | 
         | in addition to agentic coding, i think for this specific task
         | having css-spec/html-spec/web-platform-tests as machine
         | readable test suites helps a LOT. the agent can actually
         | validate against real specs.
         | 
         | back in the day, despite having gecko as an open source
         | reference, in practice the "standards" were whatever IE was
         | doing. so you'd spend weeks implementing something only to
         | discover every site was coded for IE's quirks lmao. for all of
         | their other faults, google/apple and other contributors helped
         | bring in discipline to that.
        
           | embedding-shape wrote:
           | > i think for this specific task having css-spec/html-
           | spec/web-platform-tests as machine readable test suites helps
           | a LOT
           | 
           | You know, I placed the specs in the repository with that goal
           | (even sneaked in a repo that needs compiling before being
           | usable), but as far as I can see, the agent never actually
           | peeked into that directory nor read anything from them in the
           | end.
           | 
           | It'll be easier to see once I made all the agent sessions
           | public, and I might be wrong (I didn't observe the agent at
           | all times), but seems the agent never used though.
        
             | bhadass wrote:
             | oh interesting, so it just... didn't use them? lol. i guess
             | the model's training data already has enough web knowledge
             | baked in that it could wing it. curious if explicitly
             | prompting it to reference the specs would change the output
             | quality or time to solution.
             | 
             | very excited to see the agentic sessions when you release
             | them.. that kind of transparency is super valuable for the
             | community. i can see "build a browser from scratch"
             | becoming a popular challenge as people explore the limits
             | of agentic coding and try to figure out best practices for
             | workflows/prompting. like the new "build a ray tracer" or
             | say nanogtp but for agents.
        
       | simonw wrote:
       | This is a notably better demonstration of a coding agent
       | generated browser than Cursor's FastRender - it's a fraction of
       | the size (20,000 lines of Rust compared to ~1.6m), uses way fewer
       | dependencies (just system libraries for rendering images and
       | text) and the code is actually quite readable - here's the
       | flexbox implementation, for example:
       | https://github.com/embedding-shapes/one-agent-one-browser/bl...
       | 
       | Here's my own screenshot of it rendering my blog -
       | https://bsky.app/profile/simonwillison.net/post/3mdg2oo6bms2... -
       | it handles the layout and CSS gradiants really well, renders the
       | SVG feed icon but fails to render a PNG image.
       | 
       | I thought "build a browser that renders HTML+CSS" was the perfect
       | task for demonstrating a massively parallel agent setup because
       | it couldn't be productively achieved in a few thousand lines of
       | code by a single coding agent. Turns out I was wrong!
        
         | vidarh wrote:
         | I think the human + agent thing absolutely will make a _huge_
         | difference. I see regularly that Claude can totally off piste
         | and eventually claw itself back _with a proper agent setup_ but
         | it will take a _lot_ of time if I don 't spot it and get it
         | back on track.
         | 
         | I have one project Claude is working on right now where I'm
         | testing a setup to attempt to take myself more out of the loop,
         | because _that_ is the hard part. It 's "easy" to get an agent
         | to multiply your output. It's hard to make that scale with your
         | willingness to spend on tokens rather than with your ability to
         | read and review and direct.
         | 
         | I've ended up with roughly this (it's nothing particularly
         | special):
         | 
         | - Runs a evaluator that evaluates the current state and assigns
         | scores across multiple metrics.
         | 
         | - If a given score is above a given threshold, expand the test
         | suite automatically.
         | 
         | - If the score is below a given threshold, spawn a "research
         | agent" that investgates why the scores don't meet expectations.
         | 
         | - The research agent delivers a report, that is passed to an
         | implementation agent.
         | 
         | - The main agent re-runs the scoring, and if it doesn't show an
         | improvement on one or more of the metrics, the commit is
         | discarded, and notes made of what was tried, and why it failed.
         | 
         | It takes a bit of trial and error to get it right (e.g. "it's
         | the test suite that is wrong" came up early, and the main agent
         | was almost talked into revising the test suite to remove the
         | "problematic" tests) but a division sort of like this lets
         | Claude do more sensible stuff for me. Throwing away commits
         | feels drastic - an option is to let it run a little cycle of
         | commit -> evaluate -> redo a few times before the final
         | judgement, maybe - but it so far it feels like it'll scale
         | better. Less crap makes it into the project.
         | 
         | And I think this will work better than to treat these agents as
         | if they are developers whose output costs 100x as much.
         | 
         | Code so cheap it is disposable should change the workflows.
         | 
         | So while I agree this is a better demonstration of a good way
         | to build a browser, it's a _less interesting_ demonstration as
         | well. Now that we 've seen people show that something like
         | FastRender is possible, expect people to experiment with
         | similarly ambitious projects but with more thought put into
         | scoring/evaluation, including on code size and dependencies.
        
           | embedding-shape wrote:
           | > I think the human + agent thing absolutely will make a huge
           | difference.
           | 
           | Just the day(s) before, I was thinking about this too, and I
           | think what will make the biggest difference is humans who
           | posses "Good Taste". I wrote a bunch about it here:
           | https://emsh.cat/good-taste/
           | 
           | I think the ending is most apt, and where I think we're going
           | wrong right now:
           | 
           | > I feel like we're building the wrong things. The whole vibe
           | right now is "replace the human part" instead of "make better
           | tools for the human part". I don't want a machine that
           | replaces my taste, I want tools that help me use my taste
           | better; see the cut faster, compare directions, compare
           | architectural choices, find where I've missed things, catch
           | when we're going into generics, and help me make sharper
           | intentional choices.
        
             | vidarh wrote:
             | For some projects, "better tools for the human part" is
             | sufficient and awesome.
             | 
             | But for other projects, being able to scale with little or
             | no human involvement suddenly turns some things that were
             | borderline profitable or not possible to make profitable at
             | all with current salaries vs. token costs into viable
             | businesses.
             | 
             | Where it works, it's a paradigm shift - for both good and
             | bad.
             | 
             | So it depends what you're trying to solve for. I have
             | projects in both categories.
        
               | embedding-shape wrote:
               | Personally I think the part where you try to eliminate
               | humans from involvement, is gonna lead to too much
               | trouble, being too inflexible and the results will be
               | bad. It's what I've seen so far, haven't seen anything
               | pointing to it being feasible, but I'd be happy to be
               | corrected.
        
               | vidarh wrote:
               | It really depends on the type of tasks. There are many
               | tasks LLMs do for me entirely autonomously already,
               | because they do it well enough that it's no longer worth
               | my time.
        
         | Imustaskforhelp wrote:
         | To me I really like how embedding shapes took things in his own
         | hands and actually built it. It really proved a point at such a
         | scale where I don't think any recent example can point to.
         | 
         | It's great to see hackernews be so core part of it haha.
         | 
         | > I thought "build a browser that renders HTML+CSS" was the
         | perfect task for demonstrating a massively parallel agent setup
         | because it couldn't be productively achieved in a few thousand
         | lines of code by a single coding agent. Turns out I was wrong!
         | 
         | I do wonder if tech people from future/present are gonna
         | witness this as a goliath vs david story. 20k 1 human 1 agent
         | beats 5 million$ 1.6 millions loc browser changing how even the
         | massive AI users/pioneers at the time thought about the use of
         | AI
         | 
         | Looks like I have watched some documentaries recently but why
         | do I feel like a documentary about this whole thing can be
         | created in future.
         | 
         | But also, More and more I am feeling like AI is an absolute
         | black box, nobody knows how to do things but we are all kind of
         | doing experiments with it and seeing what sticks (like how we
         | now have definitive proof that 1 human 1 agent > many agents no
         | human in the loop)
         | 
         | And this is when we are 1 month in 2026, who knows what other
         | experiments and proofs happen this year to find more about this
         | black box, and about its usefulness or not.
         | 
         | Simon, it would be interesting if you could read the thread of
         | predictions of 2026 thread in hn each month or quaterly to see
         | how many people were wrong or right about AI as we figure out
         | more things perhaps.
        
         | g947o wrote:
         | I think most people would agree that this is much more superior
         | than Cursor's "browser" from an engineering perspective -- it
         | doesn't do much but does it well, as you pointed out.
         | 
         | What it tells me is that "effectively using agents" can be much
         | more important than just throwing tokens at a problem and see
         | what comes out. I myself have completely deleted several small
         | vibe-coded projects without even going over the code, because
         | what often happens is that, two days after the code is
         | generated, I realize that I was solving the wrong problem or
         | using the wrong approach.
         | 
         | A coding agent doesn't care. It most likely just does whatever
         | you ask it to do with no pushback. While in some cases it's
         | worth using them to validate an idea, often you dig a deeper
         | hole for yourself if you go down a wrong path in the first
         | place.
        
           | embedding-shape wrote:
           | Yeah, I agree with all of what you wrote, how these are used
           | seems (to me) to be more important than how they're built. If
           | you don't know software engineering, a software engineering
           | agent isn't suddenly gonna make you one, but someone who
           | already knows the craft, can be very effective with one.
           | 
           | Amplifiers, rather than replacements. I think the community
           | at large still thinks LLMs and agents are gonna be
           | "replacing" knowledge, which I think is far from the truth.
        
       | rahimnathwani wrote:
       | This is awesome. Would you be willing to share more about your
       | prompts? I'm particularly interested in how you prompted it to
       | get the first few things working.
        
         | embedding-shape wrote:
         | Yes, I'm currently putting it all together and will make it
         | public via the blog post. Just need to go through all of it
         | first to ensure nothing secret/private leaks, will update once
         | I've made it public.
        
       | jacquesm wrote:
       | This post is far more interesting than many others on the same
       | subject, not because of what is built but because of how it it is
       | built. There is a ton of noise on this subject and most of it
       | seems to focus on the thing - or even on the author - rather than
       | on the process, the constraints and the outcome.
        
         | embedding-shape wrote:
         | Thanks, means a lot. As the author of one such article (that
         | might have been the catalyst even), I'm guilty of this myself,
         | and as I dove deeper into understanding what Cursor actually
         | built, and what they think was the "success", the less sense
         | everything made to me.
         | 
         | That's why taking a step back and seeing what's actually hard
         | in the process and bad with the output, felt like it made more
         | sense to chase after, rather than anything else.
        
           | jacquesm wrote:
           | I think the Cursor example is as bad as it gets and this is
           | as good as it gets.
           | 
           | FWIW I ran your binary and was pleasantly surprised, but my
           | low expectations probably helped ;)
        
             | embedding-shape wrote:
             | I'm glad I could take people on a journey that first
             | highlighted what absolutely sucks, to presenting something
             | that seemingly people get pleasantly surprised by! Can't
             | ask for more really :)
        
               | jacquesm wrote:
               | What is interesting is that yours is the first example of
               | what this tech can do that resonates with me, the things
               | I've seen posted so far do not pass the test for
               | excitement, it's just slop and it tries to impress by
               | being a large amount of slop. I've done some local
               | experiments but the results were underwhelming (to put it
               | mildly) even for tiny problems.
               | 
               | The next challenge I think would be to prove that no
               | reference implementation code leaked into the produced
               | code. And finally, this being the work product of an AI
               | process you can't claim copyright, but someone else could
               | claim infringement so beware of that little loophole.
        
               | embedding-shape wrote:
               | Knowing you browse HN quite a lot (not that I'm not
               | guilty of that too), that's some high praise! Thank you
               | :)
               | 
               | I think the focus with LLM-assisted coding for me has
               | been just that, assisted coding, not trying to replace
               | whole people. It's still me and my ideas driving (and my
               | "Good Taste", explained here: https://emsh.cat/good-
               | taste/), the LLM do all the things I find more boring.
               | 
               | > prove that no reference implementation code leaked into
               | the produced code
               | 
               | Hmm, yeah, I'm not 100% sure how to approach this, open
               | to ideas. Basic comparing text feels like it'd be too
               | dumb, using an LLM for it might work, letting it
               | reference other codebase perhaps. Honestly, don't know
               | how I'd do that.
               | 
               | > And finally, this being the work product of an AI
               | process you can't claim copyright, but someone else could
               | claim infringement so beware of that little loophole.
               | 
               | Good point to be aware of, and I guess I by instinct
               | didn't actually add any license to this project. I
               | thought of adding MIT as I usually do, but I didn't
               | actually make any of this so ended up not assigning any
               | license. Worst case scenario, I guess most jurisdictions
               | would deem either no copyright or that I (implicitly)
               | hold copyright. Guess we'll take that if we get there :)
        
       | rvz wrote:
       | > I'm going to upgrade my prediction for 2029: I think we're
       | going to get a production-grade web browser built by a small team
       | using AI assistance by then.
       | 
       | That is Ladybird Browser if that was not already obvious.
        
         | dewey wrote:
         | For the curious, they have a reasonable AI policy:
         | 
         | https://github.com/LadybirdBrowser/ladybird/blob/master/CONT...
        
         | simonw wrote:
         | Ladybird (a project I deeply respect) had a several year head
         | start.
        
       | mwcampbell wrote:
       | Impressive work.
       | 
       | I wonder if you've looked into what it would take to implement
       | accessibility while maintaining your no-Rust-dependencies rule.
       | On Windows and macOS, it's straightforward enough to implement UI
       | Automation and the Cocoa NSAccessibility protocols respectively.
       | On Unix/X11, as I see it, your options are:
       | 
       | 1. Implement AT-SPI with a new from-scratch D-Bus implementation.
       | 
       | 2. Implement AT-SPI with one of the D-Bus C libraries (GLib,
       | libdbus, or sdbus).
       | 
       | 3. Use GTK, or maybe Qt.
        
       | QuadmasterXLII wrote:
       | The rendering is pretty chaotic when I tried it- not that far off
       | from just the text in the html tags, in some size, color, and
       | placement on the screen. This sounds like unfairness, but there
       | is some motte-and-bailey where if you claim to be a browser, I
       | get to evaluate on stuff like links being consistently blue and
       | underlined ( as is, they are sometimes blue and sometimes
       | underlined, without a clear pattern- if they were never formatted
       | differently from standard text, I would just buy this as a
       | feature not implemented yet). It may be that some of the
       | rendering is not supported on windows- the back button certainly
       | isn't. I guess if I want to make my criticism actually legitimate
       | I should make a "one human and no agent browser" post that just
       | regexes out stuff that looks like content and formats it at
       | random. The binary I downloaded definitely overperforms at the
       | hacker news homepage and simonw's blog.
        
         | embedding-shape wrote:
         | It's a really basic browser. It's made less as an independent
         | thing, and more as a reply to https://cursor.com/blog/scaling-
         | agents, so as long as it does more or less the same as theirs,
         | but is less LOC, it does what I set out for it to do :)
         | 
         | > I get to evaluate on stuff like links being consistently blue
         | and underlined
         | 
         | Yeah, this browser doesn't have a "default stylesheet" like a
         | regular browser. Probably should have added that, but was
         | mostly just curious about rendering the websites from the web,
         | rather than using what browsers think the web should look like.
         | 
         | > It may be that some of the rendering is not supported on
         | windows- the back button certainly isn't.
         | 
         | Hmm, on Windows 11 the back button should definitively work,
         | tried that just last night. Are you perhaps on Windows 10? I
         | have not tried that myself, should work but might be why.
        
           | QuadmasterXLII wrote:
           | It is both extraordinarily impressive in an absolute sense,
           | and fairly disappointing specifically comparing my result on
           | a a random smattering of other no-js websites, to the
           | expectation I had from the simonw screenshot (which to be
           | clear is not an expectation you had control over, as you are
           | not simonw). I'm familiar with this pattern from all the rest
           | of my trying frontier ML results!
           | 
           | Yep, I ran it on an old windows 10 VM I had puttering about.
           | 
           | I think it must have a default link styling somewhere, as
           | some links are the classic blue that as far as I know I
           | intentionally styled to be black- but this could be css
           | spaghetti in tufte.css finally coming to haunt me.
        
             | embedding-shape wrote:
             | > I'm familiar with this pattern from all the rest of my
             | trying frontier ML results!
             | 
             | Well, that's how this browser came to be, because I felt
             | something similar to with how Cursor presented their
             | results :) So I guess we're in the same club, somehow.
             | 
             | And yeah, lots of websites render poorly, for obvious
             | reasons, if it's better or worse than Cursor's I guess will
             | be up to the public, I'm sure if I actually treated it as a
             | professional project I could probably get it to work quite
             | nicely rather than the abomination it currently is.
        
       | storystarling wrote:
       | How did you handle the context window for 20k lines? I assume you
       | aren't feeding the whole codebase in every time given the API
       | costs. I've struggled to keep agents coherent on larger projects
       | without blowing the budget, so I'm curious if you used a specific
       | scoping strategy here.
        
         | simonw wrote:
         | GPT-5.2 has a 400,000 token context window. Claude Opus 4.5 is
         | just 200,000 tokens. To my surprise this doesn't seem to limit
         | their ability to work with much larger codebases - the coding
         | agent harnesses have got _really_ good at grepping for just the
         | code that they need to have in-context, similar to how a human
         | engineer can make changes to a million lines of code without
         | having to hold it all in their head at once.
        
           | storystarling wrote:
           | That explains the coherence, but I'm curious about the
           | mechanics of the retrieval. Is it AST-based to map
           | dependencies or are you just using vector search? I assume
           | you still have to filter pretty aggressively to keep the
           | token costs viable for a commercial tool.
        
             | simonw wrote:
             | No vector search, just grep.
        
         | nurettin wrote:
         | You don't load the entire project into the context. You let the
         | agent work on a few 600-800 line files one feature at a time.
        
           | storystarling wrote:
           | Right, but how does it know which files to pick? I'm curious
           | if you're using a dependency graph or embeddings for that
           | discovery step, since getting the agent to self-select the
           | right scope is usually the main bottleneck.
        
             | embedding-shape wrote:
             | I gave you a more complete answer here:
             | https://news.ycombinator.com/item?id=46787781
             | 
             | > since getting the agent to self-select the right scope is
             | usually the main bottleneck
             | 
             | I haven't found this to ever be the bottleneck, what agent
             | and model are you using?
        
         | embedding-shape wrote:
         | I didn't, Codex (tui/cli) did, it does it all by itself. I have
         | one REQUIREMENTS.md which is specific to the project, a
         | AGENTS.md that I reuse across most projects, then I give Codex
         | (gpt-5.2 with reasoning effort set to xhigh) a prompt +
         | screenshot, tells it to get it to work somewhat similar, waits
         | until it completes, reviewed that it worked, then continued.
         | 
         | Most of the time when I develop professionally, I restart the
         | session after each successful change, for this project, I
         | initially tried to let one session go as long as possible, but
         | eventually I reverted back to my old behavior of restarting
         | from 0 after successful changes.
         | 
         | For knowing what file it should read/write, it uses `ls`,
         | `tree` and `ag ` most commonly, there is no out-of-band
         | indexing or anything, just a unix shell controlled by a LLM via
         | tool calls.
        
       | pulkas wrote:
       | The Mythical Man-Month, revisited
        
       | Imustaskforhelp wrote:
       | I feel like I have talked to Embedding-shape on Hackernews quite
       | a lot that I recognize him. So it was a proud like moment when I
       | saw his hackernews & github comments on a youtube video [0]about
       | the recent cursor thing
       | 
       | It's great to see him make this. I didn't know that he had a blog
       | but looks good to me. Bookmarked now.
       | 
       | I feel like although Cursor burned 5 million$, we saw that and
       | now Embedding shapes takeaway
       | 
       | If one person with one agent can produce equal or better results
       | than "hundreds of agents for weeks", then the answer to the
       | question: "Can we scale autonomous coding by throwing more agents
       | at a problem?", probably has a more pessimistic answer than some
       | expected.
       | 
       | Effectively to me this feels like answering the query which was
       | being what if we have thousands of AI agents who can build a
       | complex project autonomously with no Human. That idea seems dead
       | now. Humans being in the loop will have a much higher
       | productivity and end result.
       | 
       | I feel like the lure behind the Cursor project was to find if its
       | able to replace humans completely in a extremely large project
       | and the answer's right now no (and I have a feeling [bias?] that
       | the answer's gonna stay that way)
       | 
       | Emsh I have a question tho, can you tell me about your background
       | if possible? Have you been involved in browser development or any
       | related endeavours or was this a first new one for you? From what
       | I can feel/have talked with you, I do feel like the answer's yes
       | that you have worked in browser space but I am still curious to
       | know the answer.
       | 
       | A question which is coming to my mind is how much would be the
       | difference between 1 expert human 1 agent and 1 (non expert) say
       | Junior dev human 1 agent and 1 completely non expert say a normal
       | person/less techie person 1 agent go?
       | 
       | What are your guys prediction on it?
       | 
       | How would the economics of becoming an "expert" or becoming a
       | jack of all trades (junior dev) in a field fare with this new
       | technology/toy that we got.
       | 
       | how much productivity gains could be from 1 non expert -> junior
       | dev and the same question for junior -> senior dev in this
       | particular context
       | 
       | [0] Cursor Is Lying To Developers... :
       | https://www.youtube.com/watch?v=U7s_CaI93Mo
        
         | simonw wrote:
         | I don't think the Cursor thing was about replacing humans
         | entirely.
         | 
         | (If it was that's bad news for them as a company that sells
         | tools to human developers!)
         | 
         | It was about scaling coding agents up to _much_ larger projects
         | by coordinating and running them in parallel. They chose a web
         | browser for that not because they wanted to build a web
         | browser, but because it seemed like the ideal example of a well
         | specified but enormous (million line+) project which multiple
         | parallel agents could take on where a single agent wouldn 't be
         | able to make progress.
         | 
         | embedding-shape's project here disproves that last bit - that
         | you need parallel agents to build a competent web renderer - by
         | achieving a more impressive result with just one Codex agent in
         | a few days.
        
           | Imustaskforhelp wrote:
           | > I don't think the Cursor thing was about replacing humans
           | entirely.
           | 
           | I think how I saw things was that somehow Cursor was/is still
           | targetted very heavily on vibe coding in a similar fashion of
           | bolt.dev or lovable and I even saw some vibe coders youtube
           | try to see the difference and honestly at the end Cursor had
           | a preferable pricing than the other two and that's how I felt
           | Cursor was.
           | 
           | Of course Cursor's for the more techie person as well but I
           | feel as if they would shift more and more towards Claude Code
           | or similar which are subsidized by the provider (Anthropic)
           | itself, something not possible for Cursor to do unless
           | burning big B's which it already has done.
           | 
           | So Cursor's growth was definitely towards the more vibe
           | coders side.
           | 
           | Now coming to my main point which is that I had the feeling
           | that what cursor was trying to achieve wasn't trying to
           | replace humans entirely but replace humans from the loop Aka
           | Vibe coding. Instead of having engineers, if suppose the
           | Cursor experiment was sucessful, the idea (which people felt
           | when it was first released instantly) was that the
           | _engineering_ itself would 've been dead & instead the jobs
           | would've turned into management from a bird's eye view (not
           | managing agent's individually or being aware of what they did
           | or being in any capacity within the loop)
           | 
           | I feel like this might've been the reason they were willing
           | to burn 5 million$ for.
           | 
           | If you could've been able to convince engineers considering
           | browsers are taken as the holy grail of hardness that they
           | are better off being managers, then a vibe coding product
           | like Cursor would be really lucrative.
           | 
           | Atleast that's my understanding, I can be wrong I usually am
           | and I don't have anything against Cursor. (I actually used to
           | use Cursor earlier)
           | 
           | But the embedding shapes project shows that engineering is
           | very much still alive and beneficial net. He produced a
           | better result with very minimal costs than 5 million$
           | inference costs project.
           | 
           | > embedding-shape's project here disproves that last bit -
           | that you need parallel agents to build a competent web
           | renderer - by achieving a more impressive result with just
           | one Codex agent in a few days.
           | 
           | Simon, I think that browsers got the idea of this autonomous
           | agents partially because of your really famous post about how
           | independent tests can lead to easier ports via agents.
           | Browsers have a lot of independent tests.
           | 
           | So Simon, perhaps I may have over-generalized but do you know
           | of any ideas where the idea of parallel agents is actually
           | good now that browsers are off, personally after this
           | project, I can't really think of any. When the Cursor thing
           | first launched or when I first heard of it recently, I
           | thought that browsers did make sense for some reason but now
           | that its out of the window, I am not sure if there are any
           | other projects where massively parallel agents might be even
           | net positive over 1 human + 1 agent as Emsh.
        
             | simonw wrote:
             | No, I'm still waiting to see concrete evidence that the
             | "swarms of parallel agents" thing is worthwhile. I use sub-
             | agents in Claude Code occasionally - for problems that are
             | easily divided - and that works fine as a speed-up, but I'm
             | still holding out for an example of a swarm of agents
             | that's really compelling.
             | 
             | The reason I got excited about the Cursor FastRender
             | example was that it seemed like the first genuine example
             | of thousands of agents achieving something that couldn't be
             | achieved in another way... and then embedding-shapes went
             | and undermined it with 20,000 lines of single-agent Rust!
        
               | Imustaskforhelp wrote:
               | Haha yea, Me and emsh were actually talking about it on
               | bluesky (which I saw after seeing your bluesky, I didn't
               | know both you and emsh were on bsky haha)
               | 
               | https://bsky.app/profile/emsh.cat/post/3mdgobfq4as2p
               | 
               | But basically I got curious and you can see from my other
               | comments on you how much I love golang so decided to port
               | the project from rust to golang and emsh predicts that
               | the project's codebase can even shrink to 10k!
               | 
               | (although one point tho is that I don't have CC, I am
               | trying it out on the recently released Kimi k2.5 model
               | and their code but I decided to use that to see the real
               | world use case of an open source model as well!)
               | 
               | Edit: I had written this comment just 2 minutes before
               | you wrote but then I decided to write the golang project
               | 
               | I mean, I think I ate through all of my 200 queries in
               | kimi code & it now does display me a (browser?) and I had
               | the shell script as something to test your website as the
               | test but it only opens up blank
               | 
               | I am gonna go sleep so that the 5 hour limits can get
               | recharged again and I will continue this project.
               | 
               | I think it will be really interesting to see this project
               | in golang, there must be good reason for emsh to say the
               | project can be ~10k in golang.
        
               | embedding-shape wrote:
               | > I think it will be really interesting to see this
               | project in golang, there must be good reason for emsh to
               | say the project can be ~10k in golang.
               | 
               | Oh no, don't read too much into my wild guesses! Very
               | hunch-based, and I'm only human after all.
        
               | Imustaskforhelp wrote:
               | Edit 2: looks like the project took literally the last
               | token I had to create a big buggy implementation in
               | golang haha!
               | 
               | I kind of left the agents to do what they wanted just
               | asking for a port.
               | 
               | Your website does look rotated and the image is the only
               | thing visible in my golang port.
               | 
               | Let me open source it & I will probably try to hammer it
               | some more after I wake up to see how good Kimi is in real
               | world tasks.
               | 
               | https://github.com/SerJaimeLannister/golang-browser
               | 
               | I must admit that its not working right now and I am even
               | unable to replicate your website that was able to first
               | display even though really glitchy and image zoomed to
               | now only a white although oops looks like I forgot the i
               | in your name and wrote willson instead of willison as I
               | wasn't wearing specs. Sorry about that
               | 
               | Now Let me see yeah now its displaying _something_ which
               | is extremely glitchy
               | 
               | https://github.com/SerJaimeLannister/golang-
               | browser/blob/mai...
               | 
               | I have a file to show how glitchy it is. I mean If
               | anything I just want someone to tinker around with if a
               | golang project can reasonably be made out of this rust
               | project.
               | 
               | Simon, I see that you were also interested in go vibe
               | coding haha, this project has independent tests too!
               | Perhaps you can try this out as well and see how it goes!
               | It would be interesting to see stuff then!
               | 
               | Alright time for me to sleep now, good night!
        
       | forgotpwd16 wrote:
       | Impressive. Very nice. (Let's see Paul Allen's browser. /s) Can
       | say is Brooks's law in action. _What one human and one agent can
       | do in 3d, one human and hundreds of agents can do in few weeks_.
       | A modern retake of the old joke.
       | 
       | >without using any 3rd party libraries
       | 
       | Seems to be an easier for coding agents to implement from scratch
       | over using libraries.
        
       | avmich wrote:
       | Next thing would probably be an OS. With different APIs, the
       | browser could be not constrained by existing standards.
       | Generation of a good set of applications making working in the OS
       | convenient - starting with GNU set? And then we can approach CPU
       | architecture - again, without constraint to existing languages or
       | instruction sets. That should be interesting to play with.
        
         | forgotpwd16 wrote:
         | Someone has already done this:
         | https://github.com/viralcode/vib-OS
         | 
         | Also, someone made a similar comment not too long ago. So
         | people surely are curious if this is possible. Kinda surprised
         | this project's submission didn't got popular.
        
       | happytoexplain wrote:
       | What kind of time frame do you ballpark this would have taken you
       | on your own?
       | 
       | I know it's a little apples-and-oranges (you and the agent
       | wouldn't produce the exact same thing), but I'm not asking
       | because I'm interested in the man-hour savings. Rather, I want to
       | get a perspective on what kind of expertise went into the
       | guidance (without having to read all the guidance and be familiar
       | with browser implementation myself). "How long this would have
       | taken the author" seems like one possible proxy for "how much
       | pre-existing experience went into this agent's guidance".
        
         | simonw wrote:
         | I have a fun little tool which runs the year-2000-era sloccount
         | algorithm (which is Perl and C so I run it in WebAssembly) to
         | estimate the time and cost of a project here:
         | https://tools.simonwillison.net/sloccount
         | 
         | If you paste https://github.com/embedding-shapes/one-agent-one-
         | browser into the "GitHub Repository" tab it estimates 4.58
         | person-years and $618,599 by year-2000 standards, or 5.61 years
         | and $1,381,079 according to my very non-trustworthy 2025
         | estimate upgrade.
        
         | embedding-shape wrote:
         | > What kind of time frame do you ballpark this would have taken
         | you on your own?
         | 
         | I don't think I'd be able to do this on my own. Not that I
         | don't know Rust, but because I don't know X11 (nor macOS or
         | Windows) well enough to even know where to begin.
         | 
         | I've been a Linux user for almost two decades, so I know my way
         | around my system, but never developed X11 applications or
         | anything, I'm mostly a web developer who jumped around various
         | roles through the years. Spent a lot of time caring deeply
         | about testing, infrastructure, architecture/design and
         | communication between humans, might have given me a slight edge
         | in programming together with agents.
        
       | barredo wrote:
       | The binaries are only around 1 MB for Linux, Mac and Windows.
       | Very impressive https://github.com/embedding-shapes/one-agent-
       | one-browser/re...
        
         | embedding-shape wrote:
         | Fun fact, not until someone mentioned how small the binaries
         | did I notice! Fun little side-effect from the various
         | constraints and requirements I set in the REQUIREMENTS.md I
         | suppose.
        
       | hedgehog wrote:
       | This looks pretty solid. I think you can make this process more
       | efficient by decomposing the problem into layers that are more
       | easily testable, e.g. testing topological relationships of DOM
       | elements after parse, then spatial after layout, then eventually
       | pixels on things like ACID2 or whatever the modern equivalent is.
       | The models can often come up with tests more accurately than they
       | get the code right the first time. There are often also
       | invariants that can be used to identify bugs without ground
       | truth, e.g rendering the page with slightly different widths you
       | can make some assertions about how far elements will move.
        
         | embedding-shape wrote:
         | > There are often also invariants that can be used to identify
         | bugs without ground truth, e.g rendering the page with slightly
         | different widths you can make some assertions about how far
         | elements will move.
         | 
         | That's really interesting and sounds useful! I'm wondering if
         | there are general guidelines/requirements (not specific to
         | browsers) that could kind of "trigger" those things in the
         | agent, without explicitly telling it. I think generally that's
         | how I try to approach prompting.
        
       | sosodev wrote:
       | The browser works shockingly well considering it was created in
       | 72 hours. It can render Wikipedia well enough to read and browse
       | articles. With some basic form handling and browser standards
       | (url bar, history, bookmarks, etc) it would be a viable way to
       | consume text based content.
        
         | embedding-shape wrote:
         | I can't say my fingers (codex's fingers) haven't been itching
         | to add some small features which would basically make it a
         | viable browser for myself at least, for 90% of my browsing.
         | 
         | But I think this is one of those experiments that I need to put
         | a halt to sooner rather than later, because the scope can
         | always grow, my mind really likes those sorts of projects, and
         | I don't have the time for that right now :)
        
       | fabrice_d wrote:
       | This is a cool project, and to render Simon's blog will likely
       | become the #1 goal of AI produced "web browsers".
       | 
       | But we're very far from a browser here, so that's not that
       | impressive. Writing a basic renderer is really not that hard, and
       | matches the effort and low LoC from that experiment. This is
       | similar to countless graphical toolkits that have been written
       | since the 70s.
       | 
       | I know Servo has a "no AI contribution" policy, but I still would
       | be more impressed by a Servo fork that gets missing APIs
       | implemented by an AI, with WPT tests passing etc. It's a lot less
       | marketable I guess. Go add something like WebTransport for
       | instance, it's a recent API so the spec should be properly
       | written and there's a good test suite.
        
       ___________________________________________________________________
       (page generated 2026-01-27 23:00 UTC)