On July 4, 2026, Simon Willison shipped sqlite-utils 4.0rc2, a release candidate for the widely used Python library for working with SQLite databases. The notable part is not the transaction rewrite at the core of the 4.0 release. It is that Willison had Claude Fable review the previous release candidate before shipping, and the agent found five release blockers, including a silent data-loss bug that had survived every prior human review. The work ran to 37 prompts, 34 commits, and 30 files changed, for an estimated $149.25 in agent cost.
For anyone shipping software with AI assistance, this is a concrete look at what a final-review pass by a coding agent actually catches, what it misses, and how to wire it into your own release process.
What happened
sqlite-utils is one of the most downloaded SQLite tooling libraries in the Python ecosystem, and 4.0 is its biggest release in years. The headline change is a full rewrite of transaction handling: write statements now auto-commit unless a transaction is open, db.query() executes immediately instead of lazily, and a new migrations system runs inside transactions with rollback on failure. Those are exactly the kind of deep, cross-cutting changes where a subtle bug can hide for months. The complete list is in the sqlite-utils repository and its changelog.
Before promoting rc1 to a stable release, Willison opened Claude Code for web on his iPhone and gave Claude Fable a single instruction: do a final review before shipping the stable 4.0, and flag anything that would become a breaking change if fixed later. Fable came back with five release-blocking issues. This is the same Fable model behind Anthropic's recent coding push; our Claude Fable 5 guide covers the model itself.
The data-loss bug an AI agent caught
The most serious finding was in Table.delete_where(). The method ran its DELETE without an atomic() wrapper, so it left the database connection sitting in an open transaction. That open transaction then poisoned everything after it: any following inserts, and even a newly created table, would be silently rolled back when the connection closed. Nothing errored. The data just quietly vanished on the next open.
Fable did not just describe the problem. It produced a reproduction showing a delete, a set of new inserts, and a fresh table all disappearing after the database was reopened, then implemented the fix. The correction and the surrounding cleanup landed in pull request 767. A data-loss bug that produces no error message is the worst class of defect to ship, and it is precisely the kind that slips past manual testing because the happy path looks fine.
Claude Fable versus GPT-5.5: two AI reviewers, two findings
Willison did not stop at one model. After Fable's pass, he asked GPT-5.5 to review the changes since the last release candidate and confirm the changelog was current. The second model surfaced two more priority issues that Fable had not, both landing in pull request 768. Using two different agents as independent reviewers caught defects that neither found alone.
| Aspect | Claude Fable review | GPT-5.5 review |
|---|---|---|
| Prompt | Final review before shipping stable 4.0, flag latent breaking changes | Review changes since the last RC, confirm changelog is up to date |
| Issues found | 5 release blockers | 2 priority-1 issues |
| Headline defect | delete_where() data loss via uncommitted transaction | db.query() committing writes before raising validation errors |
| Second defect | Four further blockers across transactions and upserts | INSERT RETURNING not committing unless the generator is fully consumed |
| Landed in | PR 767 | PR 768 |
| Bonus output | Release notes the maintainer rated better than his own | Changelog accuracy confirmation |
The pattern here matters more than the specific bugs. Different models have different blind spots, so a two-reviewer setup functions like a code review panel rather than a single opinion.
How to run an AI release review on your own code
The workflow Willison used is simple enough to copy for any release, library or app. You do not need sqlite-utils; you need a coding agent with repository access and a disciplined prompt.
- Freeze a candidate. Tag a release candidate so the agent reviews a fixed state, not a moving branch.
- Prompt for latent breaking changes, not style. Ask specifically for issues that would become breaking changes if fixed after release. That framing pushes the agent toward correctness and API-stability bugs instead of cosmetic nits.
- Demand a reproduction for every claim. Require a runnable example that demonstrates each bug before any fix. This is what separated Fable's real finding from a plausible-sounding guess.
- Run a second, different model. Have a separate agent review the same diff with a slightly different brief, such as confirming the changelog matches the code. Independent reviewers catch non-overlapping defects.
- Let the agent write the release notes. Willison rated Fable's notes better than his own, calling this the kind of writing worth outsourcing because it needs to be boring, predictable, and accurate.
- Verify and merge deliberately. Read each fix, run the test suite, and merge the fixes as their own reviewed pull requests, exactly as PRs 767 and 768 were handled.
The library itself is on PyPI if you want to try the 4.0 release candidate and inspect the fixed behavior directly.
What this enables for creators and maintainers
The economics are the interesting part. Willison estimated the entire effort at $149.25 across five agent sessions, tracked inside the Claude Code session itself, with the main session accounting for $141.02. He noted that agent runs of 10 to 15 minutes let him step away and do other work between tasks. For a solo maintainer, spending roughly $150 to catch a silent data-loss bug before it reaches thousands of downstream users is an obvious trade.
The broader shift is that final-review QA, historically the hardest work to delegate because it demands full context, is becoming something an agent can genuinely assist with. That does not remove the maintainer from the loop; Willison still read, verified, and merged every fix himself. It changes what the maintainer spends attention on, from hunting for bugs to judging the agent's findings. It also raises the same governance questions we covered in our look at agentic technical debt in AI coding: code an agent writes and reviews still needs a human who understands it.
If you ship anything with a release cycle, the practical next step is to add an agent review pass to your pre-release checklist and to run at least two different models against it. The cost is small, the framing is easy to copy, and as this release showed, the class of bug it catches is the kind that never announces itself.
Frequently asked questions
What is sqlite-utils?
sqlite-utils is a popular open-source Python library and command-line tool by Simon Willison for creating and manipulating SQLite databases. Version 4.0 is a major release centered on a rewrite of how transactions and commits are handled.
What is Claude Fable?
Claude Fable is a Claude model from Anthropic tuned for coding and agentic work. In this case it ran inside Claude Code for web and reviewed a release candidate, found bugs, wrote reproductions, implemented fixes, and drafted release notes.
What was the data-loss bug it found?
The delete_where() method ran a DELETE without wrapping it in a transaction, leaving the connection in an open transaction state. Subsequent writes were then silently rolled back when the connection closed, so data disappeared with no error message.
Why did Simon Willison use two different AI models?
He ran Claude Fable first, then had GPT-5.5 review the same changes. The second model found two additional issues the first missed. Different models have different blind spots, so using two as independent reviewers catches more defects.
How much did the AI-assisted review cost?
Willison estimated $149.25 total across five agent sessions, with the main session consuming $141.02. The work spanned 37 prompts, 34 commits, and 30 files changed.
Is sqlite-utils 4.0 safe to use in production yet?
4.0rc2 is a release candidate, not a final stable release. It contains the fixes described here, but as a release candidate it is intended for testing. Check the official changelog before depending on it in production.
