Family history and AI-friendly software
Here are two subjects that have been on my mind:
- New models are vastly better at retrieving and tracking lots of real-world information, as I've discussed here and here.
- API design will need to change in a generative-AI world (see here and here).
- There's enormous power in "Wiggumizing"1 core processes: make them amenable to improvement by means of instructions that can be grasped by an LLM statelessly or near-statelessly. Context management is still important (that post is almost 7 months old but still at least slightly relevant), and a Wiggumized process automates much of the context-management problem away.
Researching family history is a good example of a domain that ought to be newly amenable to AI assistance: there's a ton of information available, and the more that LLMs can juggle lots of practical information, the better they ought to be at it. So, I've been experimenting with a Wiggumized, API-first, AI-first family history research process. It's been illuminating:
- There's even way more data out there than I suspected. (It turns out that I had ancestors in modern-day Belgium when it was part of France during the Revolution, and I found documents officially dated with the revolutionaary calendar.)
- I'm even more convinced of the power of exposing a robust API and telling AI how to use it: for now, at least, I can use different models and a variety of computer resources much more flexibly as an API consumer than I can make programmatically available through a Web service.2
- Family history is a great example of a domain where human-LLM teamwork producing much better results than either humans or LLMs can get individually. Some of this is that humans can help LLMs avoid and correct silly mistakes, can tell family history to LLMs, can help choose between lines of research, and so on. Some of it is just that humans are allowed to look at Web sites that bots are not allowed to look at, so it's useful to have a system where the LLM can ask the human to help out with data retrieval.
- If you have a lot of practice3 in turning one-off projects into (at least minimally) productionized services, the productionization process is by now very fast. I find that it's often worth it even for the sake of keeping myself honest or showing it to a single other person.
- However much I remind myself to be ambitious about trying things with AI, I don't seem to do it enough. (I'm not surprised that it wasn't hard to add a mapping feature to a site like this, but the fact that it would have been time-consuming five years ago added some mental friction.)
- Simply having a bunch of information I care about available via API is very useful: I can now ask any LLM with my API key arbitrary questions about my family history.
- Vercel is very impressive.
The result: TurboTree is a site where you can set your LLMs on their merry, Wiggum-y way. This is about as polished as you'd expect a three-hour-old Web service to be, and I make no guarantees about how well it works, but I do plan to keep it up and running for my own use. Bug reports are very much appreciated! (You'll probably be correcting AI mistakes, and I'd be grateful if you'd also take a second to help me correct mine.)
I use the term "Wiggumizing" because I view this as the core insight of the "Ralph loop" or "Wiggum loop," but (i) what exactly is defined by "Wiggum loop," (ii) what exactly is important about that process, and (iii) whether it's a good idea at all are all disputed (not to mention changing quickly).↩
This is not a recommendation for making mass-market Web services, for a lot of reasons, primarily that most users are not going to merrily fire up a few terminal windows and tell their LLMs to interact with a certain API. But most things are not mass-market Web services.↩
That is, again, a very old post.↩