SEA with node.js "works" for nearly arbitrarily general node code -- pretty much anything you can run with node. However you may have to put in substantial extra effort, e.g., using [1], and possibly more work (e.g., copying assets out or using a virtual file system).
The current OpenClaw GitHub repo [1] contains 2.1 million lines of code, according to cloc, with 1.6M being typescript. It also has almost 26K commits.
This exact thing solves a huge problem with SEA binaries as he points out in his post. You can include complicated assets easily and skip an ugly unpack step entirely. This is very useful.
Everyone runs out of steam when it comes to WebAssembly. I used to wonder in the past why we hear so little about it, until I realised that nobody is really using it. Granted, there are those who use WebAssembly, but if we compare it to HTML, CSS, JavaScript, then WebAssembly is simply not existing anywhere near that level. After soon-to-be 10 years, that is very disappointing.
Why does it make sense to compare it to HTML, CSS and JavaScript?
You could say "Granted, there are those who use the webcam capture API, but if we compare it to HTML, CSS, JavaScript, then the webcam capture API is simply not existing anywhere near that level."
Like how not every website needs to use a webcam, not every website needs to port existing code to the web or accelerate heavy computation, which is what WASM is meant for... that doesn't mean it's not useful for ones that do. It's not supposed to replace any of HTML/CSS/JS
Because at the time of WebAssembly announcement all the doomsayers were screaming at the top of their lungs: "JS/TS are dead! Serious developer would never choose it! Finally I can have my <x> in the browser!"
No! WebAssembly is designed to be a complement to, not replacement of, JavaScript. While WebAssembly will, over time, allow many languages to be compiled to the Web, JavaScript has an incredible amount of momentum and will remain the single, privileged (as described above) dynamic language of the Web.”
It's getting there. There have been a lot of developments in WebAssembly in the past few years. I've felt the same pain so I just released a library to make it easier to run it in Java
He is trying to use a different phrase “write-only code” to define exactly the same thing Karpathy defined last year as “vibe coding”.
For what it is worth, in my experience one of the most important skills one should strive to get much better at to be good at using coding agents is reading and understanding code.
I think there's some value in pure vibe coding. To your point though, the best way to extract that value is to know intimately at which point the agents tend to break down in quality, which you can only do if you read a lot of their output. But once you reach that level, you can gain a lot by "one-shotting" tasks that you know are within their capacity, and isolating the result from the rest of your project.
I thought "vibe coding" had come to mean "I used an LLM to generate this code", but didn't really imply we'd given up trying to review and read the output. The author is taking it one-step further by suggesting we not bother with the latter.
It's true that the meaning of "vibe coding" has been somewhat diluted - but the original definition as set forth by Karpathy was to forget that the code even exists (no review, no reading the commits, nothing).
Sure, but the article is talking about people who can and do read code now but will develop software without reading code in the future. Kind of like you rarely look at the object code that the compiler produces.
> Checkpoints run as a Git-aware CLI. On every commit generated by an agent, it writes a structured checkpoint object and associates it with the commit SHA. The code stays exactly the same, we just add context as first-class metadata. When you push your commit, Checkpoints also pushes this metadata to a separate branch (entire/checkpoints/v1), giving you a complete, append-only audit log inside your repository. As a result, every change can now be traced back not only to a diff, but to the reasoning that produced it.
The context for every single turn could in theory be nearly 1MB. Since this context is being stored in the repo and constantly changing, after a thousand turns, won't it make just doing a "git checkout" start to be really heavy?
For example, codex-cli stores every single context for a given session in a jsonl file (in .codex). I've easily got that file to hit 4 GB in size, just working for a few days; amusingly, codex-cli would then take many GB of RAM at startup. I ended up writing a script that trims the jsonl history automatically periodically. The latest codex-cli has an optional sqlite store for context state.
My guess is that by "context", Checkpoints doesn't actually mean the contents of the context window, but just distilled reasoning traces, which are more manageable... but still can be pretty large.
In simpler terms - they create an MCP server, essentially an API that the coding agent can call, that can fill in context about previous decisions done by the coding agent earlier in development. Agent equivalent of asking someone who's been working there longer "why is this this way".
This means that the agent will can have context of previous decisions, something that they currently struggle with as they are always starting from a blank slate.
Coding agents starting from a blank slate isn’t good practice to begin with. That’s a vibe coding practice, not a practice that you’d start with when you want to build a real business serving customers. You start with specifications and design documents; you don’t leave those decisions to agents (although you can use agents to help design them). So the context ought to be there already.
> won't it make just doing a "git checkout" start to be really heavy?
not really? doesn't git checkout only retrieve the current branch? the checkpoint data is in another branch.
we can presume that the tooling for this doesn't expect you to manage the checkpoint branch directly. each checkpoint object is associated with a commit sha (in your working branch, master or whatever). the tooling presumably would just make sure you have the checkpoints for the nearby (in history) commit sha's, and system prompt for the agent will help it do its thing.
i mean all that is trivial. not worth a $60MM investment.
i suspect what is really going on is that the context makes it back to the origin server. this allows _cloud_ agents, independent of your local claude session, to pick up the context. or for developer-to-developer handoff with full context. or to pick up context from a feature branch (as you switch across branches rapidly) later, easily. yes? you'll have to excuse me, i'm not well informed on how LLM coding agents actually work in that way (where the context is kept, how easy it is to pick it back up again). this is just a bit of opining based on why this is worth 20% of $300MM.
if i look at https://chunkhound.github.io it makes me think entire is a version of that. they'll add an MCP server and you won't have to think about it.
finally, because there is a commit sha association for each checkpoint, i would be worried that history rewrites or force pushes MUST use the tooling otherwise you'd end up screwing up the historical context badly.
I strongly agree. The memory and cpu usage
of codex-cli is also extremely good. That codex-cli is open source is also valuable because you can easily get definitive answers to any questions about its behavior.
[1] https://www.npmjs.com/package/@vercel/ncc
reply