The Emacsification of Software

Emacs has this property because it uses Lisp. The general tendency for programmers to start writing everything themselves was noted, for Lisp, but was named “The Lisp Curse”¹. It is a curse because programmers stop collaborating. Everyone becomes their own wizard in their own tower, and overall progress stops, and a dark age sets in.

1. <https://www.winestockwebdesign.com/Essays/Lisp_Curse.html#ma...>

Software that today is overwhelmingly prepackaged and usually professional, which I think at this point the nerds should reclaim:

* Podcast apps

* Music listening apps

* Feed readers

* Bluesky clients

* Note-taking apps

* Desktop bookmarking/read-later apps

* Chat and instant messaging

* Time trackers

* Recipe managers

These are all things that you can get better-than-replacement-grade results from Claude on --- not necessarily the best, not necessarily the most globally competitive, but certainly an application more closely tailored to exactly what you want it to do for your own idiosyncratic work style.

Music.app is a miserable experience, and I can just tell as I use it that it's miserable trying to serve me. But Apple long ago factored all the meaningful bits out of Music.app into MusicKit. Why am I still using Music.app? MusicKit is the real product now. This is new.

This is so exactly right and I've been saying it to whoever will put up with me...(and now am embarrassed I have no link to show for it. oh well, shame is good for writing. envy too!)

Software production is now so easy that everything is a .emacs file (pronounced "dot emacs" btw): meaning, each individual has their own entirely personal, endlessly customizable software cocoon. As tptacek says in the OP, it's "easier to build your own solution than to install an existing one" - or to learn an existing one.

Another good analogy, not by concidence, is to Lisp in general. The classic knock against it—one I never agreed with but used to hear all the time—is that Lisp with its macros is so malleable that every programmer ends up turning it into their own private language which no one else can read.

Tangential to that was Mark Tarver's 2007 piece "The Bipolar Lisp Programmer" which had much discussion over the years (https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%2...). He wrote about the "brilliant bipolar mind" (BBM) - I won't get into how he introduces that or whether fairly or not, but it's interesting given how "AI psychosis", in both ironic and unironic variants, is frequently mentioned these days.

From Tarver's article (https://www.marktarver.com/bipolar.html):

The phrase 'throw-away design' is absolutely made for the BBM and it comes from the Lisp community. Lisp allows you to just chuck things off so easily, and it is easy to take this for granted. I saw this 10 years ago when looking for a GUI to my Lisp [...] No problem, there were 9 different offerings. The trouble was that none of the 9 were properly documented and none were bug free. Basically each person had implemented his own solution and it worked for him so that was fine. This is a BBM attitude; it works for me and I understand it. It is also the product of not needing or wanting anybody else's help to do something.

Sounds pretty 2026, no? He goes on:

The C/C++ approach is quite different. It's so damn hard to do anything with tweezers and glue that anything significant you do will be a real achievement. You want to document it. Also you're liable to need help in any C project of significant size; so you're liable to be social and work with others. You need to, just to get somewhere. And all that, from the point of view of an employer, is attractive. Ten people who communicate, document things properly and work together are preferable to one BBM hacking Lisp who can only be replaced by another BBM (if you can find one).

---

When production is so easy, consumption becomes the bottleneck [1], and suddenly sharing is a problem. This is why the Emacs analogy is so good. A .emacs file is as personal as a fingerprint. You might copy snippets into yours, but why would you ever use another person's? (other than to get started as a noob). You just make your own.

The more customized these cocoons get, the harder they are for anybody else to understand—or to want to. It isn't just that another's cocoon has too high a cognitive cost to bother learning when you can just generate you own. It's also uncomfortable, like wearing someone else's clothes. The sense of smell somehow gets involved.

I would call this, maybe not AI psychosis, but AI solipsism.

In software it's fascinating how configuration management (that boringest of all phrases) is becoming the hard part. How do you share and version the source? What even is the source? Is it the prompts? That's where the OP heads at the end: "share it somewhere — or, better yet, just a screenshot and the prompts you used to make it." But when I floated a couple trial balloons about whether we might use this for Show HN—i.e., don't just share the code you generated, because that's not the source anymore; instead share the prompts—we got a lot of pushback from knowledgeable people (summarized here: https://news.ycombinator.com/item?id=47213630).

These dynamics can only be what's behind the pipe-bursting pressure that Github has been under. What a Github successor would look like is unclear, but as a clever friend points out, there will have to be one. Projects and startups along these lines are appearing, but we seem to be in the horseless carriage phase still.

Even more importantly, what happens to teamwork? If we are all a BBM now—or rather, if we all have personal armies of BBMs, locked in a manic state, primed at all hours to generate things for us-and-only-us—how do we work together? How do cocoons communicate, interoperate? What does a team of ai solipsists look like? It sounds oxymoronic.

My sense is that a lot of software teams, startups and so on, on the cutting edge of AI-driven / agentic development, are currently contending with this, not (only) philosophically but practically, e.g. how does my generated code compose with your generated code. With these frictions we presumably end up giving back some portion (how much? who can say?) of the productivity gains of generated code. One would expect such effects to show up over time, as the systems being built this way grow in complexity and maintenance/development tradeoffs become things.

I don't see many talking about it publicly yet though, which is a pity. No one wants to be the first to stop clapping and sit down during an obligatory standing ovation, but it's a bummer if you can't (yet) tell interesting stories about downsides and instead have to pretend that this is the first free lunch, the only downsideless upside that ever existed. It makes the discussion more boring and probably slows evolution since the experiments, ironically, are happening in silos.

These are the people doing the most serious and real and advanced work with the new tools (edit: I mean in the field of software dev), so it sucks if all talk of downsides is left to the cynical/curmudgeonly contingent, who for whatever good points they may, er, generate along the way, are obviously wrong about AI having no value for software dev. It's easier to talk about AI wiping out the human race than, say, bug counts going up or productivity levelling off after a while.

Mostly I just want to know what's really going on! and how people are dealing with it and how it is developing over time. Do I have to like go to meetups or something?

[1] That's why a recent paper used the title "Easier to Write, Harder to Read" - https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702

I've absolutely engaged in making personal software [0] thanks to the age of LLMs.

But to be honest, my time using Emacs didn't teach me to "build personal software". My Emacs set up was extremely brittle, and it was a nightmare when I tried to use it across Windows & macOS. My university project was written using an unholy combination of org-mode & some workflow to create a beautiful LaTeX file, and I couldn't tell you how to recompile it (if I were to try, I'd probably get an LLM to literally translate it to LaTeX).

I want my life to have as little maintenance as possible, and making my own software for everything isn't always compatible with that.

[0]: A rewrite of a NETFX application in Rust, simply because the 20 minute installation time irked me: https://github.com/bevan-philip/wlan-optimizer

Your Emacs (or my VIM) config was simple text file, that you can open in a simple text editor, and customize it as needed, and you know where is what. My VIM config is 20 year old. A year or 2 ago, I just dumped the manual package management, and started using a plugin manager.

There are no gatekeepers, no dependencies!

This, require you to have pay $20-$200 to a 3rd party corporation, or have a kind of beefy GPU (to run locally), run some instructions on text file, keep editing till it might does what you intend it to.

You are knowingly adding a dependency, which probably will become a hard dependency when everything goes jumbled up for human reviews, either on a beefy GPU or sending your data to a shareholder pleasing corporation.

Let's distinguish, how these are not the same, and the real price we pay

"Personal Software" i.e. programs that one writes for oneself, was the original vision of home computing back in the 1960s. The PC wasn't really anticipated, but the thought was that everyone would have a computer terminal at home, and write programs to do whatever was needed. It was imagined that programming would become easy enough that anyone could learn to do it. We're not there yet but with LLMs we're getting closer.

I wonder what will be the effect of this on open source software. I do not mean the technical aspects, easy of coding, documenting, explosion of PRs, .. Social aspects scare me a bit more. If everyone is building their own version, will people stick around to contribute to the same project for years. I guess the dedicated ones will do so maybe it is a good thing, a filtering out of the disinterested.

I feel as though the author really missed an opportunity here: "The Emacsulation of Software"

This article hints at what I feel is one of the not-yet-realized transformations that LLM coding brings: can we finally drop Electron/React Native and just have LLMs automate the work of transforming Figma/wireframes and behavior specs into truly native apps for each platform?

For CRUD apps, the API spec and UI mockups -- or even a photo of how it looks on the already coded platform -- would go a long way. That's exactly the kind of well defined task work LLMs do well with. It should be possible to automate a lot of the equivalence testing too.

Is there still an excuse for "maybe we'll add Android someday" or "not enough Mac/Linux users"? And is there still a justification for not building those less-used flows like password reset into the iOS app instead of throwing up random WebViews?

For those apps that do have non-trivial logic on device, LLMs have shown a lot of promise at rewriting to cross-compiling-is-easy languages like Go or Rust.

I know the article is mostly about making stand-alone software, but this type of thing is why one of the things I value most when looking workflow tools I will be using heavily is extensibility. I can try put someone's neovim plugin for a second, figure out if it's something I actually need, and if so make my own personal version that matches my mental model perfectly, adds all the dumb little bells I want, and removes all the useful features I don't personally care about. Plus I no longer need to worry nearly as much about supply chain issues.

Over the years I've replaced 90% of the plugins I used when I started. Plus I get a nice outlet from any pesky NIH symptoms.

> For the kinds of software I’m talking about, you want the prompts more than you want the source code.

Please do not do this.

Per OurWorldInData, >50% of the world lives below $10/day in 2026.

A $200/mth AI subscription costs ~66% of that.

Generation costs still exceed distribution costs by a wide margin.

Uploading costs you nothing, and it can help the poor.

I've done some similar stuff.

I wanted to reference some TLA+ community stuff. I was initially just copy-pasting the specs into mine, and that worked well enough, but it was a little tedious and I was kind of afraid I might accidentally forget to give attribution to someone if I used their spec.

So I got Claude to build a TLA+ package manager for me. It's just a basic thing in Rust that allows me to plop a deps.json file into my TLA+ folder, and put a git repo url and commit hash, and then I use tree-sitter-tlaplus [1] to rename the modules to have a basic namespace to avoid collisions. It took about 30 minutes of fighting with Claude, but then it worked fine.

As AI gets better and better and cheaper and cheaper, I suspect it will be easy to have tons of custom apps for everything. It's a brave new world.

[1] https://github.com/tlaplus-community/tree-sitter-tlaplus

Enjoyable article. I've had the same feeling about native software becoming more accessible with the help of llms. However, I tried the app and opened a large-ish markdown file and immediately had scroll hangs and then the app crashed. Making a small proof of concept is easy, but performance and reliability are still hard.

edit: typo

I was looking for a good markdown / file editor on Android available the Play Store on a device where I can't install F-Droid / arbitrary apks, as I had been using https://github.com/gsantner/markor which is not available there. My conclusion was that there's basically none, to the point that it looks like the best solution would be for me to publish a version of it there, just so that I have access to it.

I remember how just 5 years ago the majority of speakers were saying how absolutely everyone should learn computer programming. Already many years ago VBA was built to bridge the gap between engineers and other professions. Well, the gap is completely closed now, everyone can do what has been talked about for decades: programming computers. And I suspect even markdown will become obsolete very soon, eliminating this very last remnant of what programming used to be.

"the terminal itself, which is almost always monospaced and thus fatiguing to read"

It is? Why? I read monospaced text all day long. I don't find it fatiguing in the least. In fact, I think I might prefer it to non-monospaced text.

This anecdote may be the key to the productivity mystery of LLMs: the output is appearing in the form of software that wasn't ever economical to make before so kind of by definition won't appear in productivity metrics. Though at least in my professional life since we have a configuration control protocol I probably will continue not seeing any impact from AI (for better or worse).

Ehmm, weird, I can't be the only one in the room. You guys didn't know about gfm and gfm-view Emacs modes?

Ok, not the article I thought it was going to be. In fact it's the complete opposite of what Emacs means to me. For me, the point of Emacs is that I use one program to do everything. Why would I want a special bit of software just to view Markdown? I can view it in Emacs, and then it works with everything else I do. Developing lots of custom applications, AI assisted or not, is not replacing how I use Emacs.

Had somewhat related thoughts on this here: https://news.ycombinator.com/item?id=48035796 (Most vibe-coded tools are not for you)

Markdown syntax highlighting is nice, but at this point I’d be very happy if software could just consistently open .md files as plain text.

I have my Obsidian vault synced to Google Drive, and it’s completely impossible to just look at the files in it via the web interface. iOS support is also more than lacking.

i've made maybe 20 personal LLM tools this year. 3 survived past the first week. not because the rest weren't useful, just wasn't willing to debug them when something broke.

Interesting article.

When my Emacs opens a markdown file it immediately converts it into OrgMode format. I find that more readable, more navigable and more editable.

Now I'll have to go and meditate about Emacsification.

Lots of interesting takes that I think I disagree with here, although I mostly write Markdown rather than read it:

> they’re hamstrung by the terminal itself, which is almost always monospaced and thus fatiguing to read.

I recently re-built Blue, a minimalist text editor inspired by the Turbo Pascal and Turbo Basic editors of the late 1990's. It uses a fixed width font, because I prefer it.

https://github.com/codazoda/blue

It is rather funny that the article talks about markdown when everyone who uses Emacs uses org mode instead.

My .emacs file is init.el which is actually init.org, which isn't an Emacs file but a literate program that's half a guix installation script and half a regular .emacs file.

Also kill all markdown. Replace it with xml or better yet SXML.

Wow, this really changes how I think about working with software and with LLMs. Sharing ideas and amateur remixing and setting up something weird for you and your friends is so much easier now. Things you had to have lots of time and expertise to do before are just widely accessible now.

I can’t be the only one for whom `vim README.md` is perfectly good. I’ve never considered the monospaced font a limitation, I prefer it. Coloured rendering works great and is all the visual aid I need to parse quickly.

I can see a table of contents being useful though. Perhaps if `:Toc` doesn’t exist yet, it should.

> What matters are the ideas, the observation that “yeah, you can do that, and it’ll work well”. > > For the kinds of software I’m talking about, you want the prompts more than you want the source code.

Right.

In a broad sense, programming is about managing complexity/information. Constructing interfaces/abstractions in order to choose which details are useful for an interface (& which can be ignored).

The 'magical' parts of LLMs is being able to get useful output from unstructured/messy inputs.

It's kindof surprising that this has an impact on programming: it changes a lot ("write me an app that does this" becomes feasible for 'small' things), but in some sense, the fundamental problems remain.

Unfortunately ~all software stacks in use now lack stability. They are all optimized for commercial software shops where weekly update of dependencies is just the routine.

I agree, experience this, love it, etc.

The "0% product hunt, 100% show and tell" bit is one of the benefits of an ecosystem with painfully high upfront entry costs.

Does anyone know of an active forum of any kind (discord, reddit, phpbb, mailing list, whatever) for people who are building personal applications like this for love of the game, which takes hardline stances about desirable vs undesirable motives and behaviors, and enforces high entry/participation costs in exchange for unusually low quantities of transient grifters and self-interested status seeking by day-old accounts?

Speaking of which, Emacs’es markdown-mode is pretty good. :^)

The barrier to entry for writing personalized software is lower, but you still need expertise for instruction and maintenance.

I don’t think we’re at the point where any random stranger on the street can get Claude to make a perfect Electron app for their use case.

Any good md viewer and open to customize some formatting to pdf?

> You want a good Markdown viewer more than you think you do.

> monospaced and thus fatiguing to read.

Monospaced text is fine. I don't see how people who read code (and code comments) all day care that strongly about this. Plaintext is king

Prescriptions include lisinopril 20 mg, amlodipine 2.5 mg, metformin 500 mg, and aspirin 81 mg.

Emacs was the first vibe-coding.

I know this is a bit beside the point of the article, but I also got sick of reading markdown on a terminal...

So I asked my agent to write typst, ran "typst watch", and now I can look at a nice pdf file. it even auto-refreshes when the clanker changes it.

I came here to recommend Marked: https://marked2app.com

But...I like MDV.

I just use Silverbulletmd...

Terrible analogy. Emacs has always had comparably fewer major options for packages compared to other tools, there is often an obvious option based on your needs, and it has never been my experience that people decide to just roll their own versions of everything. The author has clearly never used neovim or now pi. NPM packages in general would have also been a way better example.

Edit: Sure there is some small overlap here, but it's really not comparable and definitely not like the way the author describes things. User personalization in Emacs has normally been on a much smaller scale than rewriting entire packages. Configuration is generally smaller tweaks or things on top of existing packages because Emacs provides cohesive extensibility to the point that it often doesn't require "rolling your own." Most packages are already extremely configurable and tailorable. You don't magically get that sort of environment with LLMs. Emacs is much more cooperative/generalized.

The scale and type of custom/personalized software we're seeing now with AI is completely different from how things have been in Emacs. I'm not saying that's a good or bad thing (I think it's both), but it's very different from Emacs and definitely more comparable to something like vim/neovim where (in part just because of the sheer popularity) you constantly have people "rolling their own" packages and a billion versions of everything. Even that is not a great analogy. This is something completely new.

> Suddenly, I realized: a good Markdown viewer was a dumb thing to waste time looking for. It’s 2026. I can just have one extruded for me.

If this is the starting thought, I don't know how you wrap back around to publishing and advertising the generated code.

Either you create the best possible mac markdown viewer and should share it as that, orthogonal to any statement of AI use. Or you're just adding to the noise of tools available online. Where other people should ignore your work, and go slopcode their own markdown viewer.

I love this and I have a handful of tools like this that I built for myself (I had claude write me a TUI crossplane kcl function renderer, for example -- something whose total addressable audience in the world is probably 20 people).

"Content creation for an audience of one" is really the revolutionary change that is happening right now because of AI. Disposable apps, disposable books, disposable movies, disposable music. Things that are made for a single person, used once or a handful of times and then thrown away. The entire economic model of content creation and distribution is going to explode in the next 3 or 4 years, and very few people are prepared for it.

Very cool read, kudos

[flagged]

[flagged]

[flagged]

[dead]

[dead]

No, I don't. I don't want anything that has to do with John Gruber, ever.