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.
Their new CLI agent tool [1] is written in Python unlike similar agents from Anthropic/Google (Typescript/Bun) and OpenAI (Rust). It also appears to have first class ACP support, where ACP is the new protocol from Zed [2].
This is exactly the CLI I'm referring to, whose name implies it's for playing around with "vibe-coding", instead of helping professional developers produce high quality code. It's the opposite of what I and many others are looking for.
I think that's just the name they picked. I don't mind it. Taking a glance at what it actually does, it just looks like another command line coding assistant/agent similar to Opencode and friends. You can use it for whatever you want not just "vibe coding", including high quality, serious, professional development. You just have to know what you're doing.
For example, https://github.com/williamstein/nats-bugs/issues/5 links to a discussion I have with them about data loss, where they fundamentally don't understand that their incorrect defaults lead to data loss on the application side. It's weird.
I got very deep into using NATS last year, and then realized the choices it makes for persistence are really surprising. Another horrible example if that server startup time is O(number of streams), with a big constant; this is extremely painful to hit in production.
I ended up implementing from scratch something with the same functionality (for me as NATS server + Jetstream), but based on socket.io and sqlite. It works vastly better for my use cases, since socketio and sqlite are so mature.
reply