Simon Willison’s sqlite-utils 4.0rc2 write-up is a better AI coding story than most benchmark charts because it has friction.
Willison used Claude Fable through Claude Code for web, including from his phone, to review and harden a release candidate for sqlite-utils, his Python CLI and library for manipulating SQLite databases. The numbers are concrete: 37 prompts, 34 commits, changes across 30 files, and an estimated unsubsidized usage cost of $149.25.
That is a very different claim from “AI wrote my app.” This was an experienced maintainer using an agent on a mature open-source project with tests, documentation, release notes, versioning concerns and a high bar for breaking changes.
GearPulse’s view: the story matters because it makes agentic coding look less magical and more useful. The agent produced work. The maintainer supplied taste, constraints, review, escalation and final responsibility.
The useful part is the workflow
The sqlite-utils project is not a toy. Its GitHub repository describes it as a Python CLI utility and library for manipulating SQLite databases. PyPI lists it as a developer-facing tool with Python 3.10-plus support, Apache 2.0 licensing and production/stable metadata for the current release line.
That context matters because a release candidate is the worst place to be casual. You are not just adding a demo feature. You are deciding whether migrations, transactions, documentation and edge cases are boring enough to trust.
Willison’s write-up says Fable found problems he had not encountered yet, including release blockers. One highlighted issue involved delete_where() behavior and transaction handling. He then used the agent through a sequence of commits, docs updates and checks, before also using GPT-5.5 xhigh as a separate review pass.
The pattern is worth copying:
| Step | Human job | Agent job |
|---|---|---|
| Define the mission | Ask for final release review, not vague improvement | Inspect code, docs and tests for concrete blockers |
| Triage findings | Decide which issues matter before 4.0 | Group, explain and prioritize problems |
| Patch iteratively | Review each commit and keep scope under control | Implement fixes, tests and docs updates |
| Cross-check | Bring in another model and human judgment | Find second-order issues and missed assumptions |
| Ship cautiously | Keep release-candidate framing | Avoid pretending the work is magically final |
The phone detail is easy to overplay, but it is relevant. Agentic coding changes where maintenance work can happen. A maintainer can review plans, unblock a run and ask for the next slice while away from the desk. That is not the same as fully autonomous software engineering. It is asynchronous pair programming with a tireless junior who can sometimes act senior if the constraints are good enough.
The cost number is the right kind of uncomfortable
The $149.25 estimate is not cheap in the abstract. It is also not absurd for a release-hardening pass on a meaningful developer tool.
That tension is useful. AI coding cost should not be judged as “free magic” or “too expensive” without comparing it to the work displaced or improved. If the agent finds a release-blocking transaction bug before users hit it, the cost can be easy to justify. If it spends the same money churning low-value refactors, the economics fall apart.
For developers, the lesson is not “spend $149 on every release.” It is to use agents where the work has leverage:
| Good agent target | Weak agent target |
|---|---|
| Release-candidate review with tests and docs | Open-ended “make it better” prompts |
| Repetitive fixes across many files | Taste-heavy product decisions with unclear goals |
| Changelog and documentation consistency | Blind rewrites of working APIs |
| Cross-checking migration or transaction edge cases | Shipping without human review |
| Running experiments and reporting results | Assuming generated confidence equals correctness |
Agentic coding gets more valuable when the repo has enough structure for the agent to lean on. Tests, changelogs, examples and conventions become steering systems.
Fable’s timing makes the story sharper
Anthropic’s official Fable 5 redeployment note says access was restored globally on July 1, 2026 after export controls were lifted. It also says Fable 5 would be available on Claude Platform, Claude.ai, Claude Code and Claude Cowork, with some paid plans getting up to 50 percent of weekly usage limits through July 7 before usage credits apply.
That timing explains part of the urgency in Willison’s experiment. Fable was available, powerful, temporarily bundled for some users and about to become more explicitly metered. That creates a natural question for developers: what kind of work is worth spending high-end model budget on?
The sqlite-utils example answers better than a generic coding demo. Spend it on the part of the work where mistakes are expensive and judgment matters.
The caveat: this is not push-button maintenance
The story only works because Willison knows the project deeply. He can judge whether a suggested transaction model makes sense, whether a changelog entry is accurate, whether a breaking change is acceptable and whether a test is proving the right thing.
That is the part many agentic-coding narratives skip. The model can generate code, tests and documentation quickly. It cannot own the social contract of an open-source release. It does not know which incompatibilities users will forgive, which abstractions fit the project’s philosophy, or how much churn is acceptable before a 4.0 stable release.
For less experienced developers, the danger is confusing velocity with control. An agent that can modify 30 files is useful. It is also capable of spreading a wrong assumption across 30 files very efficiently.
Bottom line
The sqlite-utils 4.0rc2 story is relevant because it shows a realistic version of AI-assisted software maintenance: a capable agent, a real project, real costs, real review and a maintainer still firmly in charge.
GearPulse’s read: this is where agentic coding is strongest today. Not as a replacement for engineering judgment, but as a way to multiply it when the human can set the bar, inspect the output and keep the release honest.
The future of developer tools will not be “the model writes everything.” It will be maintainers learning which work to delegate, which work to verify twice, and which work should remain human because the tradeoffs are not in the code alone.