Even if no Rust code for it was seen during training, an LLM can trivially transpile SQLite's C codebase to Rust on the fly. For example, I just asked ChatGPT to write John Carmack's famous Fast Inverse Square Root algorithm in Erlang, without searching online or thinking, and it transpiled it immediately (while also extracting the knowledge in the same step). SQLite's semantics/code are stored in the middle layers of an LLM, and the last layers are able to convert it into any representation, as conditioned by the prompt. Cursor's experiment is deeply flawed because they merely extracted the model's compressed, lossy knowledge of SQLite's codebase and then just ran a bunch of tests/fixing rounds to make up for the lossiness. The claim that the agents built it from scratch is false.
Then you would expect the implementation to be structured the same as SQLite, and having glanced at the result, it looks like at least some things aren't. For example, it seems to use an operator-tree executor rather than SQLite's bytecode interpreter.
The point is that the model has the source code in its weights. Therefore it's misleading to focus on being "only given the documentation", when it could produce a SQLite implementation in rust with no documentation at all. The wording is designed to create a marketing impression that it can do spec-driven development for a novel project, but this example doesn't actually support that.
It's like a diet system advertising how much weight a spokesperson lost on their system, without disclosing that they also went on Ozempic at the same time.
The knowledge is lossy, and code generation itself is non-deterministic (temperature), so the operator-tree executor must be interference from other DB implementations, because it's uncommon to have a bytecode interpreter
Even if no Rust code for it was seen during training, an LLM can trivially transpile SQLite's C codebase to Rust on the fly. For example, I just asked ChatGPT to write John Carmack's famous Fast Inverse Square Root algorithm in Erlang, without searching online or thinking, and it transpiled it immediately (while also extracting the knowledge in the same step). SQLite's semantics/code are stored in the middle layers of an LLM, and the last layers are able to convert it into any representation, as conditioned by the prompt. Cursor's experiment is deeply flawed because they merely extracted the model's compressed, lossy knowledge of SQLite's codebase and then just ran a bunch of tests/fixing rounds to make up for the lossiness. The claim that the agents built it from scratch is false.
Then you would expect the implementation to be structured the same as SQLite, and having glanced at the result, it looks like at least some things aren't. For example, it seems to use an operator-tree executor rather than SQLite's bytecode interpreter.
The point is that the model has the source code in its weights. Therefore it's misleading to focus on being "only given the documentation", when it could produce a SQLite implementation in rust with no documentation at all. The wording is designed to create a marketing impression that it can do spec-driven development for a novel project, but this example doesn't actually support that.
It's like a diet system advertising how much weight a spokesperson lost on their system, without disclosing that they also went on Ozempic at the same time.
The knowledge is lossy, and code generation itself is non-deterministic (temperature), so the operator-tree executor must be interference from other DB implementations, because it's uncommon to have a bytecode interpreter
To test this hypothesis you would need to look at the initial version before subsequent agents started refactoring it.
3 replies →
There's Turso which is a sqlite rewrite in Rust with some additional features. It's open source so I'd imagine it would be in the training data.