embedding-shapes

One Human + One Agent = One Browser From Scratch

2026-01-27T00:00:00Z

Just for the fun of it, I thought I'd embark on a week-long quest to generate millions of tokens and millions of lines of source code to create one basic browser that can render HTML and CSS (no JS tho), and hopefully I could use this to receive even more VC investments.

But then I remembered that I have something even better: a human brain! It is usually better than any machine at coordinating and thinking through things, so let's see if we can hack something together, one human brain and one LLM agent brain!

Demonstration of one-agent-one-browser running with a bunch of different websites on Linux/X11

The above might look like a simple .webm video, but it's actually a highly sophisticated and advanced browser that was super hard to build, encoded as pixels in a video file! Wowzers.

Day 1 - Starting out

For extra fun when building this, I set these requirements for myself and the agent:

I have three days to build it
Not a single 3rd party Rust library/dependency allowed
Allowed to use anything (commonly) provided out of the box on the OS it runs on
Should run on Windows, macOS and common Linux distributions
Should be able to render some websites, most importantly, my own blog and Hacker News, should be easy right?
The codebase can always compile and be built
The codebase should be readable by a human, although code quality isn't the top concern

So with these things in mind, I set out on the journal to build a browser "from scratch". I started with something really based, being able to just render "Hello World". Then to be able to render some nested tags. Added the ability of taking screenshots so the agent could use that. Added specifications for HTML/CSS (which I think the agent never used :| ), and tried to nail down the requirements for the agent to use. Also started doing "regression" or "E2E" tests with the screenshotting feature, so we could compare to some baseline images and so on. Added the ability to click on links just for the fun of it.

After about a day together with Codex, I had something that could via X11 and cURL, fetch and render websites when run, and the Cargo.lock is empty. It was about 7500 lines long in total at that point, split across files with all of them under 1000 lines long (which was a stated requirement, so not a surprise).

Day 2 - Moving On

Second day I got annoyed by the tests spawning windows while I was doing other stuff, so added a --headless flag too. Did some fixes for resizing the window, various compatibility fixes, some performance issues and improved the font/text rendering a bunch. Workflow was basically to pick a website, share a screenshot of the website without JavaScript, ask Codex to replicate it following our instructions. Most of the time was the agent doing work by itself, and me checking in when it notifies me it was done.

Day 3 - Polish & Cross-platform (+ day 4)

Third day we made large changes, lots of new features and a bunch of new features supported. More regression tests, fixing performance issues, fixing crashes and whatnot. Also added scrolling because this is a mother fucking browser, it has to be able to scroll. Added some debug logs too because that'll look cool in the demonstration video above, and also added support for the back button because it was annoying to start from scratch if I clicked the wrong link while testing.

At the end of the third day we also added starting support for macOS, and managed to get a window to open, and the tests to pass. Seems to work OK :) Once we had that working, we also added Windows support, basically the same process, just another platform after all.

Then the fourth day (whaaaat?) was basically polish, fixing CI for all three platforms, making it pass and finally cutting a release based on what got built in CI. Still all within 72 hours (3 days * 24 hours, which obviously this is how you count days).

The results after ~3 days (~70 hours)

And here it is, in all its glory, made in ~20K lines of code and under 72 hours of total elapsed time from first commit to last:

You could try compiling it yourself (zero Rust dependencies, so it's really fast :) ), or you can find binaries built on CI here:
https://github.com/embedding-shapes/one-agent-one-browser/releases

You can clone the repository, build it and try it out for yourself. It's not great, I wouldn't even say it's good, but it works, and demonstrates that one person with one agent can build a browser from scratch.

This is what the "lines of code" count ended up being after all was said and done, including support for three OSes:

$ git rev-parse HEAD
e2556016a5aa504ecafd5577c1366854ffd0e280

$ cloc src --by-file
      72 text files.
      72 unique files.
       0 files ignored.

github.com/AlDanial/cloc v 2.06  T=0.06 s (1172.5 files/s, 373824.0 lines/s)
-----------------------------------------------------------------------------------
File                                            blank        comment           code
-----------------------------------------------------------------------------------
src/layout/flex.rs                                 96              0            994
src/layout/inline.rs                               85              0            933
src/layout/mod.rs                                  82              0            910
src/browser.rs                                     78              0            867
src/platform/macos/painter.rs                      96              0            765
src/platform/x11/cairo.rs                          77              0            713
src/platform/windows/painter.rs                    88              0            689
src/bin/render-test.rs                             87              0            666
src/style/builder.rs                               83              0            663
src/platform/windows/d2d.rs                        53              0            595
src/platform/windows/windowed.rs                   72              0            591
src/style/declarations.rs                          18              0            547
src/image.rs                                       81              0            533
src/platform/macos/windowed.rs                     80              2            519
src/net/winhttp.rs                                 61              2            500
src/platform/x11/mod.rs                            56              2            487
src/css.rs                                        103            346            423
src/html.rs                                        58              0            413
src/platform/x11/painter.rs                        48              0            407
src/platform/x11/scale.rs                          57              3            346
src/layout/table.rs                                39              1            340
src/platform/x11/xft.rs                            35              0            338
src/style/parse.rs                                 34              0            311
src/win/wic.rs                                     39              8            305
src/style/mod.rs                                   26              0            292
src/style/computer.rs                              35              0            279
src/platform/x11/xlib.rs                           32              0            278
src/layout/floats.rs                               31              0            265
src/resources.rs                                   36              0            238
src/css_media.rs                                   36              1            232
src/debug.rs                                       32              0            227
src/platform/windows/dwrite.rs                     20              0            222
src/render.rs                                      18              0            196
src/style/custom_properties.rs                     34              0            186
src/platform/windows/scale.rs                      28              0            184
src/url.rs                                         32              0            173
src/layout/helpers.rs                              12              0            172
src/net/curl.rs                                    31              0            171
src/platform/macos/svg.rs                          35              0            171
src/browser/url_loader.rs                          17              0            166
src/platform/windows/gdi.rs                        17              0            165
src/platform/windows/scaled.rs                     16              0            159
src/platform/macos/scaled.rs                       16              0            158
src/layout/svg_xml.rs                               9              0            152
src/win/com.rs                                     26              0            152
src/png.rs                                         27              0            146
src/layout/replaced.rs                             15              0            131
src/net/pool.rs                                    18              0            129
src/platform/macos/scale.rs                        17              0            124
src/style/selectors.rs                             18              0            123
src/style/length.rs                                17              0            121
src/cli.rs                                         15              0            112
src/platform/windows/headless.rs                   20              0            112
src/platform/macos/headless.rs                     19              0            109
src/bin/fetch-resource.rs                          14              0            101
src/geom.rs                                        10              0            101
src/browser/render_helpers.rs                      11              0            100
src/dom.rs                                         11              0            100
src/style/background.rs                            15              0            100
src/layout/tests.rs                                 7              0             85
src/platform/windows/d3d11.rs                      14              0             83
src/win/stream.rs                                  10              0             63
src/platform/windows/svg.rs                        13              0             54
src/main.rs                                         4              0             33
src/platform/mod.rs                                 6              0             28
src/app.rs                                          5              0             25
src/lib.rs                                          1              0             20
src/platform/windows/mod.rs                         2              0             19
src/net/mod.rs                                      4              0             16
src/platform/macos/mod.rs                           2              0             14
src/platform/windows/wstr.rs                        0              0              5
src/win/mod.rs                                      0              0              3
-----------------------------------------------------------------------------------
SUM:                                             2440            365          20150
-----------------------------------------------------------------------------------

Takeaways

One human using one agent seems far more effective than one human using thousands of agents
One agent can work on a single codebase for hours, making real progress on ambitious projects
This could probably scale to multiple humans too, each equipped with their own agent, imagine what we could achieve!
Sometimes slower is faster and also better
The human who drives the agent might matter more than how the agents work and are set up, the judge is still out on this one

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.

Good Taste

2026-01-25T00:00:00Z

There is a lot of doom going around, how all developers, creatives and others are losing our jobs because AI is coming to take them. Some of that doom is real; there's work that's basically throughput and spec compliance, and AI can replace big chunks of it. But what I’m talking about here is the other kind of work, where you have authorship and stake in what you're producing, as a human creator.

I get why many of us fear AI and carry this sense of doom with us, but at the same time, as a creative I'm not super worried about it, and not because I think AI cannot generate things, or even generate good things, because I think it can. But because the hard thing has never been to just produce something. What's always been hard, is producing something good, something made by someone with Good Taste. A real human being that stand in front of hundreds of choices and knows (or feels) what gets to stay, what gets cut, what to push and what should be refused, and finally sharing the choices they made with you, through the medium.

Just to be clear, I'm mainly talking about "creating" and authorship here, not consumption, since you as a consumer are the only judge if something is good or not for you. But when you're making something, if your goal is for others to enjoy it, Good Taste becomes a huge part of what you actually excel at. Not taste as in what the snobby critics do (who ultimately are consumers), but the creator's taste; direction, restraint, pacing, taking risks and sometimes causing offense.

The AI models and the platforms seems to tend to regress to the mean. They optimize for something that "sounds right" and "doesn't upset anyone", creating something that is "acceptable" or even "plausible". This default voice is the opposite of authorship, where you explicitly don't want to just average thing out. You want to hit a specific emotional effect with specific rhythm, and you're sometimes willing to risk choices that look wrong until the entire thing is put together. I think this is why most AI output feels so bland and emotionless.

I'm not trying to say that "AI can't make you feel anything" because I don't think it's true, I think AI can generate something that hits, you can even explicitly train and/or steer AI to produce more "emotional" outputs. But what's actually happening, even there, is that there is a human deciding and curating what counts as a "hit", and the model is learning the shape of that. Ultimately you're bottling taste, not replacing it. There is no stake at the other side, no point of view that is getting committed to, no moment where it suddenly goes "No, I'm not saying that" or "Yes, that's amazing, completely new direction now".

Without any human steering and editing, the AI will just keep handing you infinite plausible takes until one of them happen to work. Infinite "fine", but not much more.

Ultimately, I think AI is an accelerant. If you already have Good Taste, it'll help you move faster, which feels like a good thing: great people continue to produce great things.

But on the other hand, it also makes it easier for people without taste to generate a lot of output that's either bland or sometimes straight up nonsense. Without the ecosystem rewarding high quality and good things, it instead rewards volume and speed, everything slightly tilting to noise.

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.

Cursor's latest "browser experiment" implied success without evidence

2026-01-16T00:00:00Z

On January 14th 2026, Cursor published a blog post titled "Scaling long-running autonomous coding" (https://cursor.com/blog/scaling-agents)

In the blog post, they talk about their experiments with running "coding agents autonomously for weeks" with the explicit goal of

understand[ing] how far we can push the frontier of agentic coding for projects that typically take human teams months to complete

They talk about some approaches they tried, why they think those failed, and how to address the difficulties.

Finally they arrived at a point where something "solved most of our coordination problems and let us scale to very large projects without any single agent", which then led to this:

To test this system, we pointed it at an ambitious goal: building a web browser from scratch. The agents ran for close to a week, writing over 1 million lines of code across 1,000 files. You can explore the source code on GitHub (https://github.com/wilsonzlin/fastrender)

This is where things get a bit murky and unclear. They claim "Despite the codebase size, new agents can still understand it and make meaningful progress" and "Hundreds of workers run concurrently, pushing to the same branch with minimal conflicts", but they never actually say if this is successful or not, is it actually working? Can you run this browser yourself? We don't know and they never say explicitly.

After this, they embed the following video:

Video

And below it, they say "While it might seem like a simple screenshot, building a browser from scratch is extremely difficult.".

They never actually claim this browser is working and functional

error: could not compile 'fastrender' (lib) due to 34 previous errors; 94 warnings emitted

And if you try to compile it yourself, you'll see that it's very far away from being a functional browser at all, and seemingly, it never actually was able to build.

Multiple recent GitHub Actions runs on main show failures (including workflow-file errors), and independent build attempts report dozens of compiler errors, recent PRs were all merged with failing CI, and going back in the Git history from most recent commit back 100 commits,
I couldn't find a single commit that compiled cleanly.

I'm not sure what the "agents" they unleashed on this codebase actually did, but they seemingly never ran "cargo build" or even less "cargo check", because both of those commands surface 10s of errors (which surely would balloon should we solve them) and about 100 warnings. There is an open GitHub issue in their repository about this right now: https://github.com/wilsonzlin/fastrender/issues/98

And diving into the codebase, if the compilation errors didn't make that clear already, makes it very clear to any software developer that none of this is actually engineered code. It is what is typically known as "AI slop", low quality something that surely represents something, but it doesn't have intention behind it, and it doesn't even compile at this point.

They later start to talk about what's next, but not a single word about how to run it, what to expect, how it's working or anything else. Cursor's blog post provides no reproducible demo and no known-good revision (tag/release/commit) to verify the screenshots, beyond linking the repo.

Regardless of intent, Cursor's blog post creates the impression of a functioning prototype while leaving out the basic reproducibility markers one would expect from such claim. They never explicitly claim it's actually working, so no one can say they lied at least.

They finish off the article saying:

But the core question, can we scale autonomous coding by throwing more agents at a problem, has a more optimistic answer than we expected.

Which seems like a really strange conclusion to arrive at, when all they've proved so far, is that agents can output millions of tokens and still not end up with something that actually works.

A "browser experiment" doesn't need to rival Chrome. A reasonable minimum bar is: it compiles on a supported toolchain and can render a trivial HTML file. Cursor's post doesn’t demonstrate that bar, and current public build attempts fail at this too.

Conclusion

Cursor never says "this browser is production-ready", but they do frame it as "building a web browser from scratch" and "meaningful progress" and then use a screenshot and "extremely difficult" language, wanting to give the impression that this experiment actually was a success.

The closest they get to implying that this was a success, is this part:

Hundreds of agents can work together on a single codebase for weeks, making real progress on ambitious projects.

But this extraordinary claim isn't backed up by any evidence. In the blog post they never provide a working commit, build instructions or even a demo that can be reproduced.

I don't think anyone expects this browser to be the next Chrome, but I do think that if you claim you've built a browser, it should at least be able to demonstrate being able to be compiled + loading a basic HTML file at the very least.

Niccup: Hiccup-like HTML Generation in ~120 Lines of Pure Nix

2025-12-03T00:00:00Z

Ever wish it was really simple to create HTML from just Nix expressions, not even having to deal with function calls or other complexities? With niccup, now there is!

[ "div#main.container"
  { lang = "en"; }
  [ "h1" "Hello" ] ]

<div class="container" id="main" lang="en">
  <h1>Hello</h1>
</div>

That's it. Nix data structures in, HTML out. Zero dependencies. Works with flakes or without.

Source Code | Website/Docs | Introduction Blog Post

Why Generate HTML from Nix?

If you're building static sites, documentation, or web artifacts as part of a Nix derivation, you've probably resorted to one of these:

String interpolation (''<div>${title}</div>''). Works until you need escaping or composition
External templating tools. Another dependency, another language, another build step
Importing HTML files, no programmatic generation

Niccup takes a different approach: represent HTML as native Nix data structures. This gives you map, filter, builtins.concatStringsSep, and the entire Nix expression language for free. No new syntax to learn. No dependencies to manage.

The Syntax

An element is a list: [ tag-spec attrs? children... ]

Tag Specs with CSS Shorthand

"div"
# <div></div>

"input#search"
# <input id="search">

"button.btn.primary"
# <button class="btn primary"></button>

"form#login.auth.dark"
# <form class="auth dark" id="login"></form>

Attributes

The optional second element can be an attribute set:

[ "a"
  { href = "/about"; target = "_blank"; }
  "About" ]
# <a href="/about" target="_blank">About</a>

Classes from the shorthand and attribute set are merged:

[ "div.base"
  { class = [ "added" "another" ]; }
  "content" ]
# <div class="base added another">content</div>

Boolean handling:

[ "input"
  { type = "checkbox";
    checked = true;
    disabled = false; } ]
# <input checked="checked" type="checkbox">

true renders as attr="attr". false and null are omitted entirely.

Children and Composition

Children can be strings, numbers, nested elements, or lists:

[ "p"
  "Text with "
  [ "strong" "emphasis" ]
  " and more." ]
# <p>Text with <strong>emphasis</strong> and more.</p>

Lists are flattened one level, which makes map work naturally:

[ "ul"
  (map (item: [ "li" item ])
       [ "One" "Two" "Three" ]) ]
# <ul><li>One</li><li>Two</li><li>Three</li></ul>

Text content is automatically escaped:

[ "p" "<script>alert('xss')</script>" ]
# <p>&lt;script&gt;alert('xss')&lt;/script&gt;</p>

Raw HTML and Comments

For trusted HTML that shouldn't be escaped:

[ "div" (raw "<strong>Already formatted</strong>") ]
# <div><strong>Already formatted</strong></div>

For HTML comments:

[ "div" (comment "TODO: refactor")
  [ "p" "Content" ] ]
# <div><!-- TODO: refactor --><p>Content</p></div>

Void Elements

Self-closing tags work as expected:

[ "img" { src = "photo.jpg"; alt = "A photo"; } ]
# <img alt="A photo" src="photo.jpg">

[ "meta" { charset = "utf-8"; } ]
# <meta charset="utf-8">

API

Four functions. That's the entire public interface.

Function	Description
`render`	Render to minified HTML
`renderPretty`	Render to indented HTML (2-space indent)
`raw`	Mark a string as trusted, unescaped HTML
`comment`	Create an HTML comment node

A Real Example: Blog Generator

{ pkgs, niccup }:
let
  h = niccup.lib;

  posts = [
    { slug = "hello"; title = "Hello World"; body = "Welcome!"; }
    { slug = "update"; title = "An Update"; body = "More content here."; }
  ];

  layout = { title, content }: h.renderPretty [
    "html" { lang = "en"; }
    [ "head"
      [ "meta" { charset = "utf-8"; } ]
      [ "meta" { name = "viewport"; content = "width=device-width"; } ]
      [ "title" title ]
    ]
    [ "body"
      [ "nav" (map (p: [ "a" { href = "/${p.slug}.html"; } p.title ]) posts) ]
      [ "main" content ]
      [ "footer" "Generated with niccup" ]
    ]
  ];

  renderPost = post: layout {
    title = post.title;
    content = [ "article" [ "h1" post.title ] [ "p" post.body ] ];
  };

in pkgs.runCommand "blog" {} ''
  mkdir -p $out
  ${builtins.concatStringsSep "\n" (map (p: ''
    cat > $out/${p.slug}.html << 'EOF'
    ${renderPost p}
    EOF
  '') posts)}
''

This produces a complete static site as a Nix derivation. Add a post to the list, rebuild, done.

Limitations

Being upfront about what niccup doesn't do:

Attribute order is alphabetical. Nix attribute sets have no insertion order; builtins.attrNames returns keys sorted lexicographically. You cannot control attribute order in the output.
One-level flattening only. [ "ul" (map ...) ] works because map returns a list that gets flattened. Deeper nesting like [ "ul" [ [ [ "li" "x" ] ] ] ] won't flatten further, you'll get nested elements, not flattened children.
Eager evaluation. The entire tree is evaluated before rendering. For the static site generation use case, this is fine. If you're generating gigabytes of HTML, this isn't your tool.
No streaming. Output is a single string. Again, fine for static sites; not designed for chunked HTTP responses.

Why Hiccup?

The Hiccup format originated in Clojure and has been battle-tested for over a decade. It maps naturally to Nix because both languages treat data structures as first-class citizens. The syntax is minimal, just lists and attribute sets, and composes with existing Nix idioms without friction.

The name "niccup" is a portmanteau: Nix + Hiccup.

Source

The entire implementation is ~120 lines of pure Nix with no external dependencies. The code, tests, and additional examples are available at:

github.com/embedding-shapes/niccup

MIT licensed.