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.
The common denominator: the data needs to be owned by you, or at least made accessible. Companies love to create walled gardens where they own the content and control how you access it, making this kind of personalized interface impossible. Hopefully we can push back more now.
I mean, hold up, if that thought lights you up I'm happy, but I don't actually think that's the common denominator. I used Things.app to track projects for a long time and ultimately fell out of love with it. Things.app didn't own my data; it's a pure UI app.
But now it occurs to me: I know precisely how I work, I know what patterns are valuable to me, I know when and how I need to remind myself of things. I don't know why I haven't already started building my Things.app replacement. But I'd guess I have it to a place where I'm happy by this time Saturday.
Honestly, it's harder for me to think of daily-driver apps where this wouldn't be the case. I guess vector graphics editing? I'm not going to vibe up a vector editor. But I'll bet all the money in my pocket that 5 years from now, the real value in vector graphics tools will be their API/SDK, not the packaged application experience.
I'm not following your reasoning about the common denominator, not sure we're on the same wavelength about what I meant. I'm claiming that in order for an application to be "reclaimable", you have to be able to access and manipulate the data under the app. Some applications currently work that way now, lots of them don't.
For example, we can "reclaim" non-DRM ebook readers, audiobooks, and music players that play local files or use an open API. But a company-specific walled garden streaming DRM'd ecosystem will be almost impossible to build around.
You're talking about entire systems. That's something to be optimistic about too. But it's actually not the thing the comment you responded to was about. I'm not saying I'm excited to get out of the Apple Music ecosystem (I like Apple Music, the service, quite a lot). I'm excited to get out of Music.app, and into my own custom Apple Music player; one where playlists and play history are simple, sanely-schemaed sqlite databases.
I gotta be careful, I'm going to talk myself into staying up late tonight building that.
Ownership can have different forms. Slack.app that doesn't let me easily extract code snippets from a thread - owns me. Jira that forces me to use their imbecilic, quirky wysiwyg owns me. Note taking app that keeps the data in their db and not my files - ain't my friend. The friction is the ownership. When extraction requires effort, the tool has leverage over you. It's a subtler form than data lock-in - behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay in Slack/Jira/Dropbox/Evernote/Notion/etc. longer, search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates.
Plain text, local files, standard formats - they don't fight you on extraction because there's nothing to protect. That's why investing in FOSS tools is almost always paying for your own liberation rather than your own imprisonment. Even when there isn't feature parity, even when the FOSS tool doesn't have a "polished UI" and it's "maintained by a teenager in Nebraska" - still a better choice.
Something like old school Facebook in UI, but functions more like MSN Messenger. You connect to your contacts via P2P, and download/upload updates to your social media network.
What would be amazing now would be a way to deploy my own Claude-built utility applications to my phone without having to go through the effort of securing a Mac developer account and going through that whole rigamarole.
An unfinished spreadsheet-based interface for entering time. Meant for consulting, but never got around to persisting the data. Mostly created it because I couldn't stand all the ways that time trackers force users to enter structured time when there's a cute algorithm to handle just about every way a human might naturally enter time.
In the days of LLMs, it would be far easier to categorize ingredients and format them into TeX for publishing as a PDF file. The idea behind this project was to let people essentially copy/paste recipes off the web or scans of handwritten content and autoformat it.
I just made a one-shot Android music player because I need a very simple one to listen to tracks to practice drums, and I need to go back from the beginning a lot of time, reduce speed, open them from Whatsapp when my teacher sends them to me and access easily the last 4-5 played.
There was nothing in F-Droid that ticked all the box so I just made my APK.
> but certainly an application more closely tailored to exactly what you want it to do for your own idiosyncratic work style.
Yep, I'm doing this all the time. I've been doing it for a year. The silliest on is an IG post previewer. My app is better suited to me than the preview function that Instagram provide itself.
Music apps especially went downhill, spotify and tidal etc need to offer apis so we can integrate several sources in one app. They used to offer much more. I was able to import my library into spotify once (thoigh it could only hold 10k item back then). I want all my music in one place, not 4 apps
I have Gonic (a subsonic server) on my home server and my client is a perl script. It basically allows me to search for an album, present a prompt for me to select the best match, and then builds up a playlist for the tracks to pass to MPV. That’s pretty much all I ever need. I would gladly dump the whole spotify client if they had an API to do the same (even if the queue is a long stream of data instead of tracks).
Many of them have been reclaimed. Check out the "awesome self hosting" GitHub repo.
Podcasts: audiobookshelf
Music: 500 different subsonic clients, many of which are good. Or some fun tuis
Feed readers: lol, more than there are grains of sand in Torvalds' flippers
Note taking: again innumerable, also, just use nvim or emacs of course
Chat: tons of very good self hosted options that can save orgs thousands a month.
Rather than build your own from scratch, rediscovering already solved issues, why not contribute to or fork a FOSS project? LLMs make it easy easier to get up to speed on large projects
Audiobookshelf is a web app! Like, if you had a good TUI music player, I don't think you'd be rebutting my thesis here. I don't doubt anybody's ability to build TUIs.
The point of the post is the emacsification of the native macOS (and Windows, I assume) environment. Totally reasonable not to care that it's occurring, that's not really responsive to the post, is it?
I was responding to your comment that nerds should reclaim software that's overwhelmingly professional and pre packaged by sharing that there already is FOSS software for the categories you listed, which imo represents nerd reclamation.
Audiobookshelf has a native android app, not sure about desktop, I only use it on Android.
Anyone can build a TUI sure but why try to rebuild the whole mpd client/server stack that lets anyone on your network play music from the several TB collection of FLACs on your NAS? Same for subsonic, why reinvent the client server protocol there when it's already solved? And for subsonic clients, why reimplement streaming, offline downloads with de-duping, stream bitrate, album / artist handling... If there's something a subsonic client doesn't have that you want, fork it, point claude at it, done! That probably falls within the emacsification thing, right?
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.
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?
There's something about this whole situation that rhymes with the issue of LLM-generated prose. It's not that GPT 5.5 writes bad prose (I mean, it doesn't write good prose, but it's not awful). It's that once I pick up on the text being GPT 5.5's, my brain switches into a mode where it starts reminding me "this is just GPT output, you could just ask GPT 5.5 these questions yourself, and get answers better tailored to what you want to know". Why am I reading this one particular artifact of a conversation with the LLM? Once I know what the conversation is about, I can just have a better one myself.
Same deal with a lot of this software. I guess there's some "taste" to it, but mostly what you care about are the ideas and the "recipe".
Also, you should just do a monthly "Vibe HN" thread.
Those are great points and it leads right back to the solipsism thing. Also, you snuck a "It's not that X, it's that Y." in there. Nice.
> you should just do a monthly "Vibe HN" thread
It wouldn't stop people from feeding them into the Show HN stream, which is the problem. If we had a good enough way to tell them apart, we could factor them into two streams, but we don't yet.
> It wouldn't stop people from feeding them into the Show HN stream, which is the problem. If we had a good enough way to tell them apart, we could factor them into two streams, but we don't yet.
But it would allow for a culture to grow where the posters would self-contain their submissions into those threads.
I don't want to make this about people's faith or whatever, but to put it frankly, I've heard a lot of contemporary Christian music, I don't care for it, and [I like to think] I can reliably recognize it in three notes or fewer,¹ which may or may not bear out in rigorous testing, but saves me a lot of time either way. This feels like it parallels strongly with the topic at hand
> 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.
I can install WhatsApp in a few tens of seconds. You most definitely spent more time than that writing this comment.
Would you mind sharing a video of you building a custom WhatsApp in less time? Not even starting to think about getting other people to talk to you on your instantly-built messaging solution...
It has been 3 hours already since your comment and I have just installed a WhatsApp update and it took around 10 seconds.
We're still waiting for tptacek's DIY WhatsApp alternative since he believes that it's "easier to build your own solution than to install an existing one".
That must be one of the most silliest comments I have ever read, and the worst part is even the moderators agree with the statement.
To be fair, I think it is true that AI will help nerds (like me) implement their own clients. Without AI, I will think that "I could make my own client", I will spend some evenings and weekends proving that I can solve the problem, and then I will never spend the time I would need to actually make it usable.
And I would love it if more services had an Open API and allowed people to write their own clients. I like the concept of "emacsification of software".
But I find it a little extreme to say "it's faster to build your own than to install an existing alternative". You still have to spend a lot of time building your own, it's just that now it's realistic without taking a sabbatical.
I think the "nerds (like me)" part of your observation is something that a lot of AI-enthusiast nerds seriously underestimate. For as long as there's been personal computing, there's been a narrative that everyone would be a programmer if we just made it easier for everyone to program, and we've seen attempt after attempt after attempt to introduce new technologies that will surely, surely, be the key to unlocking this. What we don't seem to consider is the vast circumstantial evidence that the vast majority of users are simply not interested in creating tools, automations, widgets, etc., and never will be.
For my part, I am not only a nerd, I am literally an Emacs-using nerd, and I am not interested in using LLMs to create a plethora of bespoke applications that are subtle tweaks on existing tools. I haven't ruled out using AI to assist in helping me with a program that I've been wanting to write for years, but a lot of what's blocking me on that is figuring out design aspects that an LLM wouldn't be able to help me with in the first place. (I'm also concerned about "vibe-coding" programs that I don't 100% understand, at least if they're programs that I might ever want to release into the world.)
> But I find it a little extreme to say "it's faster to build your own than to install an existing alternative".
Installing an existing alternative might be easy ... once you found the one which best (i.e. mostly) matches your requirements. The time consuming task IMO is the time needed to find and then choose between half a dozen (or so) alternatives which all might do the job ... until you installed them, tested them, and found that they are insufficient for the job you expect them to do.
> Even more importantly, what happens to teamwork?
I can concur with that thought direction. We used to pair and group-program on my team, we have a "Zoom office". Now it has become "let me take this ticket and feed it to Claude, you try the same thing with Copilot, and then we compare the results", or "I'd make a PR with my clunker, you use yours to review it". This shit honestly feels almost pointless. The pair-programming is absolutely dead. Who wants to watch me run several agents, trying to fix multiple things in different work-trees, while I'm juggling them around and fixing inconsistencies in my agents.md?
I've been pushing the idea of building a self-governing, fully autonomous cloud pipelines so we'd stop playing "stupid tokenomy" games, and it seems my management is just quietly trying to "keep it down", because I think there's a simple understanding - the moment that shit proves airworthy and actually can fly, a bunch of them are guaranteed to lose their cushy seats.
> Even more importantly, what happens to teamwork? If we are all a BBM now—or rather, if we all have personal armies of BBMs, permanently locked in a manic state, springloaded 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.
One example of teamwork is how the programmers and researchers worked together to build the UNIX SYSTEM (https://www.cs.dartmouth.edu/~doug/reader.pdf). It is not a product but an environment optimized for building tools and solving practical problems with tools written in C (while BBMs were busy with Lisp in Boston .;-)
C++ is a totally different story and you need an IDE for that.
If WASM succeeded in being the one universal ABI, it could be the perfect successor to the unix pipe for the AI age. Wasm modules for libraries, that double as terminal tools.. One could only imagine
I highly agree with the pro-Lisp sentiment. The main article that comes to mind while reading this was also posted a little while back on this forum: https://isene.org/2026/05/Audience-of-One.html
Tarver's piece was new to me, and fun, and spot on. Yes, LLMs bring the emacs cruft heap to the masses. A throwaway culture on disk is a lot less worrisome than one on soil.
I would add to that a few more open questions that I haven't seen addressed:
- As more engineers (and non-engineers) pick up coding agents, everyone is authenticating multiple MCPs, creating an n * n explosion of complexity that is impossible to centralise. Multiply this by the number of distinct coding agents for every platform and visibility is very tough. A lot of platforms also don't support scopes so you can't enforce safety short of a network proxy I suppose
- For non-developers mainly, lacking mental models such as <agent> for Y desktop app does not imply that there is a local LLM running on your machine. I suppose it's a question of trust and education versus starting conservative and progressively onboarding where we're more of the former.
- We talk a bit about the idea of sharing prompts but that fundamentally a prompt does not in itself contain quality. I've had internal tools I've made where it's mentioned that Claude made it when I mean, yes to a degree but I did many iterations using my own taste to refine things and held opinions about how things should operate. Giving someone a prompt won't inherently guarantee anything of quality. I often think about the idea of ie; give a screenshot of Github to an LLM but in a way, you're saying to create a clone, not of what exists today but is a dead echo of the design taste and choices made years ago that persist today. You can create things cheaply but without taste and good judgment, how can you continue to evolve it in a way that isn't like that draw the rest of the horse meme.
- I personally wonder about tokenmaxxing stories you hear about from other companies and like, logically what happens to glue roles? Does someone like a Microsoft just stack rank on token count and fire those who actually get work done? I suppose they already hollow out knowledge anyway so maybe it's nothing new.
- Definitely the thing with internal tooling where eventually you generate so much that you fundamentally have no mental model. It's fine for non-critical stuff and I'm kind of coming around to the idea that it's actually a better position to have no idea of the code and a strong "theory" of how a thing should work than it is to fully understand the code and have zero "theory". Ideally both of course.
Anyway, this isn't a comprehensive ramble but I've also been a bit disappointed that there hasn't been more talk about the second order effects. Many things can be true at once where you can see value in LLMs while still being critical of them and the whole DC situation ie; Colossus 1 etc.
In Emacs-land. Obviously clicking a button on the app store is easier than describing to an agent precisely the application that will solve your problem. But Emacs doesn't work this way. There's a whole subthread next to you that got all confused about this and started challenging Dan to like a WhatsApp duel or something; they've all missed this point completely.
Maybe it’s just another cocoon but I’ve been working on a framework for modular CLIs which allow different humans or agents to spin different features simultaneously but with some enforcement of shared dictionary, aliases, help, logging, formatting, semantic parsing, a few other things.
It works, it’s powerful, and certainly one way to answer the question you pose. I would argue it’s the optimal answer, it’s an answer to RPC, REST, and MCP at the same time, but it’s definitely an example of an answer and approach. In any case it is a good question and something I’ve given a lot of thought to.
Unfortunately in the age we’re in now there’s something lackluster in sharing any solution or design you have. Though the architecture and design of what I’m describing came 0% from AI everything is assumed to be and therefore unimportant? But it is the direct answer to your question so if anyone’s curious lmk.
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.
Is you actually look at the Lisp ecosystem as it exists today (even just Emacs by itself) you'll quickly realize that none of this is true in practice. Other people have pointed this out.[0]
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.
Paralleling Linux and MacOS is pretty simple, but the last time I tried to make the same config work properly in Windows it was a nightmare b/c of the path issues.
In the past when I've seen someone extolling Windows/Linux compatibility for something as complex as a detailed Emacs setup, they were using WSL or one of the wrappers like Cygwin rather than native Windows compiles of the tooling.
For whatever it's worth, I've always only ever used the native Windows build of Emacs, and I've never had any awful problems sharing my config between Windows, Linux and macOS. I'm sure I had to expend at least a bit of effort to make this work initially, but it wasn't enough for the process to stick in my mind, and the ongoing effort doesn't feel like it's added up to much.
(I admit it's added up to more than zero though! Keeping (require 'cmake-mode) working reliably on Windows and macOS has proven a minor annoyance, and fonts seem to require a degree of system-specific attention.)
The problem is the dependencies, getting hunspell installed and finding the dictionary files for example. I normally only get a new computer every few years and each time stuff like that is a new pain. And dont even start with treesitter, i cant compile anything on windows and always end up using prebuild dlls.
> I want my life to have as little maintenance as possible
I honestly can't even relate to what that even means. I'm a programmer - my everyday job is all about changing the behavior of computer systems - local, remote, cloud, embedded, etc. Requirements change, scope fluctuates, problem space evolves - grows and shrinks, accretion is unavoidable. I need to routinely move between language stacks, different data types, formats, CLI and web tools, protocols, paradigms, OSS and proprietary apps.
That means I have to constantly adapt, my control plane has to keep up with the flux. Automation is key - you must develop a mentality for that - every little annoyance can be and shall be automated. That is an endless, non-stop transformation of my workflow - continuous maintenance of my tooling. But that is not some toilsome, reactive maintenance.
Thinking that you're a programmer that doesn't want to constantly build software for your own sake is a delusion - it's like a cook that hopes to turn on the stove only in the restaurant, but won't touch a knife at home.
Emacs is the cook's home kitchen. I'd say there are two kinds of maintenance: reactive (fixing breakage, keeping up with churn) versus generative (shaping tools to match your evolving understanding). Programmers instinctively dislike the first and should be drawn to the second. Emacs is almost uniquely suited to generative maintenance because the tool and the work share the same substrate.
I get your complaint about Emacs specifically, it's a common: "too much work to set up", which usually means: "I don't want to invest before I get value", which honestly is not wise, strategic thinking. Treating Emacs as the universal tool for minimizing total maintenance burden over a career, over a lifetime is.
I think your analogy breaks down because lots of people don't program "anything and everything". I can relate to being considered quite an expert in certain programming domains among my peers, but there being all kinds of potential programming around me that I just don't find interesting at all.
Programming is also so much broader than something like cooking. It would be like saying that "you make your living manipulating matter, how could you not want to manipulate all that other matter?" to a chef. Their cooking doesn't necessarily make them want to mend clothes, remodel houses, devise new pharmaceuticals, etc.
Yeah, sure analogies are... well... some made up shit we use, because we have imagination. And the imagination can take you for a spin.
I just disagree with why Emacs heavy users are often "blamed" to be obsessed with their tools "needlessly". What does it even mean to desire "as little maintenance as possible"? Okay, let's say I don't use Emacs (which is like I dunno over 90% of existing programmers in the world). What, I won't be writing bash scripts for my work? Okay, maybe I really hate Bash. Python then? Lua? Perl? What the hell are we even talking about? Of course, a programmer will do these things. Every programmer does. There's not a single case where a programmer doesn't tweak, re-tweak, personalize, improve, readjust their tooling, their scripts, browser extensions, the set of apps they use. Why is it Emacs and Vim considered a "perpetual maintenance", and I dunno, VSCode is "it just works™"? That's just not true. If I didn't use Emacs, I'd be inevitably re-inventing some workflow automation in some different way. Or what, bash-scripts ain't no software?
I'd like to make some points more explicit about my philosophy.
1. Yes, everything has a maintenance cost. Some choices have less. For instance, electing to choose Todoist instead of org-mode for my todo list means I no longer have to worry about syncing, merge conflicts, or whether the mobile app I've chosen fully conforms to the spec (well, whatever attempt at creating a spec existed at the time).
Of course, I am paying a very literal cost for convenience, and offloading maintenance to the Todoist engineers.
2. Emacs is a cool piece of software, and I am glad others have figured out how to leverage it, in such a way they have a configuration for life. I spent a lot of time marvelling over the set up that Protesilaos had for his writing [0]. It just wasn't for me.
3. For Emacs, if I want to use it like I wanted to, I have a couple of options. Install a package like Doom Emacs, which gives me most of what I want, with a whole lot of cruft I don't. And I have to keep that up-to-date, and worry about random community plugins breaking. Or figure out what set of plugins (after first picking a package manager) to incorporate. Or figure out the Elisp to do it myself. And my writing config would differ from my software engineering config.
No shade on the people who want to do this, but I just... don't? I can use Zed, or VSCode, and I'm 90% of the way there. Install (or configure) the Evil mode equivalent, and I'm happy.
4. One of the smartest engineers I worked with couldn't touch type until about 20 years into his career. The idea that everyone is ricing everything they do, is unrealistic.
To summarize: your claim is that choosing to spend your energy on anything other than your emacs setup is a catastrophic failure in terms of ROI, a delusion, and a sort of dereliction of identity as a programmer. My rebuttal: dude, relax.
Are you even reading what I wrote? What's with the childish tone, someone dropped your keyboard rate when you're a kid or something? Emacs is a tool, not a religion. There are plenty of talented, accomplished programmers who can relate to what I said, and never even used Emacs. There's no "Emacs setup" for me, just like there's no "ricing my browser" - I do expect my web browser to work exactly the way I want (or at least as much I can get out of it) - that requires managing extensions, keybindings, extension settings, security options, disabling some annoying features, etc. It's an instrument, and requires the same type of "maintenance" and tweaking. Sure, it might not be as constant as for Emacs, but after all - web-browser is a targeted tool, Emacs is a universal one.
Whoah, whoah, whoah, you two, this is a happy post, not an angry post. Nothing to get wound up over! Part of the point is that you can both just go and do you!
We're not fighting, we're just "emotionally explaining things to one another". That's what my wife says to calm our dog, when he makes a concerned and scared face over a regular, non-confrontational conversation. Just to be clear, I'm not comparing you to our dog, I just thought it's a funny anecdote.
"Emacs is a tool, not a religion" yeah that's my point. You framed not investing in it as a delusion. We can all agree on the importance of tooling. I am responding to the tone of the sermon you wrote.
Like the cartoon character once said: "Yeah, sure, I mean, if you spend all day shuffling words around, you can make anything sound bad"... Re-read again what I wrote. Specifically about delusions. I can't believe I have to re-quote myself just to prove you my point about something you just made up in your head.
> Thinking that you're a programmer that doesn't want to constantly build software for your own sake is a delusion - it's like a cook that hopes to turn on the stove only in the restaurant, but won't touch a knife at home.
> Emacs is the cook's home kitchen.
The two sentences are adjacent. I read them as connected. If you meant them to be unrelated, I hope that this sheds light on our disagreement.
How often do you fish out a single word in a paragraph that has no semantic, emotional meaning to you personally and automatically flip the entire book, just because of one word?
What I meant is that viewing Emacs merely as a means to achieve a singular goal and to extract specific value (e.g. "I've heard Magit is nice") is shortsighted - approaching it as a strategic, long-term investment yields far greater returns. I'm not preaching for absolutely every programmer to use it.
Come on, now tell me how I think of everyone who doesn't approve my web-browser tweaking habits as "catastrophic failures"...
You keep doubling down on your own perverted reality you composed out of thin air and somehow I have to apologize? Can you be I dunno, less emotional and more substantive? There's no controversy in what I wrote - it is pretty simple and straightforward:
Programmers write programs. That's the definition of the job. Any personal tweaks - scripts, snippets, extensions, packages, configs (for VSCode, IntelliJ, Vim and yes Emacs too) are also programs. Saying: "I don't want to maintain my programs" sounds to me like saying: "I don't want to be a programmer". It doesn't matter what I use - Emacs, Sublime or Macromedia Dreamweaver - configuring and maintaining it is not "kind of a job", "part of my job", or "someone else's job". That is my job as a programmer. Period. End of discussion.
Why the fuck you keep pouring your own made up shit from one pitcher into another, thinking it's about to turn into gold, is beyond me. And somehow I'm the dude that should "relax". Well, sure, let me then apologize for my inability to explain to you something that a six year old would get off the bat.
Now allow me to explain to you kindly, why you're fucking wrong here. You probably have no idea how difficult it is to write anything meaningful in English. Especially these days. For someone for whom English is not a second or even a third language, it can be an enormously hellacious ordeal. I take pride in my English. I think it's quite possible I would never write so colorfully in any other of the three languages I have. For me, each paragraph has meaning, has voice, its own character. It takes time to write. It takes patience, humility, imagination. Machines can do it already, but their language still lacks something. Something ephemeral. Something that would make us watch for two hours, humans doing crazy acrobatics of Cirque du Soleil. I wonder how long would we watch robots doing the same? Well, who knows, maybe we'd be watching robots dancing for two hours. LLMs are getting better with languages too. Which makes it more difficult to write. Properly structured text gets blamed for being generated. Sometimes I deliberately don't fix mistakes, even though it makes my eye twitch. Darn, I'm so pissed I can't use em-dash anymore, goddammit.
I don't owe you an explanation why I do it, why write anything at all. Why HN. I'll say it anyway. I do it because I still recognize people here. Living, dreaming, learning, fighting, hating, daring, loving people. I don't get paid for it, I don't seek recognition, I am not trying to build a name. I share my opinions because nothing is more important for our species than storytelling. And we need to share stories, listen to them, re-live them, learn from them. That's why many of us would go to watch Nolan's rendition of a 2700-year-old story. Even if we don't like the movie already.
And then someone like you comes, shits all over your charming writing, compelled to do it just because they see a word they don't like. Well, honestly, fuck you. Yeah, not nice, but I'd rather be kind and tell you the truth. You wouldn't be saying the shit you replied to me with to my face. Not because I have muscles, or am intimidating, or weak and miserable, no. But because you're definitely not a jerk, or an idiot. I wouldn't have to spend hours wasting on your ass for no good fucking reason. Seriously, I am a solo father with two kids, it's fucking 1:30AM and I'm having to deal with this shit, because writing for me is still fucking hard. English is beautiful, but hard. Come on, kid, think sometimes. For the sake of fellow humans.
Less about the capabilities of LLM software, but more about my willingness to spend time to deploy them, debug them, etc.
I don't want to spend time on dealing with change. Hence why I'd rather purchase tools, where I pay for the developer to a) prepare for any maintenance, and b) will perform the maintenance needed.
(Of course, the maintainability of software with current generation LLMs depends a lot on how well your architecture them. I've got pure vibe coded slop, that can be very difficult to wrangle.)
> So LLMs are good enough to make personal software, but not good enough to maintain them?
I mean... yes?
Maintaining software means looking at issues opened on github, keeping your own list of feature requests and bug fixes, deciding if and what to fix, deciding when to fix, and if you're lucky/cursed, reviewing PRs from randos. ANY of this means diverting attention from your day job/client work/kids/???.
Can some of this be theoretically automated by an LLM? Uh, maybe? But I'm not sure how much that would help.
"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.
The road not (yet?) taken is the full flowering of the HyperCards, the Visual Basics, the Macromind Directors and Flashes...
That is, the idea that a non-expert might create interesting software in an authoring environment with good, well-thought-out building blocks and easy-to-grasp metaphors, shorn of layers of accidental or over-engineered complexity.
In this vision software still requires careful logical thinking, but it makes it much less cumbersome to translate that thinking into running code, with no tooling and build system nightmares.
Instead, we've invented such powerful models that they can regurgitate and recombine complex incantations on our behalf. The complexity is still there, though, and it's still inscrutable to non-experts.
But maybe they can help us eliminate some of it?
I think that path is still possible, and it may even nicely complement the LLM world, where LLMs help generate software that individual humans can still easily comprehend and manually modify.
I have told this to many friends who scoff at me, but using a computer is very clearly going to also mean "having the computer create programs for you". We won't even think or know about it.
To me, it isn't a matter of if, and the matter of when is also very clearly in "at most 10 years, probably much, much earlier", given that I have relatives already doing this without knowing how to code.
This is a future of computing I am absolutely in love with, and is so incredibly empowering!
> We're not there yet but with LLMs we're getting closer.
I feel I'm there. Whenever I have a problem I definitely ask "should I vibe code an app for that?"
My current Swift app has 15K LoC (5K in tests, 10K implementation) and it is finished. Like, there are minor improvements now, but it does what it needs to do. It took me 20 hours. I think the actual thing would personally take me 500 hours as I haven't programmed in Swift.
My fears with the situation you are describing is that we end up without a common file format, if everyone has a propietary app and/or file system then that makes transition or collaboration a pain.
We probably won't end there due to how lazy most of us are, but it's certainly something to consider
I feel like I'm way more cynical than most people around here about LLMs but if we accept the parent comment's framing, why can't we just use an LLM to write a throw-away converter to whatever new format is necessary? Yes of course it'll probably be lossy occasionally but the question will be, is that ok for the user doing the conversion?
LLMs are great for problem exploration. Especially with the decline of Google I think we're at a point where it's less difficult to get an LLM to spit out something that'll accomplish a task sorta compared to actually finding that on the internet. But if the task is going to be repeated or modified then I think LLMs are at a permanent disadvantage to prebuilt software. Even if that prebuilt software is just someone else running an LLM and then passing the output through acceptance testing most people just don't want the headache of debugging weird edge cases and the novelty of "I'm a developer too!" wears off pretty quickly.
I'm excited that the weird grey-zone of excel sheets with business critical logic is likely going to disappear as LLMs slowly make the logic driving those too complex to be comprehended and managed and those get foisted off onto actual engineering resources. It'll be painful but probably for the best... but for actual tools people need to use day-to-day I think the assurance that the tool will work has a lot more value than the AI hype has comprehended.
Oddly enough, Google’s LLM is the only one that has been answering my questions well on a research project these last weeks. I’m getting information from scanned text files that exist on the internet but were never adequately OCRed by other LLM companies (i.e. both OCRed at all, and moreover OCRed as the specific language in question that picks up all the diacritics). Google search results may be disappointing and polluted for years, but the company is still offering a useful product in another tab of its interface.
> Oddly enough, Google’s LLM is the only one that has been answering my questions well on a research project these last weeks.
Google Search declined in quality when results started containing more noise (more ads, SEO spam) that required sifting through. Gemini isn't displaying all that garbage.. yet.
I've found Gemini to be very helpful in figuring out all the fiddly linux problems that used to require reading endless forum posts and digging through docs.
Literally everyone had a ZX Spectrum, or Commodore 64, or a BBC Micro if their parents were rich and thought that having the same as they had at school was a good idea.
Around 5 million ZX Spectrums were sold between 1982 and 1992. If all were sold in the UK (they weren’t), that would put the penetration around 25% based on the number of households in 1990.
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
The author highlights an interesting point. There are a couple variables in action:
A- The difficulty to publish the tool
B- The difficulty to create the tool
C- The usefulness of the tool to others
D- The social reward for publishing the tool
E- The negative incentive of adding a dependency
Difficulty to find a canned solution goes up with A (because someone needs to create it) and B (someone needs to figure out how to publish it), but, the more useful it is to the community (C), the easier it gets to find it, because people will tell you.
If A and B are substantially different, if A is much higher than B, people will tend to write their own and forget about it. If B is lower, there will be fewer solutions to your problem. If A and B are low, and the social reward (C) for A is higher than the price of depending on something else (E), you'll have a leftpad situation. A lot of NPM is made of packages with high C and D and low E.
In the case of Emacs Lisp, A used to be high, but now is low, B (once you climb the learning curve) is low, C, D, and E aren't high either way. This can lead to a scenario where you build the tool before you even look if there is a tool that does it (unlike it is with VSCode, and with Eclipse before it - both have a high B).
I see a thesis someone younger than me will want to bring out to this world.
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.
Yes. You can do that. It works right now. It works really well.
My original spicy take is: why learn SwiftUI at all at this point? It's a skill that, for most tasks, falls into the same kind of bucket as "learning Microsoft Word really, really well". I appreciate people who take the time to do that, but the outcomes are within millimeters of each other whether or not we do that.
I don't think that's true of programming generally. But I think there are languages now where the rationale in specializing in them has gotten, hrm, more complicated.
I’m a SwiftUI developer at $DAY_JOB so maybe biased but while Claude can make things that look right it’s still not exactly perfect. Especially from designs. I used Claude design to mockup a monitoring app for my talos cluster and Claude code totally freestyled it. What should have been as simple as `List { Section(“title”) { … } }` got morphed into whacky DIY `VStack {}.background(.gray)` nonsense.
It looks off and it’s suboptimal performance-wise. It was, I’d say, 80% of a proper SwiftUI app (which is really fantastic given it was basically a one-shot).
Actually knowing SwiftUI meant it was trivial for me to just close out that remaining 20% by hand and have an actually *nice* cross platform (iOS, iPadOS, macOS) app.
I’m sure I could have prompted it to get it done right but without proper knowledge on the subject I wouldnt even know what was wrong and Claude doesn’t do so hot with “that just feels wrong”. Beyond that it was quicker to do it myself, but maybe I just need to prompt better /:
I have absolutely no doubt that an experienced SwiftUI macOS developer could easily produce better UI than Claude can today. The thing is, Claude produces better UI than a replacement-level macOS developer can, and, much more importantly --- this is really the core of my argument --- \infty better UI than a typical developer can produce, because most developers don't ever build native UI.
If I'm shipping a product where each development/release cycle costs my team $5MM, I am absolutely going to spring for the professional SwiftUI developer.
But most things normal developers build in their spare time don't even cost $50 per cycle. Unless they're UI learning projects or projects by UI experts, there is no "budget" for UI. At best, for real labor-of-love projects, you get a TUI where the developer spends 5 hours of their life that they will never get back creating a 70%-functional terminal version of the affordances the native UI toolkit provides out of the box.
That's all over now. However competitive Claude-generated SwiftUI user interfaces are with expert SwiftUI projects, they roflstomp the UI options available to most developers. I can't say enough what a smoking gun the flickering Signal app is here!
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.
In all honesty, when you start up emacs for the first time with a blank config, it looks terrible. But then you start building it up with plugins and adding code to support your own quirky workflows and slowly it becomes too powerful in your life to ignore. I have not been able to drop it for 13 straight years. With AI taking over the development experience, emacs and neovim have only become even better, because now you can get AI to bake your custom workflows into the config for you.
Emacs/neovim should be the gold standard for all workflow tools.
I'm currently polishing one of my packages for publication, and for that do a lot of testing in a vanilla Emacs. It's shocking how many of even (to me) absolute core functionality is actually customization I did a decade or two ago, and then forgot about.
I did the same. I started with Doom Emacs and then a year later decided to start from scratch and build the computing environment I wanted. But I think the experience of Doom showed me what was possible, what I liked, and what I really had no need for.
I make small config changes every day and its super fun to use my computer this way. I wish everything was configurable like Emacs.
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.
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).
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.
Maybe it's a good idea for SWEs to consider using LLMs to train themselves into new careers -- just in case.
Most other "knowledge" professions -- by which I mean teaching, programming, some engineering, and the arts -- are even further along into obsolescence. That said, you can still use the knowledge gained in a knowledge profession to convert into a more hands-on profession. We might have a bit longer before humanoid robots destroy all hands-on job opportunities as well. Once that happens, every person will be equally poor and destitute.
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.
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.
This really resonates with me. The ability to quickly writing one off, personalized apps really seems to be the strong suite of GenAI.
A month or so ago, I had claude write a visualizer for some data. There is an existing python viewer, but it bogs down & is painfully slow at the scale I need. So I asked Claude to port it to a compiled language. After 2 hours of iterating, I had the tool that I wanted.
Note that its throwaway, dumpster fire code. But for a one-off tool like that, its fine.
> Ehmm, weird, I can't be the only one in the room. You guys didn't know about gfm and gfm-view Emacs modes?
I'm using Emacs since last century and I've got 3 000+ lines of custom Elisp code I wrote (with maybe only a few hundred lines copy/pasta'ed from other configs).
I'm always using a recent Emacs compiled from source and now with LSP, org-mode, Magit, tree-sitter, ivy/avy/counsel/swiper with ripgrep (thanks burntsushi) integration etc.
I had zero frigging idea what gfm and gfm-view for Emacs were.
I know, right? You'd be like "using Emacs like a boss", going with your keyboard "frrrrrrrr" (well, no, that's not Emacs, Emacs would be like "C-c C-c C-c C-c C-x 8 and only then frrrr"), managing entire k8s clusters, building it from the source using most esoteric build options, --with-fries-n-ketchup, and all. And then some jerk comes out of nowhere and tells you about fancy-pangolin-mode that's been sitting quietly in core Emacs since the Prohibition and you're like: "goddammm... I've been using it wrong, my life is meaningless..." :)
We're old people. I mean, an eleven-year-old who opens Emacs becomes old in an instant. We have invented doom-scrolling. We've been going through the M-x menu way before twitter and reddit made it a thing.
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.
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'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.
Which is where the "emacsification" analogy breaks for me.
The reason people who like emacs write their one-off program in emacs is that it is an extraordinarily introspectable and debuggable programming environment. There is no "code, compile, run" loop - you just write code against the live running environment. Devoid of that fast feedback loop, writing code just isn't as much fun.
Well taken, but for MANY years, I copied and pasted elisp snippets off stackoverflow without understanding any of it. And to this day, there as many xkcd-style "space heaters" as there are emacs users. OP's point stands that LLMs make possible a new generation of quicker, dirtier hacks destined for the cruft heap.
Not OP:
- One shotted script that I schedule through cron that sends me a message when a new one piece manga chapter releases.
- Also a simple script that moves my cursor one pixel every 30 seconds. Cannot disclose why I need this.
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 read the suggestion as being that the world’s poor aren’t paying for AI tokens (or subscriptions) to generate software from prompts, and that sharing the _output_ is more beneficial to people. The reduction in energy waste is secondary, and benefits _everyone_.
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.
The point of the article is that the whole gestalt of what you do on a computer is now one big programmable surface, and in that regard everything feels a lot more like Emacs.
It's not "about" Emacs, it's more about the vibe of personalized software in 2026 to someone who does a lot of Emacs stuff.
> whole gestalt of what you do on a computer is now one big programmable surface
Emacs-effect. Use it long enough and everything becomes "one big programmable surface". I've been in that modus operandi for years. Emacs is my "control room", I don't necessarily do everything in Emacs, but for sure it converges all into it - everything flows through Emacs. I control my WM directly from the REPL inside Emacs. I can grab a content from a tab in my browser - I have access to my browser history, and all the tabs, I can switch to any tab, close and re-order them. I can grab a text selection on the page, I can extract entire readable corpus of an article while ignoring all the irrelevant fluff - banners, ads, buttons, etc. It works even for js-rendered content (React, et al.). I play all videos controlling them directly from Emacs - even though the video itself is playing outside, in mpv. I still can pause, change volume, fast forward, speed-up, extract transcript, etc. All without leaving Emacs. That's pretty useful when taking notes. I can grab any text I see on the screen. Even if it's in Slack.app. Why, If I can read it, there's no reason why Emacs shouldn't be able to. I can grab any region on my screen with Flameshot, it goes through Emacs, runs tesseract and OCRs the text out of it. Useful when someone's screen sharing in Zoom. This was all possible before LLMs. Now, LLMs running in Emacs can do some crazy, wild stuff.
mpvi [1] is the video control part. I have only used it a little bit but it is incredibly good. Control the playback completely from Emacs and quickly make timestamped org notes.
I don't know what the other parts are. Curious to learn!
Not really the same. Emacs focus a lot on compatibility and common modules (even if there may be some different takes on those common things). So you got big systems like helm, consul, ivy, company,… and the. everyone building on top.
Another thing is configuration (which also ties to the previous statement). You have to be able to split the idea of the program (what it aims to do) and your personal preferences. Emacs make that easy by having a framework for user preferences. That makes for an extendable program.
The closest, but not as user friendly is unix and suckless philosophy combined. Small programs, easy to understand, configure, and extend.
The article provides an analogy, it doesn't tell you to do anything with Emacs in particular.
Besides being an everything app for you, Emacs is an (unconventional) operating system with weak boundaries between user apps. It makes it easy to modify anything, write new things, or combine two existing ones with very little code, something that e.g. Microsoft could have only dreamed of in Office with its awkward embedding that barely worked. Emacs is one the few survivors of the idea that users should program what they need, which was popular during the personal computing revolution in the 80's. Two others are spreadsheets and BASIC.
Programming turned out to be too complex for the untrained users to handle, but AI makes the idea of custom one-off apps or weird hybrids pretty damn close, that is true in practice. I see a lot of people that vibe code their own little things to get things done. That's precisely what BASIC (often shipped in the stock ROM!) was supposed to be used for.
I think that "the number of programs" you're suggesting is arbitrary. It's kind of like calling an operating system one thing, when it's a lot of things. You can "count" the things different ways.
The bigger takeaway is "making your own programming things."
> When my Emacs opens a markdown file it immediately converts it into OrgMode format.
I want that. Can you give some details?
A search finds modeverv/markdown-to-org which looks 80% there but activates based on a yank or converting an already loaded markdown buffer. Perhaps it can be made to apply on opening a .md file.
I know, right? Org-mode is soooo much more practical. imenu works great, sparse-trees are awesome, you can edit pretty much any part¹ in an indirect buffer and all. These days I try to consume anything that can be fit into an outline, in org-mode - hackernews², reddit³, slack⁴, jira boards and tickets⁵, wiktionary entries⁶, etc.
Fun anecdote - I once needed to sort some nested items in a big yaml file. After spending three minutes trying to understand sort-regexp-fields (or some other function), I cheated - I ran org-mode, and then org-sort and then went back to yaml-mode. So stupid, yet so brilliant. Why the heck would I ever want to use "first-class IDE" or "intuitive, plebeian editor" if Emacs has anything I could possibly imagine? Right at my fingertips.
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.
I've always found it easier to collaborate using markdown. It's much more popular than org-mode! And you can get org to export text as markdown, so interop isn't necessarily even all that difficult.
And as per the general theme of the post anyway: whatever. Because you can just work around it, whatever it is, by cobbling together some code, one way or another.
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.
> 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.
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.
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.
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?
If you’re building for the "love of the game", aren’t you unlikely to post an artifact that is produced towards the end of your project and targeted towards a publication (e.g. hacker news)? I recall Mitchell Hashimoto was saying he used to browse GitHub as if it were a social media (which it is) - perhaps that’s your jam.
Merely an example but I would not, one of my gripes with LLMs is the training on general sentiment and trends, so they tend to recommend whatever is popular.
There's a reason we're not reading monospaced here, and a reason we do read monospaced code.
But the beauty of this moment is that if you want a really good SwiftUI monospaced Markdown reader, you can have it before dinner. This is exactly what I'm talking about. You have an idiosyncratic personal preference, and it's now reasonable to expect software to shrink-wrap around that preference.
Generally I just don't appreciate when someone jumps from "I care about this" to "everyone cares about this for obvious reasons." Focus on what something means to you, and being sincere about it. But that is just my advice for writing, take it or leave it.
Also, are browser text area inputs monospaced by default for everyone? Or did I configure that for myself long ago and forget? If it's not just me, maybe the "reasons" you're alluding to are not so obvious. Anyway, I have no trouble at all reading the long comments I type into text areas.
Legacy decisions as a remnant from a time when taking more space on paper cost pages and therefore resources, remaining as a default from centuries of inertia in how text is printed?
No, prose set in monospace is harder to read. The "legacy" is monospace! We went way out of our way to to get proportional typesetting working.
But seriously: you do you. There are people who code in proportional typefaces and they're as baffling to me as you are right now. Let a thousand Markdown viewers bloom.
> The "legacy" is monospace! We went way out of our way to to get proportional typesetting working.
The legacy is proportional, at least in Latin script and its ancestors. Handwriting was proportional, of course, and so was Gutenberg's printing press. Books and newspapers have virtually always been printed in proportional type.
In Chinese and Japanese, monospace is legacy in both handwriting and print... and also still universally used today. All Chinese and Japanese text is monospaced by default. Billions of people are getting by just fine reading monospaced prose.
I don't really know where this conception that monospaced is somehow objectively harder to read is coming from. Actually, this is the first I've ever heard of the complaint. I can't help but wonder if you've been subjected to some very bad monospaced fonts in prose or something.
Monospace text is objectively less dense, which means you have to move your eyes more. Every eye movement is an opportunity for error. Monospace text only makes sense when seeing exact character counts matters (which it often does in computer code).
One could argue that less density, as well as standardised widths, significantly reduces opportunity for error compared to cluttered text that is constantly varying how it is displayed. Perhaps moving your eyes more increases opportunity for error by 10% but easier-to-parse characters decreases the opportunity for error by 20%?
Turn off syntax highlighting for your code, translate it to COBOL, and pass it through a formatter that converts it to continuous word-wrapped text. Then we’ll talk again.
There is a real use case for a viewer if you have a lot of formulas. Yes you can read the raw latex but you go cross-eyed after a while. Maybe I am a softie though.
I agree, but I don't think the author of this blog post is coming from that perspective, and markdown renderers of the sort described in the post tend to do pretty poorly with math typesetting.
Nothing personal but I hate this take with a passion, and I literally think it's representative of the worst attitude in computing because it's the literal opposite of software SHOULD BE.
The whole entire point of computers in their best light is changeable software, the whole point should be "let people read how they want to."
It was also the most prominent ecosystem for "software-for-one". Lots of custom-bespoke, "it works for me" packages that were only created for personal use.
> 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 read dogleash's comment as emphasising the bad parts of that. If everyone's just sharing their half-baked slop, it becomes harder for people to discover the good programs which are worth using, and harder for those quality programs to get social proof (or good direction).
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.
No one mentioned vi, I like neovim just fine, and I'm using pi daily. Nice try though. My only point is that if you want to talk about rewriting everything yourself, NIH, churn, whatever you want to call it, Emacs is absolutely not a great example.
Are we reading the same article? OP is saying LLMs let normies tweak their personal workflows in the same way we emacs nerds had been doing for decades. Contrary to the old saw about it being an OS, Emacs is really just a shell but with lisp as its command language instead of unwieldy bash. Once Claude magicked an English to bash translator, raw shell has caught up to emacs in its ease of use.
The new thing where everyone just vibe codes their own versions of everything is not at all like personalizing Emacs.
Specifically the idea that people generally just ignore existing versions of packages and make their own has never been the case, especially compared to other editors (even VSCode).
> There are popular elisp packages lots of people use. But except for Magit, nerds are alarmingly apt to replace them with their own shinier versions (and then to show them off, transitioning to the spore-forming phase of the elisp lifecycle). Everything in Emacs is malleable.
> Until now, the Achilles heel of Emacs culture has been that, except for Magit, its packages tend to be wretched user experiences. Ugly, slow, and discoverable only after inflicting years of elisp cortical injuries on yourself.
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.
Setting aside the fact that good content is more enjoyable than bad content, experiences are meant to be shared. Humans are a social species, and a very large part of media consumption goes beyond the actual consumption and into sharing that experience with other people. People build communities around the media they like, and even integrate their favorites as part of their identity, wearing branded clothes or cosplay, decorating their rooms with merch, setting wallpapers, and so many other ways to signal what they enjoy to others. "Content creation for one" rather misses how humans work. Heck, not only media but even tools are subject to this -- people legitimately make emacs or vi part of their personality.
> The entire economic model of content creation and distribution is going to explode in the next 3 or 4 years
I think this is also inherently self-contradictory. What's the point of distributing content made for one? This gets into the same fallacy that people engage in w.r.t. "applications for one" displacing software developers. Yes, LLMs can pump out buggy software that suits one person's needs, and it doesn't need to be reliable enough to deploy at scale. It serves real utility here, because there was a gap between "the value of such software" and "what software developers are willing to work for", which meant that this software wasn't being created because there wasn't economic value in it. But then, how does one suppose software that has no economic value is going to replace all the professional software developers who were being paid to produce software that has economic value? LLMs filled a gap software developers weren't being paid to do, but given that they were not paid to do it, their jobs are not contingent on the existence of this niche. It simply doesn't follow that being able to produce content with zero economic value, whether that's applications or content for one, will cause an 'explosion' in the existing economic models.
I think that software made for one fills a similar niche to ultra-processed foods — many of which were created to supply soldiers with sustenance in an active war, and continue to fulfill the needs of their consumers (travelers — who might not have the time or space to practically prepare a home-cooked meal, working professionals — who similarly benefit from less planning and food preparation), but as research has evolved, society has realized that these meals are linked with metabolic disease and adverse health outcomes.
Applications for one, might serve as a sort of "ultra-processed software" that can fill useful niches like generating textbooks on the fly (https://news.ycombinator.com/item?id=48130679), generating focus oriented music for long study sessions, and obviate writer's block.
However, I feel like there are downsides that are both obvious (insularity, discoverability, reliability, and platform dependance) and non-obvious issues which will take time for the public to determine what they are.
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.
The common denominator: the data needs to be owned by you, or at least made accessible. Companies love to create walled gardens where they own the content and control how you access it, making this kind of personalized interface impossible. Hopefully we can push back more now.
I agree that owning the data is ideal:
https://news.ycombinator.com/item?id=48129841
I mean, hold up, if that thought lights you up I'm happy, but I don't actually think that's the common denominator. I used Things.app to track projects for a long time and ultimately fell out of love with it. Things.app didn't own my data; it's a pure UI app.
But now it occurs to me: I know precisely how I work, I know what patterns are valuable to me, I know when and how I need to remind myself of things. I don't know why I haven't already started building my Things.app replacement. But I'd guess I have it to a place where I'm happy by this time Saturday.
Honestly, it's harder for me to think of daily-driver apps where this wouldn't be the case. I guess vector graphics editing? I'm not going to vibe up a vector editor. But I'll bet all the money in my pocket that 5 years from now, the real value in vector graphics tools will be their API/SDK, not the packaged application experience.
I'm not following your reasoning about the common denominator, not sure we're on the same wavelength about what I meant. I'm claiming that in order for an application to be "reclaimable", you have to be able to access and manipulate the data under the app. Some applications currently work that way now, lots of them don't.
For example, we can "reclaim" non-DRM ebook readers, audiobooks, and music players that play local files or use an open API. But a company-specific walled garden streaming DRM'd ecosystem will be almost impossible to build around.
You're talking about entire systems. That's something to be optimistic about too. But it's actually not the thing the comment you responded to was about. I'm not saying I'm excited to get out of the Apple Music ecosystem (I like Apple Music, the service, quite a lot). I'm excited to get out of Music.app, and into my own custom Apple Music player; one where playlists and play history are simple, sanely-schemaed sqlite databases.
I gotta be careful, I'm going to talk myself into staying up late tonight building that.
I was too, thinking about making my own apps for a lot of stuff, but for now I’m sticking to web apps because distribution on mobile is still crap.
Why are you distributing at all?
> didn't own my data
Ownership can have different forms. Slack.app that doesn't let me easily extract code snippets from a thread - owns me. Jira that forces me to use their imbecilic, quirky wysiwyg owns me. Note taking app that keeps the data in their db and not my files - ain't my friend. The friction is the ownership. When extraction requires effort, the tool has leverage over you. It's a subtler form than data lock-in - behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay in Slack/Jira/Dropbox/Evernote/Notion/etc. longer, search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates.
Plain text, local files, standard formats - they don't fight you on extraction because there's nothing to protect. That's why investing in FOSS tools is almost always paying for your own liberation rather than your own imprisonment. Even when there isn't feature parity, even when the FOSS tool doesn't have a "polished UI" and it's "maintained by a teenager in Nebraska" - still a better choice.
Not necessarily, you can ask the LLM to reverse engineer the protocol.
Our social media should be decentralized and local first, allowing for bespoke clients on any OS.
This is an experiment towards that:
https://github.com/dharmatech/9social
The first client is written for plan9. This keeps the design honest. (If it can run on plan9/rc/acme...)
Video demo:
https://youtu.be/q6qVnlCjcAI
The current implementation is less than 3000 lines of code.
And speaking of Emacs... 9social was heavily inspired by an Emacs project called Org Social:
https://github.com/tanrax/org-social
I love this idea. Thank you for the examples!
I've been thinking of this as well:
Something like old school Facebook in UI, but functions more like MSN Messenger. You connect to your contacts via P2P, and download/upload updates to your social media network.
> You connect to your contacts via P2P, and download/upload updates to your social media network.
Yup, local-first is central to the design.
And, you only see who you explicitly follow.
I love your username!
I hope there's a sympy-thagoras out there.
( • ‿ • )
Sounds similar to scuttlebutt
I absolutely LOVE secure scuttlebutt (SSB).
Their local-first approach inspired that aspect of the 9social design.
However, a big difference is that SSB is a sophisticated protocol.
With 9social, the heavy lifting is done by git and a set of conventions.
> I love this idea. Thank you for the examples!
Thanks for checking it out!
How to upvote in bold? /j
It's plan9 so:
"There's a filesystem for that."
¯ \ _ ( ツ ) _ / ¯
What would be amazing now would be a way to deploy my own Claude-built utility applications to my phone without having to go through the effort of securing a Mac developer account and going through that whole rigamarole.
* Time trackers
https://repo.autonoma.ca/repo/timeivy
An unfinished spreadsheet-based interface for entering time. Meant for consulting, but never got around to persisting the data. Mostly created it because I couldn't stand all the ways that time trackers force users to enter structured time when there's a cute algorithm to handle just about every way a human might naturally enter time.
https://stackoverflow.com/a/49185071/59087
* Recipe managers
https://repo.autonoma.ca/repo/recipe-fiddle
In the days of LLMs, it would be far easier to categorize ingredients and format them into TeX for publishing as a PDF file. The idea behind this project was to let people essentially copy/paste recipes off the web or scans of handwritten content and autoformat it.
I just made a one-shot Android music player because I need a very simple one to listen to tracks to practice drums, and I need to go back from the beginning a lot of time, reduce speed, open them from Whatsapp when my teacher sends them to me and access easily the last 4-5 played. There was nothing in F-Droid that ticked all the box so I just made my APK.
Someone wrote a web server in assembly the other day: https://news.ycombinator.com/item?id=48080587
It is very inspiring.
> but certainly an application more closely tailored to exactly what you want it to do for your own idiosyncratic work style.
Yep, I'm doing this all the time. I've been doing it for a year. The silliest on is an IG post previewer. My app is better suited to me than the preview function that Instagram provide itself.
Music apps especially went downhill, spotify and tidal etc need to offer apis so we can integrate several sources in one app. They used to offer much more. I was able to import my library into spotify once (thoigh it could only hold 10k item back then). I want all my music in one place, not 4 apps
They don't offer APIs precisely so that you can't integrate several sources in one app.
I have Gonic (a subsonic server) on my home server and my client is a perl script. It basically allows me to search for an album, present a prompt for me to select the best match, and then builds up a playlist for the tracks to pass to MPV. That’s pretty much all I ever need. I would gladly dump the whole spotify client if they had an API to do the same (even if the queue is a long stream of data instead of tracks).
Many of them have been reclaimed. Check out the "awesome self hosting" GitHub repo.
Podcasts: audiobookshelf
Music: 500 different subsonic clients, many of which are good. Or some fun tuis
Feed readers: lol, more than there are grains of sand in Torvalds' flippers
Note taking: again innumerable, also, just use nvim or emacs of course
Chat: tons of very good self hosted options that can save orgs thousands a month.
Rather than build your own from scratch, rediscovering already solved issues, why not contribute to or fork a FOSS project? LLMs make it easy easier to get up to speed on large projects
Audiobookshelf is a web app! Like, if you had a good TUI music player, I don't think you'd be rebutting my thesis here. I don't doubt anybody's ability to build TUIs.
The point of the post is the emacsification of the native macOS (and Windows, I assume) environment. Totally reasonable not to care that it's occurring, that's not really responsive to the post, is it?
I was responding to your comment that nerds should reclaim software that's overwhelmingly professional and pre packaged by sharing that there already is FOSS software for the categories you listed, which imo represents nerd reclamation.
Audiobookshelf has a native android app, not sure about desktop, I only use it on Android.
Anyone can build a TUI sure but why try to rebuild the whole mpd client/server stack that lets anyone on your network play music from the several TB collection of FLACs on your NAS? Same for subsonic, why reinvent the client server protocol there when it's already solved? And for subsonic clients, why reimplement streaming, offline downloads with de-duping, stream bitrate, album / artist handling... If there's something a subsonic client doesn't have that you want, fork it, point claude at it, done! That probably falls within the emacsification thing, right?
https://github.com/awesome-selfhosted/awesome-selfhosted
I'd add Email to the list.
Email is right there waiting for disruption.
Google wave rides again!
I'd say the thing with email that most improvements would need improved standards?
That said, as with the emacs user example, the ability to automatically process all your email in madly custom ways can now be opened to the masses.
Can you elaborate?
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
There's something about this whole situation that rhymes with the issue of LLM-generated prose. It's not that GPT 5.5 writes bad prose (I mean, it doesn't write good prose, but it's not awful). It's that once I pick up on the text being GPT 5.5's, my brain switches into a mode where it starts reminding me "this is just GPT output, you could just ask GPT 5.5 these questions yourself, and get answers better tailored to what you want to know". Why am I reading this one particular artifact of a conversation with the LLM? Once I know what the conversation is about, I can just have a better one myself.
Same deal with a lot of this software. I guess there's some "taste" to it, but mostly what you care about are the ideas and the "recipe".
Also, you should just do a monthly "Vibe HN" thread.
Those are great points and it leads right back to the solipsism thing. Also, you snuck a "It's not that X, it's that Y." in there. Nice.
> you should just do a monthly "Vibe HN" thread
It wouldn't stop people from feeding them into the Show HN stream, which is the problem. If we had a good enough way to tell them apart, we could factor them into two streams, but we don't yet.
> It wouldn't stop people from feeding them into the Show HN stream, which is the problem. If we had a good enough way to tell them apart, we could factor them into two streams, but we don't yet.
But it would allow for a culture to grow where the posters would self-contain their submissions into those threads.
I don't want to make this about people's faith or whatever, but to put it frankly, I've heard a lot of contemporary Christian music, I don't care for it, and [I like to think] I can reliably recognize it in three notes or fewer,¹ which may or may not bear out in rigorous testing, but saves me a lot of time either way. This feels like it parallels strongly with the topic at hand
1. erring on the side of sounding cooler
> 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.
I can install WhatsApp in a few tens of seconds. You most definitely spent more time than that writing this comment.
Would you mind sharing a video of you building a custom WhatsApp in less time? Not even starting to think about getting other people to talk to you on your instantly-built messaging solution...
> > "easier to build your own solution than to install an existing one" - or to learn an existing one.
> I can install WhatsApp in a few tens of seconds.
But do you now have an insanely deep knowledge of WhatsApp (i.e. what serious "learning" means)?
As if someone vibe-coding it has that insanely deep knowledge?
It has been 3 hours already since your comment and I have just installed a WhatsApp update and it took around 10 seconds.
We're still waiting for tptacek's DIY WhatsApp alternative since he believes that it's "easier to build your own solution than to install an existing one".
That must be one of the most silliest comments I have ever read, and the worst part is even the moderators agree with the statement.
AI psychosis is indeed real.
To be fair, I think it is true that AI will help nerds (like me) implement their own clients. Without AI, I will think that "I could make my own client", I will spend some evenings and weekends proving that I can solve the problem, and then I will never spend the time I would need to actually make it usable.
And I would love it if more services had an Open API and allowed people to write their own clients. I like the concept of "emacsification of software".
But I find it a little extreme to say "it's faster to build your own than to install an existing alternative". You still have to spend a lot of time building your own, it's just that now it's realistic without taking a sabbatical.
I think the "nerds (like me)" part of your observation is something that a lot of AI-enthusiast nerds seriously underestimate. For as long as there's been personal computing, there's been a narrative that everyone would be a programmer if we just made it easier for everyone to program, and we've seen attempt after attempt after attempt to introduce new technologies that will surely, surely, be the key to unlocking this. What we don't seem to consider is the vast circumstantial evidence that the vast majority of users are simply not interested in creating tools, automations, widgets, etc., and never will be.
For my part, I am not only a nerd, I am literally an Emacs-using nerd, and I am not interested in using LLMs to create a plethora of bespoke applications that are subtle tweaks on existing tools. I haven't ruled out using AI to assist in helping me with a program that I've been wanting to write for years, but a lot of what's blocking me on that is figuring out design aspects that an LLM wouldn't be able to help me with in the first place. (I'm also concerned about "vibe-coding" programs that I don't 100% understand, at least if they're programs that I might ever want to release into the world.)
> But I find it a little extreme to say "it's faster to build your own than to install an existing alternative".
Installing an existing alternative might be easy ... once you found the one which best (i.e. mostly) matches your requirements. The time consuming task IMO is the time needed to find and then choose between half a dozen (or so) alternatives which all might do the job ... until you installed them, tested them, and found that they are insufficient for the job you expect them to do.
> Even more importantly, what happens to teamwork?
I can concur with that thought direction. We used to pair and group-program on my team, we have a "Zoom office". Now it has become "let me take this ticket and feed it to Claude, you try the same thing with Copilot, and then we compare the results", or "I'd make a PR with my clunker, you use yours to review it". This shit honestly feels almost pointless. The pair-programming is absolutely dead. Who wants to watch me run several agents, trying to fix multiple things in different work-trees, while I'm juggling them around and fixing inconsistencies in my agents.md?
I've been pushing the idea of building a self-governing, fully autonomous cloud pipelines so we'd stop playing "stupid tokenomy" games, and it seems my management is just quietly trying to "keep it down", because I think there's a simple understanding - the moment that shit proves airworthy and actually can fly, a bunch of them are guaranteed to lose their cushy seats.
> Even more importantly, what happens to teamwork? If we are all a BBM now—or rather, if we all have personal armies of BBMs, permanently locked in a manic state, springloaded 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.
One example of teamwork is how the programmers and researchers worked together to build the UNIX SYSTEM (https://www.cs.dartmouth.edu/~doug/reader.pdf). It is not a product but an environment optimized for building tools and solving practical problems with tools written in C (while BBMs were busy with Lisp in Boston .;-)
C++ is a totally different story and you need an IDE for that.
If WASM succeeded in being the one universal ABI, it could be the perfect successor to the unix pipe for the AI age. Wasm modules for libraries, that double as terminal tools.. One could only imagine
Before WASM was the CLR.
Before the CLR was the JVM.
Before the JVM was the Smalltalk VM.
Before the Smalltalk VM was the UCSD P-Machine.
Before the UCSD P-Machine was the BCPL O-Code interpreter.
I highly agree with the pro-Lisp sentiment. The main article that comes to mind while reading this was also posted a little while back on this forum: https://isene.org/2026/05/Audience-of-One.html
Tarver's piece was new to me, and fun, and spot on. Yes, LLMs bring the emacs cruft heap to the masses. A throwaway culture on disk is a lot less worrisome than one on soil.
So cool to see a dang comment comment. Rather than moderating comment.
I wrote a little bit about my experience with this sort of stuff a little while back if you're interested:
https://news.ycombinator.com/item?id=47393437
I would add to that a few more open questions that I haven't seen addressed:
- As more engineers (and non-engineers) pick up coding agents, everyone is authenticating multiple MCPs, creating an n * n explosion of complexity that is impossible to centralise. Multiply this by the number of distinct coding agents for every platform and visibility is very tough. A lot of platforms also don't support scopes so you can't enforce safety short of a network proxy I suppose
- For non-developers mainly, lacking mental models such as <agent> for Y desktop app does not imply that there is a local LLM running on your machine. I suppose it's a question of trust and education versus starting conservative and progressively onboarding where we're more of the former.
- We talk a bit about the idea of sharing prompts but that fundamentally a prompt does not in itself contain quality. I've had internal tools I've made where it's mentioned that Claude made it when I mean, yes to a degree but I did many iterations using my own taste to refine things and held opinions about how things should operate. Giving someone a prompt won't inherently guarantee anything of quality. I often think about the idea of ie; give a screenshot of Github to an LLM but in a way, you're saying to create a clone, not of what exists today but is a dead echo of the design taste and choices made years ago that persist today. You can create things cheaply but without taste and good judgment, how can you continue to evolve it in a way that isn't like that draw the rest of the horse meme.
- I personally wonder about tokenmaxxing stories you hear about from other companies and like, logically what happens to glue roles? Does someone like a Microsoft just stack rank on token count and fire those who actually get work done? I suppose they already hollow out knowledge anyway so maybe it's nothing new.
- Definitely the thing with internal tooling where eventually you generate so much that you fundamentally have no mental model. It's fine for non-critical stuff and I'm kind of coming around to the idea that it's actually a better position to have no idea of the code and a strong "theory" of how a thing should work than it is to fully understand the code and have zero "theory". Ideally both of course.
Anyway, this isn't a comprehensive ramble but I've also been a bit disappointed that there hasn't been more talk about the second order effects. Many things can be true at once where you can see value in LLMs while still being critical of them and the whole DC situation ie; Colossus 1 etc.
> easier to build your own solution than to install an existing one
seriously?
In Emacs-land. Obviously clicking a button on the app store is easier than describing to an agent precisely the application that will solve your problem. But Emacs doesn't work this way. There's a whole subthread next to you that got all confused about this and started challenging Dan to like a WhatsApp duel or something; they've all missed this point completely.
Maybe it’s just another cocoon but I’ve been working on a framework for modular CLIs which allow different humans or agents to spin different features simultaneously but with some enforcement of shared dictionary, aliases, help, logging, formatting, semantic parsing, a few other things.
It works, it’s powerful, and certainly one way to answer the question you pose. I would argue it’s the optimal answer, it’s an answer to RPC, REST, and MCP at the same time, but it’s definitely an example of an answer and approach. In any case it is a good question and something I’ve given a lot of thought to.
Unfortunately in the age we’re in now there’s something lackluster in sharing any solution or design you have. Though the architecture and design of what I’m describing came 0% from AI everything is assumed to be and therefore unimportant? But it is the direct answer to your question so if anyone’s curious lmk.
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...>
Is you actually look at the Lisp ecosystem as it exists today (even just Emacs by itself) you'll quickly realize that none of this is true in practice. Other people have pointed this out.[0]
[0] https://applied-langua.ge/posts/lisp-curse-redemption-arc.ht...
And if then you compare it to e.g. Python (or JS) ecosystem, well. It's all very relative, isn't it?
It's not clear to me what you mean, can you elaborate?
The curse actually feels more relevant to me to ruby rather than lisp.
> But they’re hamstrung by the terminal itself, which is almost always monospaced and thus fatiguing to read.
Not related to the main point of the article, but I find reading long form vontnet in a mono font much easier.
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
Have had the same emacs setup on linux, windows and macos for 15 years. Honestly, it's the best thing in my computing life.
me too! The peace of mind of getting any computer, cloning my config and feel at home.
Paralleling Linux and MacOS is pretty simple, but the last time I tried to make the same config work properly in Windows it was a nightmare b/c of the path issues.
In the past when I've seen someone extolling Windows/Linux compatibility for something as complex as a detailed Emacs setup, they were using WSL or one of the wrappers like Cygwin rather than native Windows compiles of the tooling.
For whatever it's worth, I've always only ever used the native Windows build of Emacs, and I've never had any awful problems sharing my config between Windows, Linux and macOS. I'm sure I had to expend at least a bit of effort to make this work initially, but it wasn't enough for the process to stick in my mind, and the ongoing effort doesn't feel like it's added up to much.
(I admit it's added up to more than zero though! Keeping (require 'cmake-mode) working reliably on Windows and macOS has proven a minor annoyance, and fonts seem to require a degree of system-specific attention.)
The problem is the dependencies, getting hunspell installed and finding the dictionary files for example. I normally only get a new computer every few years and each time stuff like that is a new pain. And dont even start with treesitter, i cant compile anything on windows and always end up using prebuild dlls.
> I want my life to have as little maintenance as possible
I honestly can't even relate to what that even means. I'm a programmer - my everyday job is all about changing the behavior of computer systems - local, remote, cloud, embedded, etc. Requirements change, scope fluctuates, problem space evolves - grows and shrinks, accretion is unavoidable. I need to routinely move between language stacks, different data types, formats, CLI and web tools, protocols, paradigms, OSS and proprietary apps.
That means I have to constantly adapt, my control plane has to keep up with the flux. Automation is key - you must develop a mentality for that - every little annoyance can be and shall be automated. That is an endless, non-stop transformation of my workflow - continuous maintenance of my tooling. But that is not some toilsome, reactive maintenance.
Thinking that you're a programmer that doesn't want to constantly build software for your own sake is a delusion - it's like a cook that hopes to turn on the stove only in the restaurant, but won't touch a knife at home.
Emacs is the cook's home kitchen. I'd say there are two kinds of maintenance: reactive (fixing breakage, keeping up with churn) versus generative (shaping tools to match your evolving understanding). Programmers instinctively dislike the first and should be drawn to the second. Emacs is almost uniquely suited to generative maintenance because the tool and the work share the same substrate.
I get your complaint about Emacs specifically, it's a common: "too much work to set up", which usually means: "I don't want to invest before I get value", which honestly is not wise, strategic thinking. Treating Emacs as the universal tool for minimizing total maintenance burden over a career, over a lifetime is.
I think your analogy breaks down because lots of people don't program "anything and everything". I can relate to being considered quite an expert in certain programming domains among my peers, but there being all kinds of potential programming around me that I just don't find interesting at all.
Programming is also so much broader than something like cooking. It would be like saying that "you make your living manipulating matter, how could you not want to manipulate all that other matter?" to a chef. Their cooking doesn't necessarily make them want to mend clothes, remodel houses, devise new pharmaceuticals, etc.
Yeah, sure analogies are... well... some made up shit we use, because we have imagination. And the imagination can take you for a spin.
I just disagree with why Emacs heavy users are often "blamed" to be obsessed with their tools "needlessly". What does it even mean to desire "as little maintenance as possible"? Okay, let's say I don't use Emacs (which is like I dunno over 90% of existing programmers in the world). What, I won't be writing bash scripts for my work? Okay, maybe I really hate Bash. Python then? Lua? Perl? What the hell are we even talking about? Of course, a programmer will do these things. Every programmer does. There's not a single case where a programmer doesn't tweak, re-tweak, personalize, improve, readjust their tooling, their scripts, browser extensions, the set of apps they use. Why is it Emacs and Vim considered a "perpetual maintenance", and I dunno, VSCode is "it just works™"? That's just not true. If I didn't use Emacs, I'd be inevitably re-inventing some workflow automation in some different way. Or what, bash-scripts ain't no software?
I'd like to make some points more explicit about my philosophy.
1. Yes, everything has a maintenance cost. Some choices have less. For instance, electing to choose Todoist instead of org-mode for my todo list means I no longer have to worry about syncing, merge conflicts, or whether the mobile app I've chosen fully conforms to the spec (well, whatever attempt at creating a spec existed at the time).
Of course, I am paying a very literal cost for convenience, and offloading maintenance to the Todoist engineers.
2. Emacs is a cool piece of software, and I am glad others have figured out how to leverage it, in such a way they have a configuration for life. I spent a lot of time marvelling over the set up that Protesilaos had for his writing [0]. It just wasn't for me.
3. For Emacs, if I want to use it like I wanted to, I have a couple of options. Install a package like Doom Emacs, which gives me most of what I want, with a whole lot of cruft I don't. And I have to keep that up-to-date, and worry about random community plugins breaking. Or figure out what set of plugins (after first picking a package manager) to incorporate. Or figure out the Elisp to do it myself. And my writing config would differ from my software engineering config.
No shade on the people who want to do this, but I just... don't? I can use Zed, or VSCode, and I'm 90% of the way there. Install (or configure) the Evil mode equivalent, and I'm happy.
4. One of the smartest engineers I worked with couldn't touch type until about 20 years into his career. The idea that everyone is ricing everything they do, is unrealistic.
[0]: https://protesilaos.com (purely for the emacs, not anything else there)
[1]: https://bphilip.uk/blog/2025-03-09-chase-bank-sync/
To summarize: your claim is that choosing to spend your energy on anything other than your emacs setup is a catastrophic failure in terms of ROI, a delusion, and a sort of dereliction of identity as a programmer. My rebuttal: dude, relax.
Are you even reading what I wrote? What's with the childish tone, someone dropped your keyboard rate when you're a kid or something? Emacs is a tool, not a religion. There are plenty of talented, accomplished programmers who can relate to what I said, and never even used Emacs. There's no "Emacs setup" for me, just like there's no "ricing my browser" - I do expect my web browser to work exactly the way I want (or at least as much I can get out of it) - that requires managing extensions, keybindings, extension settings, security options, disabling some annoying features, etc. It's an instrument, and requires the same type of "maintenance" and tweaking. Sure, it might not be as constant as for Emacs, but after all - web-browser is a targeted tool, Emacs is a universal one.
Whoah, whoah, whoah, you two, this is a happy post, not an angry post. Nothing to get wound up over! Part of the point is that you can both just go and do you!
We're not fighting, we're just "emotionally explaining things to one another". That's what my wife says to calm our dog, when he makes a concerned and scared face over a regular, non-confrontational conversation. Just to be clear, I'm not comparing you to our dog, I just thought it's a funny anecdote.
"Emacs is a tool, not a religion" yeah that's my point. You framed not investing in it as a delusion. We can all agree on the importance of tooling. I am responding to the tone of the sermon you wrote.
Like the cartoon character once said: "Yeah, sure, I mean, if you spend all day shuffling words around, you can make anything sound bad"... Re-read again what I wrote. Specifically about delusions. I can't believe I have to re-quote myself just to prove you my point about something you just made up in your head.
I'll re-quote it for you:
> Thinking that you're a programmer that doesn't want to constantly build software for your own sake is a delusion - it's like a cook that hopes to turn on the stove only in the restaurant, but won't touch a knife at home.
> Emacs is the cook's home kitchen.
The two sentences are adjacent. I read them as connected. If you meant them to be unrelated, I hope that this sheds light on our disagreement.
How often do you fish out a single word in a paragraph that has no semantic, emotional meaning to you personally and automatically flip the entire book, just because of one word?
What I meant is that viewing Emacs merely as a means to achieve a singular goal and to extract specific value (e.g. "I've heard Magit is nice") is shortsighted - approaching it as a strategic, long-term investment yields far greater returns. I'm not preaching for absolutely every programmer to use it.
Come on, now tell me how I think of everyone who doesn't approve my web-browser tweaking habits as "catastrophic failures"...
Hmm, not quite an apology, but sort of a tacit acknowledgement that what you wrote wasn’t quite what you meant. Good enough for me.
You keep doubling down on your own perverted reality you composed out of thin air and somehow I have to apologize? Can you be I dunno, less emotional and more substantive? There's no controversy in what I wrote - it is pretty simple and straightforward:
Programmers write programs. That's the definition of the job. Any personal tweaks - scripts, snippets, extensions, packages, configs (for VSCode, IntelliJ, Vim and yes Emacs too) are also programs. Saying: "I don't want to maintain my programs" sounds to me like saying: "I don't want to be a programmer". It doesn't matter what I use - Emacs, Sublime or Macromedia Dreamweaver - configuring and maintaining it is not "kind of a job", "part of my job", or "someone else's job". That is my job as a programmer. Period. End of discussion.
Why the fuck you keep pouring your own made up shit from one pitcher into another, thinking it's about to turn into gold, is beyond me. And somehow I'm the dude that should "relax". Well, sure, let me then apologize for my inability to explain to you something that a six year old would get off the bat.
Now allow me to explain to you kindly, why you're fucking wrong here. You probably have no idea how difficult it is to write anything meaningful in English. Especially these days. For someone for whom English is not a second or even a third language, it can be an enormously hellacious ordeal. I take pride in my English. I think it's quite possible I would never write so colorfully in any other of the three languages I have. For me, each paragraph has meaning, has voice, its own character. It takes time to write. It takes patience, humility, imagination. Machines can do it already, but their language still lacks something. Something ephemeral. Something that would make us watch for two hours, humans doing crazy acrobatics of Cirque du Soleil. I wonder how long would we watch robots doing the same? Well, who knows, maybe we'd be watching robots dancing for two hours. LLMs are getting better with languages too. Which makes it more difficult to write. Properly structured text gets blamed for being generated. Sometimes I deliberately don't fix mistakes, even though it makes my eye twitch. Darn, I'm so pissed I can't use em-dash anymore, goddammit.
I don't owe you an explanation why I do it, why write anything at all. Why HN. I'll say it anyway. I do it because I still recognize people here. Living, dreaming, learning, fighting, hating, daring, loving people. I don't get paid for it, I don't seek recognition, I am not trying to build a name. I share my opinions because nothing is more important for our species than storytelling. And we need to share stories, listen to them, re-live them, learn from them. That's why many of us would go to watch Nolan's rendition of a 2700-year-old story. Even if we don't like the movie already.
And then someone like you comes, shits all over your charming writing, compelled to do it just because they see a word they don't like. Well, honestly, fuck you. Yeah, not nice, but I'd rather be kind and tell you the truth. You wouldn't be saying the shit you replied to me with to my face. Not because I have muscles, or am intimidating, or weak and miserable, no. But because you're definitely not a jerk, or an idiot. I wouldn't have to spend hours wasting on your ass for no good fucking reason. Seriously, I am a solo father with two kids, it's fucking 1:30AM and I'm having to deal with this shit, because writing for me is still fucking hard. English is beautiful, but hard. Come on, kid, think sometimes. For the sake of fellow humans.
> I want my life to have as little maintenance as possible, and making my own software for everything isn't always compatible with that.
So LLMs are good enough to make personal software, but not good enough to maintain them?
It's usually easier to build something that maintain it for extended periods of time, particularly if that maintenance requires adding new features.
Less about the capabilities of LLM software, but more about my willingness to spend time to deploy them, debug them, etc.
I don't want to spend time on dealing with change. Hence why I'd rather purchase tools, where I pay for the developer to a) prepare for any maintenance, and b) will perform the maintenance needed.
(Of course, the maintainability of software with current generation LLMs depends a lot on how well your architecture them. I've got pure vibe coded slop, that can be very difficult to wrangle.)
> So LLMs are good enough to make personal software, but not good enough to maintain them?
I mean... yes?
Maintaining software means looking at issues opened on github, keeping your own list of feature requests and bug fixes, deciding if and what to fix, deciding when to fix, and if you're lucky/cursed, reviewing PRs from randos. ANY of this means diverting attention from your day job/client work/kids/???.
Can some of this be theoretically automated by an LLM? Uh, maybe? But I'm not sure how much that would help.
“Those who say they lack time to build tools are precisely the ones who cannot afford not to.”
"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.
The road not (yet?) taken is the full flowering of the HyperCards, the Visual Basics, the Macromind Directors and Flashes...
That is, the idea that a non-expert might create interesting software in an authoring environment with good, well-thought-out building blocks and easy-to-grasp metaphors, shorn of layers of accidental or over-engineered complexity.
In this vision software still requires careful logical thinking, but it makes it much less cumbersome to translate that thinking into running code, with no tooling and build system nightmares.
Instead, we've invented such powerful models that they can regurgitate and recombine complex incantations on our behalf. The complexity is still there, though, and it's still inscrutable to non-experts.
But maybe they can help us eliminate some of it?
I think that path is still possible, and it may even nicely complement the LLM world, where LLMs help generate software that individual humans can still easily comprehend and manually modify.
I have told this to many friends who scoff at me, but using a computer is very clearly going to also mean "having the computer create programs for you". We won't even think or know about it.
To me, it isn't a matter of if, and the matter of when is also very clearly in "at most 10 years, probably much, much earlier", given that I have relatives already doing this without knowing how to code.
This is a future of computing I am absolutely in love with, and is so incredibly empowering!
> We're not there yet but with LLMs we're getting closer.
I feel I'm there. Whenever I have a problem I definitely ask "should I vibe code an app for that?"
My current Swift app has 15K LoC (5K in tests, 10K implementation) and it is finished. Like, there are minor improvements now, but it does what it needs to do. It took me 20 hours. I think the actual thing would personally take me 500 hours as I haven't programmed in Swift.
My fears with the situation you are describing is that we end up without a common file format, if everyone has a propietary app and/or file system then that makes transition or collaboration a pain.
We probably won't end there due to how lazy most of us are, but it's certainly something to consider
I feel like I'm way more cynical than most people around here about LLMs but if we accept the parent comment's framing, why can't we just use an LLM to write a throw-away converter to whatever new format is necessary? Yes of course it'll probably be lossy occasionally but the question will be, is that ok for the user doing the conversion?
That's going to be huge thing in the future I think
Everyone having their own hyperspecific apps or even different UIs/visualization in the same app
The whole idea of an application becomes a much more fluid thing
If your app is built with a dynamic language why not let users re-write the code themself and add whole new features
This is why open source has been great and will only get better
LLMs are great for problem exploration. Especially with the decline of Google I think we're at a point where it's less difficult to get an LLM to spit out something that'll accomplish a task sorta compared to actually finding that on the internet. But if the task is going to be repeated or modified then I think LLMs are at a permanent disadvantage to prebuilt software. Even if that prebuilt software is just someone else running an LLM and then passing the output through acceptance testing most people just don't want the headache of debugging weird edge cases and the novelty of "I'm a developer too!" wears off pretty quickly.
I'm excited that the weird grey-zone of excel sheets with business critical logic is likely going to disappear as LLMs slowly make the logic driving those too complex to be comprehended and managed and those get foisted off onto actual engineering resources. It'll be painful but probably for the best... but for actual tools people need to use day-to-day I think the assurance that the tool will work has a lot more value than the AI hype has comprehended.
> Especially with the decline of Google
Oddly enough, Google’s LLM is the only one that has been answering my questions well on a research project these last weeks. I’m getting information from scanned text files that exist on the internet but were never adequately OCRed by other LLM companies (i.e. both OCRed at all, and moreover OCRed as the specific language in question that picks up all the diacritics). Google search results may be disappointing and polluted for years, but the company is still offering a useful product in another tab of its interface.
> Oddly enough, Google’s LLM is the only one that has been answering my questions well on a research project these last weeks.
Google Search declined in quality when results started containing more noise (more ads, SEO spam) that required sifting through. Gemini isn't displaying all that garbage.. yet.
I've found Gemini to be very helpful in figuring out all the fiddly linux problems that used to require reading endless forum posts and digging through docs.
It’s exactly what I use LLMs for as a non-computer professional.
> It was imagined that programming would become easy enough that anyone could learn to do it.
Arguably LLMs take us further away from that than we've ever been. All they do is automate copying and pasting in shit from StackOverflow.
We were closer to everyone being able to learn how to program computers in the mid-80s when everyone had one and they started up with a BASIC prompt.
Ah yes, the 80s, when everyone had a computer.
Well, yeah. The home computer revolution.
Literally everyone had a ZX Spectrum, or Commodore 64, or a BBC Micro if their parents were rich and thought that having the same as they had at school was a good idea.
If you change "literally everyone" to "a minority" we can agree.
Well, no, because it wasn't a minority.
They were cheap and ubiquitous, unless I suppose you were in one of "Iron Curtain" countries.
A quick google query says 15% of US households own a personal computer in 1989.
Okay, well, it was far more than that in the UK and Europe.
I suppose it's a bit like television, it would have been more popular where it was invented.
Around 5 million ZX Spectrums were sold between 1982 and 1992. If all were sold in the UK (they weren’t), that would put the penetration around 25% based on the number of households in 1990.
One specific model of ZX Spectrum, which is one specific make and model of home computer.
Did you live in the UK in the 1980s?
My house did not have a computer in it until 1992. I knew many people who did not have a computer in the house in the 1980s. Computers were expensive!
Even in the early 80s they were 100 quid, that was nothing.
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
You mean no gatekeepers besides whatever the people who build the UI applications decide the limits should be.
The author highlights an interesting point. There are a couple variables in action:
A- The difficulty to publish the tool
B- The difficulty to create the tool
C- The usefulness of the tool to others
D- The social reward for publishing the tool
E- The negative incentive of adding a dependency
Difficulty to find a canned solution goes up with A (because someone needs to create it) and B (someone needs to figure out how to publish it), but, the more useful it is to the community (C), the easier it gets to find it, because people will tell you.
If A and B are substantially different, if A is much higher than B, people will tend to write their own and forget about it. If B is lower, there will be fewer solutions to your problem. If A and B are low, and the social reward (C) for A is higher than the price of depending on something else (E), you'll have a leftpad situation. A lot of NPM is made of packages with high C and D and low E.
In the case of Emacs Lisp, A used to be high, but now is low, B (once you climb the learning curve) is low, C, D, and E aren't high either way. This can lead to a scenario where you build the tool before you even look if there is a tool that does it (unlike it is with VSCode, and with Eclipse before it - both have a high B).
I see a thesis someone younger than me will want to bring out to this world.
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.
Yes. You can do that. It works right now. It works really well.
My original spicy take is: why learn SwiftUI at all at this point? It's a skill that, for most tasks, falls into the same kind of bucket as "learning Microsoft Word really, really well". I appreciate people who take the time to do that, but the outcomes are within millimeters of each other whether or not we do that.
I don't think that's true of programming generally. But I think there are languages now where the rationale in specializing in them has gotten, hrm, more complicated.
I’m a SwiftUI developer at $DAY_JOB so maybe biased but while Claude can make things that look right it’s still not exactly perfect. Especially from designs. I used Claude design to mockup a monitoring app for my talos cluster and Claude code totally freestyled it. What should have been as simple as `List { Section(“title”) { … } }` got morphed into whacky DIY `VStack {}.background(.gray)` nonsense.
It looks off and it’s suboptimal performance-wise. It was, I’d say, 80% of a proper SwiftUI app (which is really fantastic given it was basically a one-shot).
Actually knowing SwiftUI meant it was trivial for me to just close out that remaining 20% by hand and have an actually *nice* cross platform (iOS, iPadOS, macOS) app.
I’m sure I could have prompted it to get it done right but without proper knowledge on the subject I wouldnt even know what was wrong and Claude doesn’t do so hot with “that just feels wrong”. Beyond that it was quicker to do it myself, but maybe I just need to prompt better /:
I have absolutely no doubt that an experienced SwiftUI macOS developer could easily produce better UI than Claude can today. The thing is, Claude produces better UI than a replacement-level macOS developer can, and, much more importantly --- this is really the core of my argument --- \infty better UI than a typical developer can produce, because most developers don't ever build native UI.
If I'm shipping a product where each development/release cycle costs my team $5MM, I am absolutely going to spring for the professional SwiftUI developer.
But most things normal developers build in their spare time don't even cost $50 per cycle. Unless they're UI learning projects or projects by UI experts, there is no "budget" for UI. At best, for real labor-of-love projects, you get a TUI where the developer spends 5 hours of their life that they will never get back creating a 70%-functional terminal version of the affordances the native UI toolkit provides out of the box.
That's all over now. However competitive Claude-generated SwiftUI user interfaces are with expert SwiftUI projects, they roflstomp the UI options available to most developers. I can't say enough what a smoking gun the flickering Signal app is here!
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.
I'm the same.
In all honesty, when you start up emacs for the first time with a blank config, it looks terrible. But then you start building it up with plugins and adding code to support your own quirky workflows and slowly it becomes too powerful in your life to ignore. I have not been able to drop it for 13 straight years. With AI taking over the development experience, emacs and neovim have only become even better, because now you can get AI to bake your custom workflows into the config for you.
Emacs/neovim should be the gold standard for all workflow tools.
I'm currently polishing one of my packages for publication, and for that do a lot of testing in a vanilla Emacs. It's shocking how many of even (to me) absolute core functionality is actually customization I did a decade or two ago, and then forgot about.
I did the same. I started with Doom Emacs and then a year later decided to start from scratch and build the computing environment I wanted. But I think the experience of Doom showed me what was possible, what I liked, and what I really had no need for.
I make small config changes every day and its super fun to use my computer this way. I wish everything was configurable like Emacs.
It is! That's the post!
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
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).
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.
Maybe it's a good idea for SWEs to consider using LLMs to train themselves into new careers -- just in case.
Most other "knowledge" professions -- by which I mean teaching, programming, some engineering, and the arts -- are even further along into obsolescence. That said, you can still use the knowledge gained in a knowledge profession to convert into a more hands-on profession. We might have a bit longer before humanoid robots destroy all hands-on job opportunities as well. Once that happens, every person will be equally poor and destitute.
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
"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.
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
This really resonates with me. The ability to quickly writing one off, personalized apps really seems to be the strong suite of GenAI.
A month or so ago, I had claude write a visualizer for some data. There is an existing python viewer, but it bogs down & is painfully slow at the scale I need. So I asked Claude to port it to a compiled language. After 2 hours of iterating, I had the tool that I wanted.
Note that its throwaway, dumpster fire code. But for a one-off tool like that, its fine.
Ehmm, weird, I can't be the only one in the room. You guys didn't know about gfm and gfm-view Emacs modes?
> Ehmm, weird, I can't be the only one in the room. You guys didn't know about gfm and gfm-view Emacs modes?
I'm using Emacs since last century and I've got 3 000+ lines of custom Elisp code I wrote (with maybe only a few hundred lines copy/pasta'ed from other configs).
I'm always using a recent Emacs compiled from source and now with LSP, org-mode, Magit, tree-sitter, ivy/avy/counsel/swiper with ripgrep (thanks burntsushi) integration etc.
I had zero frigging idea what gfm and gfm-view for Emacs were.
But I'll look into it now!
I know, right? You'd be like "using Emacs like a boss", going with your keyboard "frrrrrrrr" (well, no, that's not Emacs, Emacs would be like "C-c C-c C-c C-c C-x 8 and only then frrrr"), managing entire k8s clusters, building it from the source using most esoteric build options, --with-fries-n-ketchup, and all. And then some jerk comes out of nowhere and tells you about fancy-pangolin-mode that's been sitting quietly in core Emacs since the Prohibition and you're like: "goddammm... I've been using it wrong, my life is meaningless..." :) We're old people. I mean, an eleven-year-old who opens Emacs becomes old in an instant. We have invented doom-scrolling. We've been going through the M-x menu way before twitter and reddit made it a thing.
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.
markdown tables are the only thing that's really rough to read, IMO
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'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.
Which is where the "emacsification" analogy breaks for me.
The reason people who like emacs write their one-off program in emacs is that it is an extraordinarily introspectable and debuggable programming environment. There is no "code, compile, run" loop - you just write code against the live running environment. Devoid of that fast feedback loop, writing code just isn't as much fun.
Well taken, but for MANY years, I copied and pasted elisp snippets off stackoverflow without understanding any of it. And to this day, there as many xkcd-style "space heaters" as there are emacs users. OP's point stands that LLMs make possible a new generation of quicker, dirtier hacks destined for the cruft heap.
What were the three?
Not OP: - One shotted script that I schedule through cron that sends me a message when a new one piece manga chapter releases. - Also a simple script that moves my cursor one pixel every 30 seconds. Cannot disclose why I need this.
>> Also a simple script that moves my cursor one pixel every 30 seconds. Cannot disclose why I need this.
Hehe. Definitely not to avoid the company micro time tracking their employees.
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.
> 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.
> Uploading costs you nothing, and it can help the poor.
Could you expound more on this? Are you suggesting that less energy use in data centers would help the world's poor?
I read the suggestion as being that the world’s poor aren’t paying for AI tokens (or subscriptions) to generate software from prompts, and that sharing the _output_ is more beneficial to people. The reduction in energy waste is secondary, and benefits _everyone_.
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.
The point of the article is that the whole gestalt of what you do on a computer is now one big programmable surface, and in that regard everything feels a lot more like Emacs.
It's not "about" Emacs, it's more about the vibe of personalized software in 2026 to someone who does a lot of Emacs stuff.
> whole gestalt of what you do on a computer is now one big programmable surface
Emacs-effect. Use it long enough and everything becomes "one big programmable surface". I've been in that modus operandi for years. Emacs is my "control room", I don't necessarily do everything in Emacs, but for sure it converges all into it - everything flows through Emacs. I control my WM directly from the REPL inside Emacs. I can grab a content from a tab in my browser - I have access to my browser history, and all the tabs, I can switch to any tab, close and re-order them. I can grab a text selection on the page, I can extract entire readable corpus of an article while ignoring all the irrelevant fluff - banners, ads, buttons, etc. It works even for js-rendered content (React, et al.). I play all videos controlling them directly from Emacs - even though the video itself is playing outside, in mpv. I still can pause, change volume, fast forward, speed-up, extract transcript, etc. All without leaving Emacs. That's pretty useful when taking notes. I can grab any text I see on the screen. Even if it's in Slack.app. Why, If I can read it, there's no reason why Emacs shouldn't be able to. I can grab any region on my screen with Flameshot, it goes through Emacs, runs tesseract and OCRs the text out of it. Useful when someone's screen sharing in Zoom. This was all possible before LLMs. Now, LLMs running in Emacs can do some crazy, wild stuff.
Wild!! Would love to look at your .emacs.d configs
mpvi [1] is the video control part. I have only used it a little bit but it is incredibly good. Control the playback completely from Emacs and quickly make timestamped org notes.
I don't know what the other parts are. Curious to learn!
[1]: https://github.com/lorniu/mpvi
Sure, but it misses interoperability, which is the point of Emacs for me. That's my point.
Not really the same. Emacs focus a lot on compatibility and common modules (even if there may be some different takes on those common things). So you got big systems like helm, consul, ivy, company,… and the. everyone building on top.
Another thing is configuration (which also ties to the previous statement). You have to be able to split the idea of the program (what it aims to do) and your personal preferences. Emacs make that easy by having a framework for user preferences. That makes for an extendable program.
The closest, but not as user friendly is unix and suckless philosophy combined. Small programs, easy to understand, configure, and extend.
OP is trying to say Home Depot let normies do their own small repairs, and you're protesting saying "No, no, that's not how we pros do it."
Normies can do their own repairs when they want and how they want. But I was just pointing out a difference in behavior, not the true way of doing.
The article provides an analogy, it doesn't tell you to do anything with Emacs in particular.
Besides being an everything app for you, Emacs is an (unconventional) operating system with weak boundaries between user apps. It makes it easy to modify anything, write new things, or combine two existing ones with very little code, something that e.g. Microsoft could have only dreamed of in Office with its awkward embedding that barely worked. Emacs is one the few survivors of the idea that users should program what they need, which was popular during the personal computing revolution in the 80's. Two others are spreadsheets and BASIC.
Programming turned out to be too complex for the untrained users to handle, but AI makes the idea of custom one-off apps or weird hybrids pretty damn close, that is true in practice. I see a lot of people that vibe code their own little things to get things done. That's precisely what BASIC (often shipped in the stock ROM!) was supposed to be used for.
Same thing, actually, I think.
I think that "the number of programs" you're suggesting is arbitrary. It's kind of like calling an operating system one thing, when it's a lot of things. You can "count" the things different ways.
The bigger takeaway is "making your own programming things."
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.
> When my Emacs opens a markdown file it immediately converts it into OrgMode format.
I want that. Can you give some details?
A search finds modeverv/markdown-to-org which looks 80% there but activates based on a yank or converting an already loaded markdown buffer. Perhaps it can be made to apply on opening a .md file.
I know, right? Org-mode is soooo much more practical. imenu works great, sparse-trees are awesome, you can edit pretty much any part¹ in an indirect buffer and all. These days I try to consume anything that can be fit into an outline, in org-mode - hackernews², reddit³, slack⁴, jira boards and tickets⁵, wiktionary entries⁶, etc.
Fun anecdote - I once needed to sort some nested items in a big yaml file. After spending three minutes trying to understand sort-regexp-fields (or some other function), I cheated - I ran org-mode, and then org-sort and then went back to yaml-mode. So stupid, yet so brilliant. Why the heck would I ever want to use "first-class IDE" or "intuitive, plebeian editor" if Emacs has anything I could possibly imagine? Right at my fingertips.
___
¹ https://github.com/agzam/org-edit-indirect.el
² https://github.com/thanhvg/emacs-hnreader/
³ https://github.com/thanhvg/emacs-reddigg
⁴ https://github.com/agzam/slacko.el
⁵ https://github.com/agzam/go-jira.el
⁶ https://github.com/agzam/wiktionary-bro.el
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.
I've always found it easier to collaborate using markdown. It's much more popular than org-mode! And you can get org to export text as markdown, so interop isn't necessarily even all that difficult.
And as per the general theme of the post anyway: whatever. Because you can just work around it, whatever it is, by cobbling together some code, one way or another.
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.
> 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.
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.
Had somewhat related thoughts on this here: https://news.ycombinator.com/item?id=48035796 (Most vibe-coded tools are not for you)
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?
If you’re building for the "love of the game", aren’t you unlikely to post an artifact that is produced towards the end of your project and targeted towards a publication (e.g. hacker news)? I recall Mitchell Hashimoto was saying he used to browse GitHub as if it were a social media (which it is) - perhaps that’s your jam.
Speaking of which, Emacs’es markdown-mode is pretty good. :^)
Emacs is an editor! God help you if you do something to my computer where when I click on a Markdown file something changes in my Emacs window setup.
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.
If you were building it for yourself would you ever chose Electron?
Merely an example but I would not, one of my gripes with LLMs is the training on general sentiment and trends, so they tend to recommend whatever is popular.
This is an article about nerds writing nerd software.
> 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
There's a reason we're not reading monospaced here, and a reason we do read monospaced code.
But the beauty of this moment is that if you want a really good SwiftUI monospaced Markdown reader, you can have it before dinner. This is exactly what I'm talking about. You have an idiosyncratic personal preference, and it's now reasonable to expect software to shrink-wrap around that preference.
Generally I just don't appreciate when someone jumps from "I care about this" to "everyone cares about this for obvious reasons." Focus on what something means to you, and being sincere about it. But that is just my advice for writing, take it or leave it.
Also, are browser text area inputs monospaced by default for everyone? Or did I configure that for myself long ago and forget? If it's not just me, maybe the "reasons" you're alluding to are not so obvious. Anyway, I have no trouble at all reading the long comments I type into text areas.
And more power to people for embracing agency :)
There's a reason we're not reading monospaced here
You underestimate the number of HN users who are reading this site in their terminal. ;-)
I get 429s all the time trying to read this site in lynx or any non-mainstream browser (w/o JS).
I'm genuinely surprised by the monospace cheering section!
Hello from eww
> a reason we're not reading monospaced here
Legacy decisions as a remnant from a time when taking more space on paper cost pages and therefore resources, remaining as a default from centuries of inertia in how text is printed?
No, prose set in monospace is harder to read. The "legacy" is monospace! We went way out of our way to to get proportional typesetting working.
But seriously: you do you. There are people who code in proportional typefaces and they're as baffling to me as you are right now. Let a thousand Markdown viewers bloom.
> The "legacy" is monospace! We went way out of our way to to get proportional typesetting working.
The legacy is proportional, at least in Latin script and its ancestors. Handwriting was proportional, of course, and so was Gutenberg's printing press. Books and newspapers have virtually always been printed in proportional type.
In Chinese and Japanese, monospace is legacy in both handwriting and print... and also still universally used today. All Chinese and Japanese text is monospaced by default. Billions of people are getting by just fine reading monospaced prose.
I don't really know where this conception that monospaced is somehow objectively harder to read is coming from. Actually, this is the first I've ever heard of the complaint. I can't help but wonder if you've been subjected to some very bad monospaced fonts in prose or something.
Monospace text is objectively less dense, which means you have to move your eyes more. Every eye movement is an opportunity for error. Monospace text only makes sense when seeing exact character counts matters (which it often does in computer code).
One could argue that less density, as well as standardised widths, significantly reduces opportunity for error compared to cluttered text that is constantly varying how it is displayed. Perhaps moving your eyes more increases opportunity for error by 10% but easier-to-parse characters decreases the opportunity for error by 20%?
There's limited research on readability of monospaced font. But this study suggests monospace is weakly more readable than variable-width font:
https://dl.acm.org/doi/epdf/10.1145/2897736
Surprised that Monaspace hasn't been mentioned below.
https://monaspace.githubnext.com/
Turn off syntax highlighting for your code, translate it to COBOL, and pass it through a formatter that converts it to continuous word-wrapped text. Then we’ll talk again.
I have written multiple books entirely in LaTeX edited with neovim. So... your point is not taken.
I'm a fan of your writing, all the more because you've somehow managed to do all of it in monospace. :)
Authoring is different from reading.
And why did you author them in LaTeX if you think reading in monospace plaintext is fine for everyone?
There is a real use case for a viewer if you have a lot of formulas. Yes you can read the raw latex but you go cross-eyed after a while. Maybe I am a softie though.
I agree, but I don't think the author of this blog post is coming from that perspective, and markdown renderers of the sort described in the post tend to do pretty poorly with math typesetting.
The dislike of code per se is what drives these people to use agents in the first place.
Nothing personal but I hate this take with a passion, and I literally think it's representative of the worst attitude in computing because it's the literal opposite of software SHOULD BE.
The whole entire point of computers in their best light is changeable software, the whole point should be "let people read how they want to."
Any good md viewer and open to customize some formatting to pdf?
emacs + pandoc
Prescriptions include lisinopril 20 mg, amlodipine 2.5 mg, metformin 500 mg, and aspirin 81 mg.
I came here to recommend Marked: https://marked2app.com
But...I like MDV.
Emacs was the first vibe-coding.
It was also the most prominent ecosystem for "software-for-one". Lots of custom-bespoke, "it works for me" packages that were only created for personal use.
I just use Silverbulletmd...
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.
> 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.
The post talks about this.
The post talks about it as a good thing.
"With LLMs you can just make your own".
I read dogleash's comment as emphasising the bad parts of that. If everyone's just sharing their half-baked slop, it becomes harder for people to discover the good programs which are worth using, and harder for those quality programs to get social proof (or good direction).
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.
Seriously, your idea here is maybe you can start an Emacs vs. vi fight in the comment threads?
No one mentioned vi, I like neovim just fine, and I'm using pi daily. Nice try though. My only point is that if you want to talk about rewriting everything yourself, NIH, churn, whatever you want to call it, Emacs is absolutely not a great example.
Are we reading the same article? OP is saying LLMs let normies tweak their personal workflows in the same way we emacs nerds had been doing for decades. Contrary to the old saw about it being an OS, Emacs is really just a shell but with lisp as its command language instead of unwieldy bash. Once Claude magicked an English to bash translator, raw shell has caught up to emacs in its ease of use.
The new thing where everyone just vibe codes their own versions of everything is not at all like personalizing Emacs.
Specifically the idea that people generally just ignore existing versions of packages and make their own has never been the case, especially compared to other editors (even VSCode).
> There are popular elisp packages lots of people use. But except for Magit, nerds are alarmingly apt to replace them with their own shinier versions (and then to show them off, transitioning to the spore-forming phase of the elisp lifecycle). Everything in Emacs is malleable.
> Until now, the Achilles heel of Emacs culture has been that, except for Magit, its packages tend to be wretched user experiences. Ugly, slow, and discoverable only after inflicting years of elisp cortical injuries on yourself.
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.
Setting aside the fact that good content is more enjoyable than bad content, experiences are meant to be shared. Humans are a social species, and a very large part of media consumption goes beyond the actual consumption and into sharing that experience with other people. People build communities around the media they like, and even integrate their favorites as part of their identity, wearing branded clothes or cosplay, decorating their rooms with merch, setting wallpapers, and so many other ways to signal what they enjoy to others. "Content creation for one" rather misses how humans work. Heck, not only media but even tools are subject to this -- people legitimately make emacs or vi part of their personality.
> The entire economic model of content creation and distribution is going to explode in the next 3 or 4 years
I think this is also inherently self-contradictory. What's the point of distributing content made for one? This gets into the same fallacy that people engage in w.r.t. "applications for one" displacing software developers. Yes, LLMs can pump out buggy software that suits one person's needs, and it doesn't need to be reliable enough to deploy at scale. It serves real utility here, because there was a gap between "the value of such software" and "what software developers are willing to work for", which meant that this software wasn't being created because there wasn't economic value in it. But then, how does one suppose software that has no economic value is going to replace all the professional software developers who were being paid to produce software that has economic value? LLMs filled a gap software developers weren't being paid to do, but given that they were not paid to do it, their jobs are not contingent on the existence of this niche. It simply doesn't follow that being able to produce content with zero economic value, whether that's applications or content for one, will cause an 'explosion' in the existing economic models.
I think that software made for one fills a similar niche to ultra-processed foods — many of which were created to supply soldiers with sustenance in an active war, and continue to fulfill the needs of their consumers (travelers — who might not have the time or space to practically prepare a home-cooked meal, working professionals — who similarly benefit from less planning and food preparation), but as research has evolved, society has realized that these meals are linked with metabolic disease and adverse health outcomes.
Applications for one, might serve as a sort of "ultra-processed software" that can fill useful niches like generating textbooks on the fly (https://news.ycombinator.com/item?id=48130679), generating focus oriented music for long study sessions, and obviate writer's block.
However, I feel like there are downsides that are both obvious (insularity, discoverability, reliability, and platform dependance) and non-obvious issues which will take time for the public to determine what they are.
I'm with you on purpose-built disposable tools, but who wants to read a disposable book, or watch a disposable movie?
Not me. I'm enthralled by what this moment promises for building software, but I'm yicked out the same way everyone else is by generative art.
Very cool read, kudos
whoosh goes the point of Markdown over some youngster's heads
No, I don't. I don't want anything that has to do with John Gruber, ever.
I suggest you switch to Org mode, then :-)
Curios. What are you responding to?
Markdown is a Gruber thing.
but what did Gruber do?
Had a public argument with some other guys about whose version of markdown could use the name "standard markdown", apparently?