Purview is a weekly review of blog posts I find on the web and how they relate to my work. It is also a way to shout out interesting work, even when it sits outside my comfort zone.
This week’s thread is understanding: what it takes to keep software small enough to grasp, and what happens to that grasp when code costs almost nothing.
Paul Masurel, who wrote Tantivy as a Rust take on Lucene, was interviewed by ParadeDB in April 2026, a company that runs Tantivy inside PostgreSQL.
Tantivy is a library, not a service, and I think that is the future of search: not huge deployments, but situated databases that people first build and then query the way they want.
Link: https://www.paradedb.com/blog/tantivy-interview
Four moves in a few months, one cause: coding agents push far more code than version control built for humans can absorb.
OpenAI kept Git and rebuilt the server. Pando is a Git-compatible backend written in Rust, designed by one engineer and built with Codex in ten weeks. It has served the monorepo since April, cut median push latency by nearly 80%, and engineers and agents still use the plain Git client.
Anthropic left Git. Merges to its monorepo went from about 2,500 a day in May to more than 30,000 in September. A team of seven built Scion, a centralized system that assumes agents are always online, and migrated in five months. It is not open source, and Anthropic says it is no replacement for Git in general use.
GitHub, the host for everyone else, also kept Git and rebuilt underneath. Its new storage layer, announced on November 5, keeps Git packs in Azure Blob Storage, references in a dedicated replicated log, and serves traffic from disposable replicas that hold only cached state. In internal tests it took 5,000 concurrent agents and 7,200 pushes per second on one repository. It is in private preview, with a wider rollout planned for early 2027.
Martin von Zweigbergk, who created Jujutsu (jj), joined East River Source Control as CTO in September, after 15 years at Google. In his view jj fixes the side of version control that runs on your laptop, but the server still speaks Git, and the storage layer is what must change next. jj stays open source under Apache 2.0, with Martin as a core maintainer.
Why it matters to me:
Links:
Curiositry turns the honeypot around: instead of luring attackers, a curiosity trap is a small hook that rewards close attention and draws in like-minded people. Examples range from the turtle in the Wait But Why footer, which leads down a chain of nested pages, to footnotes, inside jokes, and job offers hidden in a browser console.
The remedy is mostly patience: publish often, write from concrete experience, make it easy to reply, and layer the text so the main point stays fast for hurried readers while the details reward the attentive ones.
All the footer is a trap. The only missing piece is a blogroll, and I am working on it. It feels premature to link to the blogs of people I have not had a conversation with beforehand.
Link: https://www.autodidacts.io/curiosity-traps/
Pavel Uvarov wrote Schevana, a functional desktop in Chez Scheme. He calls it a toy, a happy place for Lisp enthusiasts: the desktop is just a function of the environment, drawn by the CPU in a single thread.
dharmatech picked it up and built upon it, with a pull request that adds a flock of boids and a window to edit its rules. He also made a video where he explains that AI offers the opportunity to visit or revisit topics, new and old, more quickly and in a way that is more fun.
One person shares the work of the other and builds upon it. That opens the question of what AI is for, and whether there is still room for experimenting and improving upon the state of the art.
Why it matters to me:
Links:
Veit Heller is writing a series that explains Futamura projections, with a first and a second projection so far.
Futamura projections bridge the gap between interpreters and compilers. Given an interpreter and a specializer, they promise fast, ad-hoc compilation strategies at a lower cost than writing a compiler by hand.
Why it matters to me:
Links:
All seven texts agree that understanding has become the scarce thing. A program is a theory held by people, not its text, cognitive debt lives in heads, and generation now outpaces understanding. The loss hides itself: satisfaction rises while skill falls, and AI users overrate their skills. What decides is the relationship to the tool, not the tool.
They split on where understanding can live, and on what to do. Storey and VirtusLab keep it in people’s heads and answer by slowing down. Kerr notes that agents cannot know by making but excel at knowing by testing, so she builds verification and a context for agents. My essay AI without IA puts part of it in the environment. On the stakes, Hicks shows that it is a matter of identity, and Jeffries abstains where Kerr uses AI despite its harm.
Kerr’s list of vexations leaves out two techniques. Mutation testing tests the tests themselves, which matters most when an agent writes both the code and its tests. Deterministic simulation testing runs a system under a controlled clock and scheduler, so that any failure can be replayed exactly. I told the story of a small mutation testing tool in Reading mutation.py: a story.
Where Naur speaks of theory, I like to speak of the spirit of the code, as opposed to its letter: something you have to make your own when you approach a new codebase. It is a more elegant way to say: when in Rome, do as the Romans do. Going through an AI tool, we lose that spirit, or never acquire it.
Links:
Tim Zöller, writing from Java, takes up the Lisp curse: Lisp makes custom solutions so easy that everyone builds their own, and no shared library forms. He fears LLMs bring it to ecosystems like Java’s. If generating code looks cheaper than adopting a library, fewer people use libraries, maintainers get less feedback, fewer reusable modules get shared, and software development becomes a lonelier task.
I think the diagnosis is right and the name is wrong. In Rudolf Winestock’s essay, the curse is social: extending Lisp is so easy that lone hackers each build their own 80% solution, and the community never converges. But the lone hacker at least understood the code. What Zöller describes is code that nobody wrote and nobody read. That is not Lisp’s curse, that is artificial intelligence without intelligence augmentation, the thread of this issue.
The ordered key-value store taught me the same lesson from the data side. OKVS is the factorization of what you need to store data: ordered keys, bytes, ranges, transactions. It is so powerful that two people never need to agree on code; each rebuilds secondary indexes or pagination in an evening. They do need to agree on the key encoding, because bytes do not explain themselves and data outlives the code that wrote it. FoundationDB’s tuple layer is first of all an encoding, written down as a spec, which is why bindings in many languages agree on the bytes without sharing code. SRFI-167 and 168 were my attempt at the same level.
So the curse is not having too much power. It is failing to separate what must be shared, the spec, from what one can afford to rewrite, the code. LLMs threaten that separation from the other side, by making code so cheap that nobody bothers to write the spec.
Links:
Today I learned a word from Jessica Kerr, who signs her site “symmathecist, in the medium of code”. A symmathesy, a word coined by Nora Bateson, is a learning system made of learning parts. A symmathecist is an active participant in one, who works to increase learning within the system and between the system and its environment.
For Kerr, a software team is a symmathesy: people, running software, and tools all learn from each other. People learn from errors and stored data, the software changes as people change it, and none of the parts stays fixed.
Links: