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.
Fixed! BSL (to my understanding) is a copy of the license and its a 'hashicorp document' so it had their title on it.
However, someone earlier today put me onto the concept of AGPL licenses so I changed MIRA over to AGPL because it still aligns with my overall intent of protecting my significant effort from someone coming in and Flappy Bird-ing it while still making it freely available to anyone who wants to access, modify, anything it.
We also had this recently with arduino. I don't understand why companies try to get that way. To me it is not an open source licence - it is a closed source business licence. Just with different names.
(As I said above I changed to an AGPL earlier today but I'll speak to my BSL logic)
I liked BSL because the code ~was~ proprietary for a time so someone couldn't duplicate my software I've worked so hard on, paywall it, and put me out of business. I'm a one-man development operation and a strong gust of wind could blow me over. I liked BSL because it naturally decayed into a permissive open source license automatically after a timeout. I'd get a head start but users could still use it and modify it from day one as long as they didn't charge money for it.
Totally fair - but just call it Source Available then.
Open Source has a specific definition and this license does not conform to that definition.
Stating it is open source creates a bait and switch effect with people who understand this definition, get excited, then realize this project is not actually open source.
Could you please stop that? First it is not true. "Open Source" has nothing to do with the "Open Source Initiative" it existed long before. Second you are making people keep their source closed (not available) which is not a good thing.
"Open Source has a specific definition and this license does not conform to that definition."
To be fair, this wouldn't be an issue if Open Source stuck with "Debian Free Software". If you really want to call it a bait and switch, open source did it first.
Meta leading the charge. Tencent just tried to do it this week. People need to to call them on it and AI ‘influencers’ never do, quite the opposite actually
I'm not seeing the justification for this comment. If anything that license, like the BSL, is aimed at keeping the small guy who worked on X in business so they can profit from their work (always need to put food on the table) while also sharing its innards with the world.
If you’re able to self host and run the tool for any use, it’s effectively a free, extensible, modifiable software solution.
Copyleft licenses are as restrictive as the license DHH put out with Fizzy. I’m an Apache 2.0 or MIT licensing OSS advocate myself, but it’s difficult to argue that it’s worse or equal to a fully closed SaaS solution.
It’s not even remotely close to one of these bullshit “ee” OSS licenses
Open source has an accepted and well understood meaning to developers; when people use the term to mean something other than that, it is 100% of the time for exploitative purposes, and they know they are being disingenuous.
I've used the term for 25+ years to describe my own source-included free software projects, and I'll thank you (and OSI) for not policing my language. No trademark? No standing. Choose other crusades.
Overreaction much? Nobody is policing. Your failure to recognize the meaning of a word - like any other - is just going to harm you due to your own ignorance of its ramifications.
(Shrug) As you will note at the top of the thread, williamstein is policing. All I'm doing is pointing out that the policeman has no badge, no gun, and no uniform, and that their cruiser looks suspiciously like a '92 Crown Victoria with black and white spray paint and a spotlight from Cabela's.
When you combine two words into a fundamentally novel phrase, you are not expressing an opinion, you are contributing to the global (or in this case, anglophone) dictionary.
So if you were to write that you are not in the habit of stealing from children, you might have your own idiosyncratic definition of "steal" or "child"?
Well, I certainly can't argue with that, um... logic.
Meanwhile, if anyone is entitled to the distinction of having "coined" the "fundamentally novel" phrase, it's a guy named Robert Steele who publicized the term "open source intelligence" in 1990 and organized the First International Symposium on Open Source Solutions in 1992.
Be that as it may, it's a generic phrase, as evinced by its prior usage in other fields like intelligence and journalism. Lacking a trademark, OSI has zero authority to word-police everyone else. No amount of plugging their ears and chanting lalalala will change the fact that OSI does not own exclusive rights to the phrase "open source." Not with respect to software, not with respect to anything else.
The author of the project in this article is perfectly within their rights to use the term, and the rest of us know very well what they mean by it.
"Steal" and "child" likewise lack any trademark protection.
So, suppose I accuse you of stealing from children, then when you protest, I
reply that the meaning I give those 2 words might not be the meaning most people have, but that is fine because no one owns the exclusive rights to those 2 words.
[1] https://jointmathematicsmeetings.org/meetings/national/jmm20...
reply