Simon Willison Vibecoded a SQLite Query Explainer With Claude Fable 5

Developer and Datasette creator Simon Willison read one line in Julia Evans' post Learning a few things about running SQLite — "Maybe one day I'll learn to read a query plan" — and turned it into working software the same day. Not by writing the tool himself, but by prompting Claude Fable 5, Anthropic's model released in June 2026, to build it for him.

What actually got built

The result is the SQLite Query Explainer, a browser page that runs a real SQLite engine client-side — Python compiled to WebAssembly via Pyodide, with SQLite running inside that Python. Type a query, and it runs both EXPLAIN (the raw virtual-machine bytecode SQLite executes) and EXPLAIN QUERY PLAN (the higher-level plan: which indexes get used, what gets scanned), then layers plain-English annotations over both. No server round-trip, no API call — the whole thing executes in the tab.

Maybe one day I'll learn to read a query plan.

— Julia Evans, Learning a few things about running SQLite

The caveat Willison put on his own tool

This is the part worth sitting with. Willison shipped the explainer with a built-in disclaimer: "Approach with caution, since I don't know enough about SQLite query plans to verify the results myself, but it seems cromulent enough to me." He didn't hide that he can't independently confirm the tool's explanations are accurate — because reading query plans is exactly the skill he doesn't have. He can verify that it runs, that it's useful, that it feels right. He cannot verify that it's correct in the way an SQLite internals expert could.

Why this is the actual vibecoding story

The headline version of this story is "AI built a working dev tool in a day," and that part is true and notable — Pyodide-in-the-browser SQLite tooling is not trivial plumbing. But the more useful story for builders is the caveat itself. Willison didn't pretend the model's output was ground truth just because it compiled and ran. He named the exact boundary of what he could personally validate and published that boundary alongside the tool.

That's the distinction that separates vibecoding as a productivity multiplier from vibecoding as a liability. An AI model can compress the distance between "I wish this existed" and a working prototype to almost nothing. It cannot compress the distance between "this runs without error" and "this is correct," especially in a domain — like SQLite's query planner internals — where being wrong looks exactly like being right until someone who actually knows the internals checks.

• Fast path: idea to working tool, same day, via prompting rather than manual implementation.
• Fixed cost: someone with real domain knowledge still has to check the output before it's trusted for anything beyond casual use.
• Honest disclosure — stating plainly what you can't verify — is itself part of shipping the tool responsibly, not an afterthought.