sqlite-utils 4.1: the first dot-release after the Claude Fable rewrite
Simon Willison has released sqlite-utils 4.1, the first dot-release after version 4.0rc2 written almost entirely with Claude Fable. The update introduces five minor features: the --code option to generate rows to insert directly from Python code, --type to force column type (useful for postal codes that look like integers but should be stored as text), a method to drop indexes, the ability to read SQL queries from standard input, and support for switching a table from strict to non-strict mode and back.
Why it matters to you: code written by an agent four days ago has survived the first true development cycle. Willison used GPT-5.6 Sol xhigh Codex to implement the features, and explicitly asked the model to manually test its own work outside automated tests. This round caught two minor bugs that unit tests had missed. It’s not his first time shipping AI-assisted code, but it’s the first time an entire codebase was rewritten by an agent and the first subsequent update confirms that rewritten base is solid.
Where to look: Willison always publishes full transcripts of Codex sessions. The most interesting prompt is «use uv run python -c and manually exercise the new .transform(strict=) option, see if you can find any edge-cases or bugs», which delegates manual exploratory testing to the model.
The details
Context
Four days ago Willison had shipped sqlite-utils 4.0rc2, a release candidate written almost entirely by Claude Fable in 37 prompts for roughly $149. That rewrite touched much of the codebase, adding schema migrations and other structural features. The 4.1 is the first dot-release after that rewrite, and the real test of how maintainable that code is.
New features
Five additions, all small but long-requested:
-
--codefor insert and upsert: instead of importing data from files, you can pass a Python code block (or path to a.py) that defines arows()function or an iterable of rows. Extends the pattern sqlite-utils already used forsqlite-utils convert, where you pass code blocks as CLI arguments. -
--typefor column type override: when creating a table from CSV or TSV, you can force a column’s type. Useful for postal codes or identifiers that look like numbers but must stay text to preserve leading zeros. A feature requested back in 2019 (issue #131), implemented now because Codex flagged it as “easy” while reviewing all open issues. -
Drop indexes: new
table.drop_index(name)method andsqlite-utils drop-indexcommand, both withignore=True/--ignoreoption to not fail if the index doesn’t exist. -
Queries from stdin:
sqlite-utils querynow accepts-instead of SQL query to read from standard input. Enablesecho "select * from dogs" | sqlite-utils query dogs.db -. -
Toggle strict mode:
table.transform()andsqlite-utils transformcommand now accept--strictand--no-strictto convert a table from strict to non-strict mode and back. Inspired by a post from Evan Hahn observing that there’s no ALTER TABLE to change strict mode: sqlite-utils’transformmechanism, which copies data to a new table, is exactly what’s needed.
The workflow
Willison used GPT-5.6 Sol xhigh via Codex. The most significant prompt of the session was: «use uv run python -c and manually exercise the new .transform(strict=) option, see if you can find any edge-cases or bugs». It delegates to the model not just code writing but manual exploratory testing outside automated tests. This round found two minor bugs that unit tests hadn’t caught, which were fixed in the same session.
What it means
The 4.0 was a deep rewrite. The 4.1, shipped four days later, shows that rewritten codebase has survived its first true development cycle: the agent that wrote it left no hidden technical debt, and a second agent (different model) could work on top of it without incident. Code written by an agent ships, and the code that follows continues to ship.
Willison always publishes full transcripts, letting you see exactly which prompts produced what. This is the thread we’re following: agents writing code that reaches production, with cost and constraints documented each time.