July 13-19, 2026
It was a relatively good week work-wise, despite the IQ-diminishing heat sweeping Europe. On Friday I wrote and published a blog post detailing my current agentic coding workflow. It was spectacularly unpopular on Bluesky, squeaked out a few likes on LinkedIn, and garnered no attention on HackerNews. (I think I forgot to enable comments or upvotes when I posted? I can’t find any sort of link to it, now.) It was nonetheless time well spent, as putting to paper these thoughts about how LLMs are changing my personal experience of software engineering helped to clarify my thinking about the subject. If you’re curious about how I use my computer to write code these days (which includes the way I write the prose, although I use LLMs only for editing grammar and spelling in personal writing like this), check it out.
I also updated both this site and that main blog site to use the Rheo justify package, which should produce much better word spacing in all of my personal writing. When I viewed a post on mobile (I have a very small screen on my device), it looked a bit messy; so I reverted mobile to regular left-alignment.
Dissertation[26w29-diss]
I stacked up a small but significant (virtual) pile of papers about Marx and mathematics, and made further progress on the 2021 edited collection Karl Marx and Mathematics. Slowly I am building up a clearer sense of how this literature might all come together in a chapter.
Rheo[26w29-rheo]
For reasons I explained in last week’s notes, I cut another major release, 0.5.0, of Rheo this week. Probably most significant in this release is a change in how spines are specified in rheo.toml. A spine is the main conceptual extension that Rheo gives over Typst proper. It functions as a project management primitive, allowing you to split Typst across multiple files and then have the Rheo CLI automatically collect them together. If you’ve been following the latest features in Typst, you’ll know that this is fairly trivial to set up natively using a combination of the experimental bundle target and module system, which is more or less how Rheo compiles spines under the hood. Spines offer an abstract way to think about which files (‘vertebrae’) should be packaged into each format.
In 0.5.0, spines are inferred from the file system hierarchy of the content directory by default. I realized that this is usually what I want in my Rheo projects, and that this ‘spine inference’ gives Rheo more concrete utility over Typst; as maintaining spines explicitly translates the burden of tracking vertebrae into a different idiom (as was basically necessary in Rheo <0.5.0), rather than actually alleviating it. If you want to use the native Typst CLI to compile multiple Typst source files into a website with a corresponding number of pages, you need to set up a basic bundle/module template to import them appropriately. Using Rheo >=0.5.0, you can just run rheo watch . and get going.
I also added the rheo-context variable, which is the first step to comparably removing the need to explicitly set up a harness for tables of contents / sitemaps in sidebars and index pages. After a discussion with Will Crichton about this, I decided that I need to change the API in another breaking way this week, moving the data structure behind a rheo-context() function boundary. This is breaking for a variable that was only introduced in 0.5.0, though, and so I am considering subverting strict semver and batching the changes into an 0.5.1 release. Otherwise I might give the impression that a major version every week is Rheo’s standard development velocity, which is certainly not the case.
Digital Theory Lab[26w29-dtl]
I sunk my teeth back into this project on Tuesday and Wednesday, and I’m hopeful that we’ll soon have some public updates. The code changes did include one public PR to treetok, a Python library that gives an indication of the research’s general domain, i.e. LLM interpretability at the level of token variation. Here’s a sneak peek of some data visualization from the project:
This is a screenshot of a viewer that I wrote this week with Bonsai, a frontend framework developed at Jane Street that incorporates concepts from Elm, React, and other functional UX libraries and packages them through OCaml. Though I wrote recently about my drift away from web development, it was the topic of my most serious technical thinking as an undergraduate, and visualization is inseparable from programming, despite the fetish of some backend/systems engineering cultures that isolate the two from each other. I do like the idea of having a more powerful type system for frontend work (in Bonsai you write code in OCaml with effectively inlined HTML and CSS, and it compiles to HTML/CSS/Javascript).
Karaji[26w29-karaji]
Last but not least, I started a new project this week in the distributed systems space. I’ve decided to wait and see what comes of working on it for a few weeks before I say too much more, but I’m quite excited about it. My last serious job before grad school was at Halter working out the best way to build a feature store as an application running on Apache Flink, and throughout my PhD I’ve cast around in the streaming execution engine and vector database space for something that would stick. Part of the problem I had in this search, I realize now in retrospect, is that Flink and similar distributed systems are typically built out for the purpose of large-scale, industrial data processing, where data is processed as soon as possible after ingested (in ‘real time’).
Karaji—the name I’m giving to this new system—is something I’ve started building to address a personal use case, not a hypothetical business one. I started writing Rheo for the same reason—to do something with my computers that I hadn’t worked out how to do with existing software in a way that worked for me. It seems obvious to say (and this advice is widely circulated in engineering communities): but personal software is the most inspiring software to write, as there’s no better motivation for making something work well than wanting to use it yourself.