Simon Willison's Weblog: geoffrey-litt

Quoting Geoffrey Litt

2025-10-24T14:07:11+00:00

A lot of people say AI will make us all "managers" or "editors"...but I think this is a dangerously incomplete view!

Personally, I'm trying to code like a surgeon.

A surgeon isn't a manager, they do the actual work! But their skills and time are highly leveraged with a support team that handles prep, secondary tasks, admin. The surgeon focuses on the important stuff they are uniquely good at. [...]

It turns out there are a LOT of secondary tasks which AI agents are now good enough to help out with. Some things I'm finding useful to hand off these days:

Before attempting a big task, write a guide to relevant areas of the codebase

Spike out an attempt at a big change. Often I won't use the result but I'll review it as a sketch of where to go

Fix typescript errors or bugs which have a clear specification

Write documentation about what I'm building

I often find it useful to run these secondary tasks async in the background -- while I'm eating lunch, or even literally overnight!

When I sit down for a work session, I want to feel like a surgeon walking into a prepped operating room. Everything is ready for me to do what I'm good at.

— Geoffrey Litt, channeling The Mythical Man-Month

Tags: ai, generative-ai, llms, ai-assisted-programming, geoffrey-litt, coding-agents, parallel-agents

Enough AI copilots! We need AI HUDs

2025-07-27T22:15:55+00:00

Enough AI copilots! We need AI HUDs

Geoffrey Litt compares Copilots - AI assistants that you engage in dialog with and work with you to complete a task - with HUDs, Head-Up Displays, which enhance your working environment in less intrusive ways.

He uses spellcheck as an obvious example, providing underlines for incorrectly spelt words, and then suggests his AI-implemented custom debugging UI as a more ambitious implementation of that pattern.

Plenty of people have expressed interest in LLM-backed interfaces that go beyond chat or editor autocomplete. I think HUDs offer a really interesting way to frame one approach to that design challenge.

Tags: design, design-patterns, ai, generative-ai, llms, geoffrey-litt

Malleable software

2025-06-11T19:21:39+00:00

Malleable software

New, delightful manifesto from Ink & Switch.

In this essay, we envision malleable software: tools that users can reshape with minimal friction to suit their unique needs. Modification becomes routine, not exceptional. Adaptation happens at the point of use, not through engineering teams at distant corporations.

This is a beautifully written essay. I love the early framing of a comparison with physical environments such as the workshop of a luthier:

A guitar maker sets up their workshop with their saws, hammers, chisels and files arranged just so. They can also build new tools as needed to achieve the best result—a wooden block as a support, or a pair of pliers sanded down into the right shape. […] In the physical world, the act of crafting our environments comes naturally, because physical reality is malleable.

Most software doesn’t have these qualities, or requires deep programming skills in order to make customizations. The authors propose “malleable software” as a new form of computing ecosystem to “give users agency as co-creators”.

They mention plugin systems as one potential path, but highlight their failings:

However, plugin systems still can only edit an app's behavior in specific authorized ways. If there's not a plugin surface available for a given customization, the user is out of luck. (In fact, most applications have no plugin API at all, because it's hard work to design a good one!)

There are other problems too. Going from installing plugins to making one is a chasm that's hard to cross. And each app has its own distinct plugin system, making it typically impossible to share plugins across different apps.

Does AI-assisted coding help? Yes, to a certain extent, but there are still barriers that we need to tear down:

We think these developments hold exciting potential, and represent a good reason to pursue malleable software at this moment. But at the same time, AI code generation alone does not address all the barriers to malleability. Even if we presume that every computer user could perfectly write and edit code, that still leaves open some big questions.

How can users tweak the existing tools they've installed, rather than just making new siloed applications? How can AI-generated tools compose with one another to build up larger workflows over shared data? And how can we let users take more direct, precise control over tweaking their software, without needing to resort to AI coding for even the tiniest change?

They describe three key design patterns: a gentle slope from user to creator (as seen in Excel and HyperCard), focusing on tools, not apps (a kitchen knife, not an avocado slicer) and encouraging communal creation.

I found this note inspiring when considering my own work on Datasette:

Many successful customizable systems such as spreadsheets, HyperCard, Flash, Notion, and Airtable follow a similar pattern: a media editor with optional programmability. When an environment offers document editing with familiar direct manipulation interactions, users can get a lot done without needing to write any code.

The remainder of the essay focuses on Ink & Switch's own prototypes in this area, including Patchwork, Potluck and Embark.

Honestly, this is one of those pieces that defies attempts to summarize it. It's worth carving out some quality time to spend with this.

Via lobste.rs

Tags: design-patterns, ai, generative-ai, llms, ai-assisted-programming, local-first, geoffrey-litt, ink-and-switch

Stevens: a hackable AI assistant using a single SQLite table and a handful of cron jobs

2025-04-13T20:58:09+00:00

Stevens: a hackable AI assistant using a single SQLite table and a handful of cron jobs

Geoffrey Litt reports on Stevens, a shared digital assistant he put together for his family using SQLite and scheduled tasks running on Val Town.

The design is refreshingly simple considering how much it can do. Everything works around a single memories table. A memory has text, tags, creation metadata and an optional date for things like calendar entries and weather reports.

Everything else is handled by scheduled jobs to popular weather information and events from Google Calendar, a Telegram integration offering a chat UI and a neat system where USPS postal email delivery notifications are run through Val's own email handling mechanism to trigger a Claude prompt to add those as memories too.

Here's the full code on Val Town, including the daily briefing prompt that incorporates most of the personality of the bot.

Tags: sqlite, ai, generative-ai, llms, geoffrey-litt, val-town, ai-personality

Ambsheets: Spreadsheets for exploring scenarios

2025-02-05T02:50:22+00:00

Ambsheets: Spreadsheets for exploring scenarios

Delightful UI experiment by Alex Warth and Geoffrey Litt at Ink & Switch, exploring the idea of a spreadsheet with cells that can handle multiple values at once, which they call "amb" (for "ambiguous") values. A single sheet can then be used to model multiple scenarios.

Here the cell for "Car" contains {500, 1200} and the cell for "Apartment" contains {2800, 3700, 5500}, resulting in a "Total" cell with six different values. Hovering over a calculated highlights its source values and a side panel shows a table of calculated results against those different combinations.

Always interesting to see neat ideas like this presented on top of UIs that haven't had a significant upgrade in a very long time.

Via Hacker News

Tags: spreadsheets, ui, ux, geoffrey-litt, ink-and-switch

Quoting Geoffrey Litt

2025-01-15T16:15:54+00:00

Today's software ecosystem evolved around a central assumption that code is expensive, so it makes sense to centrally develop and then distribute at low marginal cost.

If code becomes 100x cheaper, the choices no longer make sense! Build-buy tradeoffs often flip.

The idea of an "app"—a hermetically sealed bundle of functionality built by a team trying to anticipate your needs—will no longer be as relevant.

We'll want looser clusters, amenable to change at the edges. Everyone owns their tools, rather than all of us renting cloned ones.

— Geoffrey Litt

Tags: ai, generative-ai, llms, ai-assisted-programming, geoffrey-litt

Quoting Geoffrey Litt

2024-12-23T04:22:56+00:00

Whether you’re an AI-programming skeptic or an enthusiast, the reality is that many programming tasks are beyond the reach of today’s models. But many decent dev tools are actually quite easy for AI to build, and can help the rest of the programming go smoother. In general, these days any time I’m spending more than a minute staring at a JSON blob, I consider whether it’s worth building a custom UI for it.

— Geoffrey Litt

Tags: ai, generative-ai, llms, ai-assisted-programming, geoffrey-litt

Towards universal version control with Patchwork

2024-05-08T01:44:26+00:00

Towards universal version control with Patchwork

Geoffrey Litt has been working with Ink & Switch exploring UI patterns for applying version control to different kinds of applications, with the goal of developing a set of conceptual primitives that can bring branching and version tracking to interfaces beyond just Git-style version control.

Geoffrey observes that basic version control is already a metaphor in a lot of software—the undo stack in Photoshop or suggestion mode in Google Docs are two examples.

Extending that is a great way to interact with AI tools as well—allowing for editorial bots that can suggest their own changes for you to accept, for example.

Via @stevekrouse

Tags: version-control, ai, generative-ai, llms, geoffrey-litt, ink-and-switch

Quoting Geoffrey Litt

2024-03-18T18:16:09+00:00

It's hard to overstate the value of LLM support when coding for fun in an unfamiliar language. [...] This example is totally trivial in hindsight, but might have taken me a couple mins to figure out otherwise. This is a bigger deal than it seems! Papercuts add up fast and prevent flow. (A lot of being a senior engineer is just being proficient enough to avoid papercuts).

— Geoffrey Litt

Tags: programming, ai, llms, geoffrey-litt

You Can Build an App in 60 Minutes with ChatGPT, with Geoffrey Litt

2024-01-10T23:41:15+00:00

You Can Build an App in 60 Minutes with ChatGPT, with Geoffrey Litt

YouTube interview between Dan Shipper and Geoffrey Litt. They talk about how ChatGPT can build working React applications and how this means you can build extremely niche applications that you woudn’t have considered working on before—then to demonstrate that idea, they collaborate to build a note-taking app to be used just during that specific episode recording, pasting React code from ChatGPT into Replit.

Geoffrey: “I started wondering what if we had a world where everybody could craft software tools that match the workflows they want to have, unique to themselves and not just using these pre-made tools. That’s what malleable software means to me.”

Via Ian Maurer

Tags: ai, react, generative-ai, chatgpt, llms, geoffrey-litt

Quoting Geoffrey Litt

2023-03-27T06:10:29+00:00

I think it’s likely that soon all computer users will have the ability to develop small software tools from scratch, and to describe modifications they’d like made to software they’re already using.

— Geoffrey Litt

Tags: ai, generative-ai, llms, geoffrey-litt

SQLite Happy Hour - a Twitter Spaces conversation about three interesting projects building on SQLite

2022-03-23T22:01:07+00:00

Yesterday I hosted SQLite Happy Hour. my first conversation using Twitter Spaces. The idea was to dig into three different projects that were doing interesting things on top of SQLite. I think it worked pretty well, and I'm curious to explore this format more in the future.

Here's the tweet that initially promoted the space:

Interested in devious tricks to push the envelope of what you can do with SQLite?

Join myself, @benbjohnson, @geoffreylitt and @nschiefer on Tuesday for a Twitter Spaces conversation about @litestream, @datasetteproj and Riffle!https://t.co/ukRMVgC09u
- Simon Willison (@simonw) March 17, 2022

My co-hosts, representing the three projects, were:

Ben Johnson @benbjohnson, creator of Litestream - a tool that adds replication to SQLite built on top of the WAL mechanism.
Geoffrey Litt @hgeoffreylitt and Nicholas Schiefer @nschiefer who are working on Riffle, a project exploring the idea of driving reactive user interfaces using SQL queries - see Building data-centric apps with a reactive relational database.

Twitter Spaces recorded audio only lasts for 30 days, so I've exported the audio and shared it on SoundCloud as well.

Simon Willison · SQLite Happy Hour - 22nd March 2022

Collaborative notes from the session

Something I've observed in Twitter Spaces I've joined in the past is that they can really benefit from a dedicated back-channel, to share links and allow audience participation without people needing to first request to speak.

A trick I've used with online talks I've given in the past is to start a collaborative Google Doc to collect shared notes and questions. I tried this for the Twitter Space, and it worked really well!

You see that document here. During the session the document was open for anyone to edit - I've locked it down now that the session has ended.

I've duplicated the final form of the document at the bottom of this post.

Something I really like about this format is that it allows for additional material to be posted later. I spent some time adding more detailed answers to the questions about Datasette after the session had ended.

Thoughts for if I do this again

This was my first time hosting a space, and I learned a lot along the way.

Firstly, this kind of thing works the best when there is a back and forth between the participants.

My original idea was to have each project talk for ten minutes, then spend five minutes on discussion between the panel before moving on to the next project - and 15 minutes of open discussion at the end.

My co-hosts suggested we try to make it more conversational, interrupting each other as we went along. We did that, and it worked much better: these conversations are far more interesting as a conversation than a monolog.

I still don't have a great feel for when to interrupt people in an audio-only conversation, since unlike an in-person panel there are no visual clues to go off!

Techology: it turns out Twitter Spaces has wildly different functionality on web v.s. mobile apps. We spent the first five minutes making sure all of our speakers could talk! We really should have done a tech rehearsal first, but I wasn't sure how to do that without accidentally broadcasting it to the world - maybe setup burner Twitter accounts for testing?

Presenting audio-only is itself a challenge: I'm used to leaning on visual demos when I explain what Datasette is in a talk, and not having those to fall back on was challenging. I had jotted down notes on the main points I wanted to hit which certainly helped, but I think there's a whole new presenting skill here that I need to work harder to develop.

Exporting the recorded audio from Twitter was frustrating but possible. I wrote some notes on how I did that in this TIL.

Our collaborative notes in full

SQLite Happy Hour Twitter Space

22nd March 2022 - 12:30pm PT / 1:30pm MT / 3:30pm ET

Welcome to the SQLite Happy Hour! This hour-long session will feature three projects that are doing interesting things with SQLite. Each project will provide a ten minute overview, followed by five minutes of discussion from the panel. The last 15 minutes of the hour will be an open discussion and general Q&A.

This document is open for anyone to edit. Please feel free to drop notes and questions in as we go along.

The recording of the space is available here: https://twitter.com/i/spaces/1ypKdEXvkMLGW

Riffle

Geoffrey Litt @geoffreylitt, Nicholas Schiefer @nschiefer

Riffle asks: what if you wrote your whole UI as a query over a local database? So far, we've built a prototype using SQLite and React. More background in this paper:

Building data-centric apps with a reactive relational database

Research project goal is to make development simpler, as opposed to the ongoing trend of more complexity.

Riffle looks at having a database-centric mechanism at the heart of the view. Declarative queries could make apps easier to understand and debug.

SQLite is the tool used for the prototype.

Local first architecture: Ink & Switch have been promoting this. Return to a world where you local client device serves as a source of truth - you can access data offline etc - and when the network is available your data gets synced to the cloud.

The prototype: a reactive layer that uses SQLite as a state management backend for React, using https://sql.js.org/ which compiles SQLite in WASM. Also built prototypes of desktop apps using https://github.com/tauri-apps/tauri - like Electron but using the system web browser instead of bundling its own.

Since they control the writes, they can re-execute every query after any writes happen. SQLite is so fast that this works fine, queries all take under a ms and even with a thousand queries you can still run them all.

ALL UI state is in the database - there's no local React component state - literally everything is in the database. This means all UI state is persistent by default.

IndexedDB is used for the in-browser persistence. The Tauri desktop app stores to a file on disk. Maybe SQL.js could do that with the new Chrome filesystem API stuff too?

Questions about Riffle:

Will Riffle target vanilla JS, or Node.js?
- It's running client-side, so vanilla JS
From Stephen: What about browser-native UI state like scroll position, URL path, query string, multiple independent browser tabs, etc?
- Great question. We do some syncing of browser-native state to put it in the DB: eg, to support virtualized list rendering we update scroll state in the DB with an event handler. But there's definitely some browser state that isn't being captured reliably. In the purest world, the pixels on your screen would be produced by a DB query :)
From Predrag Gruevski: Would "query the queries" be a viable approach for narrowing the set of queries that need to be re-executed after a given write? Simple example: if table X gets modified, query for all queries that have table X in a FROM clause, then re-execute them.
- yeah, that's roughly the direction we're headed. It's a little trickier than that if you start having subqueries / materialized view, but good general idea
From Longwei Su: Right now, each db update will cause a whole refresh. Is there any plan to refine the binding? So that any db update will only trigger UI component that "subscribe" to this section of the data. Sqlite have trigger, which can have callback on record update. How to construct that "publisher"-> "subscriber" mapping from sql query?

Comments for Riffle:

From Jesse - http://web.dev/file-system-access/ isn't a very rich api - I think you could persist to it, but I don't think you can seek/update/.../all the posix stuff sqlite probably needs
Hasura documented how they do reactive queries with Postgres, might be useful for minimising refetch overhead?

Datasette

Simon Willison @simonw

Datasette is an open source multi-tool for exploring and publishing data. It explores SQLite as a read-only mechanism for publishing structured data online in as flexible a manner as possible, and aims to build an ecosystem of plugins that can handle a wide range of exploratory data analysis challenges.

Video introduction here: https://simonwillison.net/2021/Feb/7/video/

Questions about Datasette:

How does it compares with https://github.com/dinedal/textql, it seems the same but instead of sqlite binaries, just raw csv files which are more ubiquitous, and easier to view and edit with with office software (msf excel, libreoffice calc) ?
- sqlite-utils memory provides similar functionality: https://simonwillison.net/2021/Jun/19/sqlite-utils-memory/
Does Datasette need to worry about SQLite's Defense Against the Dark Arts security guidelines?
- Yes, absolutely! I've put a lot of work in there. Most importantly, Datasette enforces a time limit on queries, which cuts them off if they take more than a second.
The SQLite3 docs are sometimes light on examples for the tricky stuff (e.g., enabling WAL). What's your best sort of info beyond the official docs?
- I've been publishing my own notes here: https://til.simonwillison.net/sqlite
- The SQLite Forum is amazing - I ask questions on there and often get a reply from the maintainers within a few hours: https://sqlite.org/forum/forummain
From Predrag Gruevski: Regarding learning curve, is a GraphQL web IDE (with syntax highlighting / autocomplete etc.) sufficiently user-friendly for folks more comfortable with a spreadsheet than a CLI tool or SQL?
- Probably not! GraphQL requires thinking like a programmer too. I'm interested in helping people who aren't yet ready to learn any kind of programming language
- I have a plugin for Datasette that adds GraphQL with the GraphiQL user interface - demo here: datasette-graphql-demo.datasette.io
- Thanks! Would love to compare notes on this -- my experience from working with analysts at my employer was that they were able to master GraphiQL very quickly. In a sense, it was more intimidating than actually difficult, so working with them directly to get them over the initial difficulty hump via examples and targeted exercises made a huge positive impact.

Litestream

Ben Johnson @benbjohnson

Litestream adds replication to SQLite, allowing databases to be cheaply replicated to storage systems such as S3. Litestream also now implements live read-replication, where many read replicas can be run against a single leader database.

https://www.sqlite.org/np1queryprob.html - Many Small Queries Are Efficient in SQLite

Questions about Litestream:

What does the planned hot standby feature look like, especially regarding durability guarantees during fail-over?
- BJ: Hot standby is a tough issue to generalize. The database-as-a-service version of Litestream that's coming will handle this but it's not necessarily planned for Litestream)
Will DBaaS be hosted, OSS, or both?
- It'll be both
From Longwei Su: I assume offline update will be commit locally then sync with the online storage. If there is a offline commit that conflict with the online version(that already committed in). How to resolve the conflict?
Not sure if this relates to Litestream but; how big is sql.js --- how much does it cost (in kilobytes) to load sqlite in the browser?
- BJ: I think sql.js is 1.2MB so the cost depends on how much your provider charges for bandwidth
- Thanks! Meant "cost" in the sense of bytes transferred over wire --- this answers it :)

GraphQL

https://github.com/simonw/help-scraper is scraping GraphQL schemas

Tags: sqlite, my-talks, twitter, datasette, litestream, ben-johnson, geoffrey-litt