Part of the series: Shorthands
2026-01-02
I recently spent about a year developing my own shorthand: Smith Shorthand. It was a success; the result hung together well and I’ve been a happy user since then.
In November, unbidden, came to me the sudden question: what would Smith look like if I had decided to keep the positional vowel system that I had discarded from its immediate inspiration, Oliver’s Stenoscript?
I didn’t have a particular appetite to overhaul and relearn my shorthand, but the short sketch I made was satisfying, and made me want to think about it more. Moreover, having gone to the core of it and retooled it, the full system now felt unwieldy and overengineered. So I decided I’d like to take this new altered core and evolve it into something much smaller and simpler than Smith.
The successor system is called Stolze-Smith (the name is a slant reference to another member of the Germanic family). As intended, it’s smaller than its predecessor. Even to the extent that it could theoretically fit in an Arthur Whitney-style reference card—though realistically an interested party should read the manual.
A significant change in my working habits since I was working on Smith: I’m an AI user now. In September I started learning to properly program with LLM-backed coding agents, having been in management for the couple of years prior, and not done much coding as a result. But since September I’ve been doing as much programming as I can, and almost always with Claude.
So it didn’t feel very far-fetched to start a new git repo when I wanted to build something new. The first thing I did after I decided that I’d like to make a proper system out of the incunabulum in my notebook was to encode the whole thing in JSON.
Having made structured data out of the rules I had sketched out, I was able to use Claude to iterate on the system. In principle this is not unlike iterating on source code. In fact, just as Claude is relatively knowledgeable about programming techniques and patterns, it knows enough about phonology and English phonotactics to be dangerous. The first design decision I had to make that didn’t follow completely from my starting principles was what to do with the sound /h/: I explained my problem and what considerations were most important to me, and Claude was able to make a suggestion (that I hadn’t thought of) that I liked enough to use.
Part of the advantage here is the same as rubber-ducking. To be effective with a coding agent you have to be structured, explicit and unambiguous in your problem definition, and that itself is a wonderful tool for finding a solution. But this rubber duck will also talk back.
An outcome that feels more significant, though, is:
Designing a shorthand is not a problem of computation, but it is a member of the truly massive set of non-computational problems that are amenable to computational prostheses. The gap between most of these problems and a computational prosthesis is usually: the problem is too recherché, not generalizable enough, of interest to too few people, and not remunerative enough to justify the time and energy necessary to write the software that would help you solve it.
The economics of such problems have been permanently altered.
Stolze-Smith, like its predecessor, possesses a set of briefs: these are the relation between a single sign, written by itself, and a common word. They’re single-sign abbreviations.
When you come up with your set of briefs, you have a series of criteria which you’d like to satisfy, none of which can be satisfied perfectly:
These can’t all be perfectly satisfied. For instance: when we consider assigning words to signs by sound (it’s better to assign “to” to the sign for /t/ than to the sign for /f/), we encounter the difficulty that the sounds for our signs are evenly distributed–there are two possible assignments per sound–but the set of the first sounds of the most common words in written English is not evenly distributed. Some sounds are overrepresented and some are underrepresented.
In fact, what we have here is an NP-hard combinatorial optimization problem. We can use computers to solve it. First we must express all of the above considerations as scoring functions which, given some set of assignments, combine into an overall score. The set of assignments that produces the highest score is the one that best balances all of these different considerations.
Even then, though: there are far too many sets of possible assignments to simply score them all. There is a branch of software that can help you find an optimal set of assignments, operations research (specifically, the subfield of integer optimization), but in the past, setting up an integer programming solver to solve such a problem has both been labor-intensive and required a fair amount of specialist knowledge.
Claude is exquisitely well-suited to fulfilling complex, well-defined API signatures. In the course of designing Stolze-Smith, I instantiated an OR-Tools solver with a comprehensive articulation of every facet of my intuition about what made for a good brief assignment, and furthermore a series of lightweight web apps to visualize and explore a set of assignments.
The problem of rendering a shorthand falls into a very similar category. It’s theoretically possible to encode every rule of how the pen must move in order to realize a particular outline, but it would require extensive knowledge of vector graphics–and even then, who would bother?
In the case of Stolze-Smith, there is a single application that is both obvious and extremely narrow in scope. To properly document the system for human consumption, you have to provide written samples. Nothing else will do. In the case of Smith, the greatest manual effort was writing out the system illustrations and scanning them in.
In order to produce the manual for Stolze-Smith, I built an entire text-to-signs pipeline which, given English words, will render an SVG of the appropriate Smith-Stolze outline. For bonus points, I created a reStructuredText directive which will insert the rendered SVG into the HTML generated for the rest of the document.
The result is that the entire manual is programmatically generated; I can iterate on it by editing the RST, regenerating the HTML, and pushing it to Netlify.
I want neither to over- nor underapply the insights gleaned from this project to the work of computer programming in industry. I think there is much here that is meaningful when working with coding agents on any project; there is also much that’s only applicable to solo projects where the code is not the point. In the case of Stolze-Smith, there are about 40,000 lines of code—far too much for any sane person to write by themselves!–but they don’t need to keep operating after the system has been designed and generated.
Let that be the point! In the sphere of my interests, there are many, many questions and curiosities that could be satisfied with 40,000 lines of code and not with much fewer. There will be more strange things created that would never otherwise have breathed.