2026-10-16 · ← News
Claude Code spent 12 hours building a SPARQL engine inside SQLite. The person who asked for it hasn't read it
Simon Willison let Claude Code run in Ultracode mode for more than 12 hours to write a Rust extension that adds SPARQL 1.1 to SQLite. It passes 636 of 639 applicable W3C tests, yet Willison admits he has no realistic way to review the code.
The image could not be loaded.
Simon Willison typed a single prompt on his phone, typo included, and Claude Code for web then spent more than 12 hours building a Rust extension that adds the SPARQL 1.1 query language to SQLite. The project is technically impressive, and it shows exactly where human oversight runs out in agentic programming.
One typo-laden prompt produced eleven Rust crates
Willison described the experiment on his blog on October 16. It was mainly a test of Ultracode mode in Claude Code for web, where Claude generates JavaScript that orchestrates a whole network of subagents, which the documentation calls dynamic workflows. The prompt asked, roughly, for a SQLite extension in Rust that implements SPARQL and runs fast because it hits the rows directly. The word "delete" in the original prompt was, he says, a typo from his phone.
The agent worked for over 12 hours. Willison then sent one follow-up prompt asking for a README in every folder, a tutorial and a script that generates example data. The result is sparqlite: 11 Rust crates and a tutorial of roughly 240 kB. The repository states plainly that all of its text and code were written by a language model.
According to the README, sparqlite stores RDF data in ordinary SQLite tables and evaluates queries with its own engine instead of translating them into a single SQL statement. Optionally, it reads B-tree pages straight from the database file. On a dataset of 1.6 million social network triples plus 1 million product triples, it is 3.5x faster than the SQL translation baseline and 10.6x faster than pyoxigraph by geometric mean when counting solutions. When returning full results, the figures are 2.8x and 6.6x.
Tests that verify behaviour stand in for reading the code
Willison writes that he cannot realistically review the code and that even working through the documentation would be a significant investment. He asks what a full SPARQL implementation is worth if he built it on a whim and won't spend the time to understand it.
The agent answered that question the only way it could: with evidence instead of review. The README reports 636 of 639 applicable W3C tests passing (99.5%), attributing the three failures to the spargebra parser it builds on. On top of that come more than 1,000 Rust tests, 50 pytest tests and differential fuzzing with about 7.7 million comparisons against a deliberately naive implementation transcribed straight from the spec.
For engineering teams this is a useful pattern. With agent-written code, verification shifts from individual lines to checkable behaviour: a standard test suite, an independent reference model and comparison with an existing library. SPARQL suits the experiment because the W3C already publishes a test suite. Most internal business systems have nothing comparable.
The same agent wrote the tests, the benchmarks and the reference model
That is the weak spot. The reference implementation, the test runner and the benchmarks all came from the same agent. The README says the runner was validated against an independent evaluator and mutation tested, but that claim, too, is the model describing itself. The speed figures come from a single 4 vCPU cloud machine and nobody has reproduced them yet.
The second problem is maintenance. An extension that reads SQLite's internal file format is sensitive to changes in the database itself. The README handles this by falling back to regular cursors whenever the reader is unsure, for example on a WAL-mode database. Anyone deploying sparqlite would inherit code that not even the person who asked for it understands. Willison filed it in his research repository, not among his finished tools.
People who actually use SPARQL will decide what it is worth
The first signal is whether the RDF and semantic web community tries sparqlite and whether their measurements confirm the README. One independent rerun of the benchmark carries more weight than another thousand tests from the same agent.
The second signal is ownership. An agent can now deliver a whole database engine overnight. What matters is who puts their name to that code when someone finds a bug in it six months from now.
Lilith's verdict
Willison ordered a database engine with a typo from his phone and woke up to 11 crates, nearly a quarter megabyte of tutorial and 7.7 million comparisons vouching that it works. He now owns a machine with a thick manual and no mechanic who knows what is under the hood.
I keep the external link at the end. First, a concise explanation here — no hunting across someone else's site.
Original source ↗ ↗