It is pretty incredible to me that in the pre-LLM/agent coding world, creating a new high-quality JS engine or browser seemed like it would likely never happen again. But now, any large company could build one if they wanted to. In a single digit number of months no less.
This is really cool to see and study. It’s a great experiment.
I think it doesn’t really say a lot though. The hard part, in my opinion, is not making a new engine, it’s making one that’s worth using and will remain so for a long time.
What I’d love to see next is how well (or poorly) this approach is at making the performance not terrible.
Great. the one-agent-one-human repository by embedding-shapes is certainly quite nice and I had tried to re-create the results (within golang) though and I had failed but even within that I feel like maybe I learnt a lot of things (Also got to talk with emsh on bsky!)
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!
(I wonder what Simon thinks now of this, because from my skim of this article, they do seem to mention some tidbits about parallelism, Either way, I think that these projects are really adventurous and there is still something novel in all of this.)
(Edit: I have tried reading the blog post many times now but I am unable to understand how this is [working?] but something like cursor's project had turned to waste. Initially people were optimistic about cursor's project until emsh really showed them that it wasn't so good, I hope that this might not be the case here but still, I am just a bit confused as to why this in particular seems to work, kind of waiting for simon's post about it now :] )
If there is one thing that that agents/LLMs have highlighted, it is how much credit those test writers do deserve. Teams that were already following a TDD-style approach seem to be able to realize value from agents most easily because of their tests.
The tests are what enable: building a brand new JS runtime that works, rewriting a complex piece of code in a different language (e.g. Golang instead of TypeScript) that is more performant for that task, or even migrating off of an old stack (.NET WebForms) to something newer.
It is pretty incredible to me that in the pre-LLM/agent coding world, creating a new high-quality JS engine or browser seemed like it would likely never happen again. But now, any large company could build one if they wanted to. In a single digit number of months no less.
This is really cool to see and study. It’s a great experiment.
I think it doesn’t really say a lot though. The hard part, in my opinion, is not making a new engine, it’s making one that’s worth using and will remain so for a long time.
What I’d love to see next is how well (or poorly) this approach is at making the performance not terrible.
Great. the one-agent-one-human repository by embedding-shapes is certainly quite nice and I had tried to re-create the results (within golang) though and I had failed but even within that I feel like maybe I learnt a lot of things (Also got to talk with emsh on bsky!)
It will also be very interesting to read simonw's comments on all of this too (https://news.ycombinator.com/item?id=46779522#46786824) when he had said:-
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!
(I wonder what Simon thinks now of this, because from my skim of this article, they do seem to mention some tidbits about parallelism, Either way, I think that these projects are really adventurous and there is still something novel in all of this.)
(Edit: I have tried reading the blog post many times now but I am unable to understand how this is [working?] but something like cursor's project had turned to waste. Initially people were optimistic about cursor's project until emsh really showed them that it wasn't so good, I hope that this might not be the case here but still, I am just a bit confused as to why this in particular seems to work, kind of waiting for simon's post about it now :] )
Pretty neat as a real-sized-project experiment to see what a programming program can actually do.
Now do it without those pre-written tests. Spec only. Else, the writers of those tests deserve a LOT of credit.
If there is one thing that that agents/LLMs have highlighted, it is how much credit those test writers do deserve. Teams that were already following a TDD-style approach seem to be able to realize value from agents most easily because of their tests.
The tests are what enable: building a brand new JS runtime that works, rewriting a complex piece of code in a different language (e.g. Golang instead of TypeScript) that is more performant for that task, or even migrating off of an old stack (.NET WebForms) to something newer.