Home
Jul 5, 2026
View All

What AI Really Costs to Build: Simon Willison's $149 Experiment

The Short Version#

Simon Willison published a detailed accounting of using Claude Fable to write most of sqlite-utils 4.0rc2 for $149.25 — and separately flagged a frustrating pattern where model quality goes up but the tools around them get worse. Both posts together are the most useful thing a PM thinking about AI-assisted development could read today.

Simon Willison — sqlite-utils 4.0, mostly written by Claude Fable for $149.25#

Source: https://simonwillison.net/2026/Jul/5/sqlite-utils-fable/#atom-everything Credibility: High (first-person account from a highly credible practitioner, with cost receipts)

What happened: Simon Willison shipped sqlite-utils 4.0rc2, an open-source Python library he's maintained for years, and published a detailed breakdown of what it cost to have Claude Fable write most of it: $149.25. This isn't a vibe-coded toy. sqlite-utils is a real, production-quality developer tool with an established user base. The post is notable because it's one of the most concrete cost-and-output breakdowns from a credible technical practitioner, not a startup founder making a growth claim.

Key patterns:

  • The $149.25 figure covers meaningful feature work on a real, maintained open-source project — not a throwaway script or a demo
  • Willison is explicit that Fable "mostly wrote" the release, implying a significant portion of actual implementation
  • This is a continuation of his pattern of publishing cost-per-task data, which is rare in a landscape full of "AI 10x productivity" claims with no numbers attached
  • sqlite-utils is a tool Willison knows deeply — he can evaluate output quality in a way most casual vibe-coders cannot

Why it matters for PMs: This is one of the cleanest data points we have on what AI-assisted development actually costs at the task level on a non-trivial project. $149 to ship a release candidate of a real library is striking. For PMs evaluating AI coding tool investments, this is the kind of unit economics you should be asking your eng teams to track. It also sets up a useful question: if a maintainer with deep domain knowledge can use AI this effectively, what does that imply for teams where domain knowledge is distributed or partial?

Critical questions:

  • How much of the $149 was revision and correction versus first-pass generation? The cost figure alone doesn't tell you the iteration count.
  • What's Willison's review and testing overhead on top of the generation cost? The AI cost is only part of the total effort.
  • Would this generalize to teams where the human reviewer doesn't have Willison's depth of context on the codebase?
  • Is this the kind of cost structure that holds for new feature work, or mainly for maintenance/refactoring tasks?

Action you could take today: Ask your engineering leads to start logging AI coding tool costs per task or per sprint on one real project for the next four weeks. Willison's transparency here is rare — and that's exactly why it's valuable. Having your own baseline changes every future "AI saves us time" conversation.

Simon Willison — Better Models, Worse Tools#

Source: https://simonwillison.net/2026/Jul/4/better-models-worse-tools/#atom-everything Credibility: High (practitioner perspective from one of the most prolific AI tool critics writing today)

What happened: Willison published a post flagging a pattern he's observed: as underlying model quality improves, the tool interfaces around them are getting worse. The core argument is that the product layer — the UX, the context management, the workflow integrations — is degrading even as raw model capability increases. This isn't abstract. He's writing from direct, daily use of these tools for real work.

Key patterns:

  • The "better models, worse tools" framing names something a lot of practitioners feel but haven't articulated cleanly
  • The complaint isn't about model quality — it's about the gap between what models can do and what the products built around them actually let you do
  • This is a product critique, not a research critique: it's about UX, workflow, and interface decisions that tool builders are making (or not making)
  • The timing — published the same day as his sqlite-utils cost breakdown — makes this a useful pair: one post shows what's possible, the other explains why it's harder than it should be

Why it matters for PMs: This is the product tension that doesn't get enough airtime. Most AI product conversation focuses on capability improvements — better benchmarks, longer context, cheaper tokens. Willison is pointing at the other side of the equation: the product experience that wraps the model is often getting worse because teams are chasing model updates rather than investing in workflow quality. For anyone building AI-powered products, this is a direct challenge to your prioritization. When did you last ship something that made the experience better without the underlying model changing?

Critical questions:

  • Which specific tools is Willison calling out? The post title is strong but the PM relevance depends on whether the critique lands on tools your team uses or builds.
  • Is this a temporary regression during a period of rapid capability change, or a structural incentive problem (teams optimize for model benchmarks because those are measurable)?
  • How do you know if your own product is making this mistake? What signals would tell you that your tool UX is degrading relative to the model it wraps?
  • Does this pattern hold across categories, or is it specific to coding tools where workflow integration is especially complex?

Action you could take today: Pull up your product's last five releases. Count how many shipped improvements to the underlying model or AI capability versus improvements to the workflow, UX, or experience around it. If the ratio skews heavily toward capability, you may be living this pattern.

Lenny Rachitsky — Community Wisdom: Quarterly Planning and AI#

Source: https://www.lennysnewsletter.com/p/community-wisdom-quarterly-planning Credibility: High (Lenny's Newsletter, community wisdom from practitioners)

What happened: Lenny's Newsletter issue 192 in the Community Wisdom series focuses on quarterly planning and AI, along with cash vs. equity comp, paying for interview exercises, AI-powered outbound, and compliance startup opportunities. The "quarterly planning and AI" thread is the most PM-relevant signal here — it's a real-time pulse on how practitioners are integrating AI into planning cycles, not retrospective analysis.

Key patterns (based on the Community Wisdom format):

  • The "quarterly planning and AI" framing suggests practitioners are now thinking about AI not just as a tool to use, but as something that changes how planning works
  • AI-powered outbound as a topic signals that the "AI for GTM" conversation has moved from hype to active experimentation
  • The presence of "compliance startup opportunities" alongside AI topics reflects a maturing market where AI is creating regulatory surface area, not just capability

Why it matters for PMs: If you're heading into Q3 planning right now (which most teams are), the question of how AI changes the planning process itself is live. Does AI help you do better discovery faster? Does it change how you synthesize user research before planning? Does it create new risks in the form of AI-powered outbound that your roadmap needs to account for? This is the community conversation happening in parallel to your own planning cycle.

Critical questions:

  • What specific practices are practitioners sharing about AI in quarterly planning — is it AI-assisted research synthesis, or something more structural?
  • Is there evidence that AI is changing the cadence of planning (more frequent cycles) or just the tooling?
  • How is the community distinguishing between "AI helps me plan" and "AI changes what I should plan for"?

Action you could take today: Before your next planning session, ask each PM on your team to spend 30 minutes using their AI tool of choice to synthesize user feedback or research from the last quarter. Compare what surfaced versus your normal synthesis process. The delta tells you something real.

Quick Hits#

  • Simon Willison: "Better Models: Worse Tools" — the product UX around AI tools is degrading even as model quality improves. Sharp critique worth reading if you're building AI-powered products. (2026-07-05): https://simonwillison.net/2026/Jul/4/better-models-worse-tools/#atom-everything

  • Aravind Srinivas (Perplexity): Announced Perplexity integration on Intel Ultra Series 3 laptops with local models and hybrid inference — Perplexity moving into the on-device/local model space via hardware partnerships. (2026-07-05): https://x.com/AravSrinivas

  • Notion: Published a post on what they learned during the Custom Agents beta — Notion's co-founder Akshay Kothari on autonomous AI teammates handling entire workflows. A rare "what we actually learned" from a beta, not just a launch announcement. (recent): https://www.notion.com/blog/what-we-learned-during-the-custom-agents-beta

  • Clement Delangue (Hugging Face): Posted that open-source AI allows frontier labs to share compute and spending, making them "an order of magnitude more efficient" than closed-source. Frames open-source as a structural cost advantage, not just a philosophical one. (2026-07-04): https://x.com/ClementDelangue

  • Lenny Rachitsky: Community Wisdom 192 on quarterly planning and AI — real practitioner patterns on integrating AI into planning cycles, right as Q3 planning kicks off. (2026-07-04): https://www.lennysnewsletter.com/p/community-wisdom-quarterly-planning

The Thread#

The gap between capability and product is widening. Willison's $149 sqlite-utils release shows what's possible when model capability and practitioner skill align. His "Better Models, Worse Tools" post explains why that combination is rarer than it should be: the product layer isn't keeping up. This week's pattern — from Vercel's sandbox filesystem updates to Cursor's team MCP rollout to Notion's agent beta learnings — all point at teams trying to close that gap in their own ways. The ones who are shipping real workflow improvements, not just capability improvements, are the signal worth tracking.

Sit With This#

Simon Willison published a $149 cost breakdown for shipping a real open-source library release — one of the most concrete unit-economics data points we have for AI-assisted development on a non-trivial project. On the same day, he argued that tool UX is getting worse even as models improve.

For your product: If your team has been shipping AI capability improvements but hasn't invested comparably in the workflow and UX around those capabilities, how would you know? What metric or signal would tell you your users are hitting the "better model, worse tool" problem in your product?