"This is the fourth post in a series on Emacs completion. The first argued that Incremental Completing Read (ICR) is a structural property of an interface rather than a convenience feature. The second broke the Emacs substrate into eight packages (collectively VOMPECCC) each solving one of the six orthogonal concerns of a complete completion system. The third walked through spot, a ~1,100-line Spotify client built as a little shim on top of those packages.
This post is the hands-on complement to the spot post. Where the spot case study reviewed a finished codebase from the outside, this one builds a tiny produce picker tool from scratch, one VOMPECCC package at a time. The use case is deliberately trivial: we have a list of produce items (twenty fruits and ten vegetables) with some metadata, and we want to pick one and do something with it."
"This essay's novel contribution to the critical literature is a typographic close-reading of one moment in Orin's morning chapter, where Wallace describes a peculiar feature of a Subject's handwritten note: "every single circle – o's, d's, p's, the #s 6 and 8 – is darkened in" (pg. 43). The argument is that the three darkened letters (O, D, P) spell, in Orin's perception, the name Oedipus. This may seem like a reach, but the encoding becomes the smoking gun in the case against Avril Incandenza when you appreciate Wallace's intellectual debt to Douglas Hofstadter and Gödel, Escher, Bach – a debt the essay documents in detail below."
This is a great write up, I specifically love the graph and the distinction between the outer and inner harness.
I often wonder, typically in feverish coding sessions trying to enhance my 'outer harness', how much of this outer harness will eventually be brought into the inner harness? That is, how much of this outer harness engineering will become obsolete very shortly when Claude et al make similar enhancements to the inner harness?
Can you provide any heuristics here? Are there any members of the outer harness that you think are especially worth engineering? Are there others that you think will soon be obviated by upcoming improvements to these agent providers?
Also, I recommend doing a quick proofread of the figure in the article, there are some typos and some bullets seem unfinished. For example "Specificatints" in the outer harness should likely be "Specifications". The bullets under there have a syntactical mistake as well. In the loop part of the image, under "Improve Feedforward" the parenthetical isn't closed and it's an incomplete sentence. There are likely other typos.
Wow, yes I should have looked more closely at the image - which was obviously generated by Gemini Nano Banana (it usually does a better job with the text rendering). I checked the article text carefully but not the image...
And that's a great question. I'll answer it in two parts. First, I think the inner and outer are actually quite complimentary. The outer part is largely things that Claude can't provide - such as your own instructions, skills, and ways of validating things specific to your project. I have memory as part of the outer harness but Claude of course does have a memory system and it would not surprise me if they drastically improve it.
The other thing, mentioned in the article, is that harnesses (and specifically Claude) are shrinking: "As I was going through these iteration cycles, we also released Opus 4.6, which provided further motivation to reduce harness complexity. There was good reason to expect 4.6 would need less scaffolding than 4.5 did. ". (from https://www.anthropic.com/engineering/harness-design-long-ru...).
So my* core argument is you still need that "scaffolding", but it belongs in the outer harness.
Clear, thank you! I didn't know about Nano Banana for this! Would be cool if they let you edit the image text directly, not sure though, I've never used that tool. Impressive that it generated that!
NB doesn't support direct editing of an image. But you can open the image in something like Krita or Photoshop, highlight the part you want to change with a red marker, and then ask Nano Banana to modify that highlighted section. It usually does a really good job.
In many cases you can just prompt “change this source text into this target text,” and it works in most cases.
Boy oh boy, I enjoyed reading this! This is so important in the current era of LLMs making the production of narrative content so accessible.
The following were especially thought provoking:
"But what happens to writing then when chisels give way to more automatic, efficient, and accessible tools? And if it is true that certain forms of thinking develop alongside writing, then what do these developments do to our thinking at large?"
"And yet, with the informatic revolution, writing no longer retains its linearity, nor is it aimed at a particular audience. Instead, we increasingly write for an apparatus—think attentional metrics such as likes and shares, character limits that encourage brevity, “prompts” that in essence produce writing for us. Our engagement with writing is no longer sequential—rather, we must synthesize information across multivocal networks where everything is available to us simultaneously. To what extent do such changes signal not only the decline of writing itself but also the emergence of a new post-historical and post-political form of consciousness?"
"There is a symbiotic circularity here between these needs and the development of writing technologies: as our ability to communicate evolved, so too has our level of communication increased, which in turn generates demand for more advanced writing technologies."
I don't think I have the same capacity for philosophizing as you, but this makes me think about other technologies geared towards the production and consumption of text and how it may affect our ability to think.
Practically, the least technologically sophisticated form would be some kind of pen and paper situation, and the most mature would be the transformation of a prompt (by an LLM) into some text. Anyone who's used pen+paper and LLMs for this purpose would be familiar with the intimate and uniquely cognitive nature of writing my hand, and similarly with the starkly contrasted detachment of having an LLM generate prose for you.
Your post makes me think about the steps between....
How much cognitive exercise did we lose in the transition from pen+paper to typewriters? Type-writing is still an intimate activity with almost shocking demands on sustained focus by today's standards. It forces you to engage in this way, but frees you from actually constructing the individual morphological forms of each character.
And then, how much of the cognitive exercise required to typewrite was lost when text editors came along, with the ability to yeet any garbage onto the line, knowing you can go back and rearrange it? We lose the required sustained focus from typewriting, but then sure there's still the requirement to edit, rearrange, etc.... still some cognitive exercise there in refactoring a narrative, paraphrasing, etc....
But then, what about when we have things like auto completion or type-ahead to facilitate this? Okay , now we've lost the need to generate our own vocabulary out of the ether, and we get literal completions from something like a dictionary.
And then --- how much is lost when auto COMPLETION becomes auto SUGGESTION. We no longer have to "recall" what we want to write, but merely "recognize" it? Now, any sentence we write pulls from the unfathomable fan-out that is anything related on the internet that a thesaurus or LLM or semantic matcher is aware of.
And then (o god), how much is lost when an LLM does the whole thing for us (something like agentic narration).
This is all a puddle of idea, and I apologize for that. This was just an incredible thought provoking post, and I wonder how you think about the loss of value in writing in each of these layers, and a more material question --- do you recommend a reversion to one of these writing mediums for specific cases? What value do you see, for example, in pen+paper vs typing+text-editor vs LLM generating content.
Separately, do you think there are opportunities for LLMs to unobtrusively enhance the writing process and make it more introspective? Sometimes I'll have an LLM provide an editorial review of my content, but I've seen mixed results and find myself adopting maybe 10% of the review.
Emacs for 25+ years is admirable! Question for you - did you ever use Icicles? I'm going to add that to the history section in the previous post that discussed the history of completion in Emacs and how we got to VOMPECCC.
The author of Embark (the E in VOMPECCC) reached out yesterday mentioning that Icicles would be a good addition, and like me, he and his fellow VOMPECCC package authors hadn't used it before. I think we all started using emacs when helm was already an option. I know Icicles was more popular years ago pre-helm and pre-ivy, and it would be great to hear a little blurb about your experience with it if you ever used it!
=) you're a legend --- I just added the go back button this morning and will deploy tonight. In the short term, if you click the number in the footnote it will take you back. Thats what I'm button-izing.
This bad experience is an artifact of switching from the original experience (with autosyncing Footnotes, plus other goodies, in the sidelines) to this minimal one. If you want the chaos with all the sideline components, you can toggle them in the Reading Controls menu in the top right hand side of the article page.
Thanks for writing! I normally wouldn’t even comment on a small thing like that, but with the length of the articles it was tough to go back and forth. Clicking the number in the footnote works great. I swear I tried that before, but maybe just didn’t hit it quite right
"This is the third post in a series on Emacs completion. The first post argued that Incremental Completing Read (ICR) is not merely a UI convenience but a structural property of an interface, and that Emacs is one of the few environments where completion is exposed as a programmable substrate rather than a sealed UI. The second post broke the substrate into eight packages (collectively VOMPECCC), each solving one of the six orthogonal concerns of a complete completion system.
In this post, I show, concretely, what it looks like when you build with VOMPECCC, by walking through the code of spot, a Spotify client I implemented as a pure ICR application in Emacs."
I totally agree. For me, the biggest take away from researching and writing this post is this: "the state space of a model – not just its happy path of a golden test instance – is the right unit to reason about when you write tests". If I were to try and get buy-in from an enterprise on doing a layered testing strategy, I'd probably lead with this idea as it is the most resonant. I've struggled to get folks on board to strategies like this in the past, and it's likely because I've led with the complex layering approach rather than simply calling out the fact that we aren't reasoning about the right 'unit' when we're testing our models or procs that use those models.
This post is the hands-on complement to the spot post. Where the spot case study reviewed a finished codebase from the outside, this one builds a tiny produce picker tool from scratch, one VOMPECCC package at a time. The use case is deliberately trivial: we have a list of produce items (twenty fruits and ten vegetables) with some metadata, and we want to pick one and do something with it."
reply