You can call it what you want I guess, but "vibe coded" around these parts is a simple pejorative, it means the authors don't know what the code does and the product is poor quality.
Most successful agent-coded projects have a few essential features that it's worth calling out: 1) The human driving it has real domain expertise; 2) There's an oracle for correctness; 3) The agent has a real-world example to copy, adapt, or translate.
This project had all these elements. The human driving the agent understood the technical and product decisions that make a version-controlled database work, because he's been doing that for 8 years. The project uses the existing 5.7M query test suite for SQLite3 as its oracle, as well as adapted versions of Dolt's extensive test suite to verify the version-control features that SQLite has no tests for. And the agent had a human-written implementation of the core product (Dolt) to crib from.
All of this is to say: yes, agents wrote this code, but if you or another randomly chosen software engineer sat down and tried to duplicate this result you wouldn't succeed. You wouldn't know what the agent had gotten wrong at every step of development, or even what questions to ask to find out where the errors might be. Despite the existence of a correctness oracle, the agent on its own cannot iterate to 100% correctness without a domain expert steering it. And that expert also has to have an extensive understanding of the existing code base that's being copied. You can't just say "Claude, implement version control in SQLite3, make no mistakes", it's not going to work.
You use it to write version-controlled applications, so that your structured table data gets the same collaboration and auditing benefits that your source code enjoys. This is a couple years of out date but should give you an idea for how it's being used in the real world.
For DoltLite, the big use case is embedded local-first development. It's a DB you can write to locally offline, then sync to a remote server when you have connectivity. Crucially, this works in both directions, and tolerates writes from multiple offline clients by merging their changes together.
Neon is basically this same idea: postgres on a copy-on-write file system.
These aren't really "branches" though, they're hard forks. You can't merge them back after making changes. Dolt is still the only SQL database with branch and merge.
It was https://threekit.com. It was a while ago now but we had to use MySQL for our primary copy that users used (e.g. prod), and only when they were working on branches did we use dolt. I think the second complication was that Dolt was not stable enough to use in heavy load scenarios as well.
I can delete this comment if you do not want to discuss this publicly.
I remember that engineering decision. You guys were pretty early customers for your throughput and durability requirements (we hadn't even added standby replication yet when you started your integration). We've come a long way in the years since then.
Regardless of whether this particular project goes anywhere, it's at least very interesting that Yegge has discovered a way to make multi-agent setups work better. Giving them discrete personas ("you are a senior database engineer with 30 years of experience") and narrower scopes makes them much more effective. This was surprising to me but makes a lot of sense in retrospect.
The part that always struck me as weird about this stuff is that all of these "agents" with their "personas" are the same baseline LLMs with the same training ultimately, just told to basically pretend they're different. How far can that really get you?
I'm not actually a database engineer with 30 years of experience. If somebody demanded that I pretend to be one, I guess I'd give it a shot, but I would expect any actual employer would be able to tell that I don't have the level of knowledge and experience that you'd expect from somebody like that.
If the base LLM actually has the knowledge of all of these specialties, why can't it just apply them all at once, instead of needing to be told to I guess pretend to be only one of them.
Agreed, would really like to understand what this (setting the LLM up to assume a role to improve performance) is doing under the cover and why it works.
Why aren't the labs training models to pick a mantra appropriate to the task and do this themselves? "Huh, a database question. I am going to pretend I'm a database expert with lots of experience. OK, here we go!"
Most successful agent-coded projects have a few essential features that it's worth calling out: 1) The human driving it has real domain expertise; 2) There's an oracle for correctness; 3) The agent has a real-world example to copy, adapt, or translate.
This project had all these elements. The human driving the agent understood the technical and product decisions that make a version-controlled database work, because he's been doing that for 8 years. The project uses the existing 5.7M query test suite for SQLite3 as its oracle, as well as adapted versions of Dolt's extensive test suite to verify the version-control features that SQLite has no tests for. And the agent had a human-written implementation of the core product (Dolt) to crib from.
All of this is to say: yes, agents wrote this code, but if you or another randomly chosen software engineer sat down and tried to duplicate this result you wouldn't succeed. You wouldn't know what the agent had gotten wrong at every step of development, or even what questions to ask to find out where the errors might be. Despite the existence of a correctness oracle, the agent on its own cannot iterate to 100% correctness without a domain expert steering it. And that expert also has to have an extensive understanding of the existing code base that's being copied. You can't just say "Claude, implement version control in SQLite3, make no mistakes", it's not going to work.