edit: typo
But...I like MDV.
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
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.
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.
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?
> 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
"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.
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.
Software production is so easy now that everything is a .emacs file: meaning, each individual has their own entirely personal, endlessly customizable software cocoon. As the article says, it's "easier to build your own solution than to install an existing one" - or to learn an existing one.
A similar analogy, not by concidence, is 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 it's fair or not, but it's interesting how mental illness comes up, given how "AI psychosis", in both ironic and unironic variants, is so frequently referred to 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).
The flip side of all this is that when production is so easy, the bottleneck becomes consumption, and sharing turns into an unsolved 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 you'd never use another person's (other than maybe as a way to get started as a noob).
The more customized these things get, the harder it is for anyone else to understand them—or to want to. This distinction is important. It isn't just that someone else's cocoon has too high a cognitive cost to bother learning it, given that you can just generate you own. It's also uncomfortable, like wearing someone else's clothes. The sense of smell gets involved.
Rather than ai psychosis, we could call this ai solipsism.
In the software realm it's fascinating to see how configuration management (that boringest of all phrases) has become 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 must be what's behind the pipe-bursting pressure that Github has been under. What a Github successor might look like is far from clear, but as a clever friend of mine points out, it's likely that there will have to be one. Projects and startups along these lines are appearing now, but we seem to be in the horseless carriage phase still.
Even more importantly, what happens to teamwork? To put it in Tarver's terms, if we are all a BBM now—or rather, we all have armies of cheap BBMs, permanently locked in the manic phase, waiting at all moments to generate things for us—how do we work together? How do these cocoons communicate, interoperate? What does a team of ai solipsists look like? It sounds rather oxymoronic.
My sense is that a lot of software teams, startups and so on, who have been on the cutting edge of AI-driven / agentic development, are currently grappling with this, and I don't mean philosophically but in very practical ways. e.g. how does my generated code compose with your generated code. With these issues, we end up giving back some of the productivity gains of generating code in the first place, and it makes sense that these effects show up more over time, as the systems being built this way grow in complexity and the maintenance/development tradeoff becomes a thing.
No one seems to talk about it publicly, though,
[editing - bear with me...]
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.
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
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.
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.
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.
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.
We probably won't end there due to how lazy most of us are, but it's certainly something to consider
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.
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?
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.
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.
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.
> 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.
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.
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.
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.
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!
I make small config changes every day and its super fun to use my computer this way. I wish everything was configurable like Emacs.
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.
So LLMs are good enough to make personal software, but not good enough to maintain them?
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."
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
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.
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.
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."
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 :)
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 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.)
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.
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!
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.
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.
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.
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.
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.
And why did you author them in LaTeX if you think reading in monospace plaintext is fine for everyone?
They were cheap and ubiquitous, unless I suppose you were in one of "Iron Curtain" countries.
(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.)
I don't know what the other parts are. Curious to learn!
I suppose it's a bit like television, it would have been more popular where it was invented.
Did you live in the UK in the 1980s?
You want a good Markdown viewer more than you think you do.
We’re all reading a ton of Markdown. It’s been the lingua franca of software development since long before LLMs. But now agents have led us into a cursed renaissance of TUI tooling, and the reading experience has become intolerable. I’m certain that at least 14% of the agita about AI code is driven by exhaustion over incessantly scrolling terminal Markdown.
There are good TUI Markdown viewers. The Charm folks built glow, which I used & enjoyed. My friend Josh built Markless, which is handsome and bristling with features, most notably a table-of-contents nav. These tools are great. But they’re hamstrung by the terminal itself, which is almost always monospaced and thus fatiguing to read.
There are good graphical UI Markdown editors. On macOS, where I live, there’s Obsidian, Typora, and Bear, my personal daily driver. Native UI Markdown editors are attractive and legible. Good reading experiences. But they’re editors. My editors live in particular virtual desktops, with windows arranged just-so, and it drives me up a fucking wall when I click a random .md file and it messes with my editing environment.
So I took a trip to the App Store, where there are in fact Markdown viewers. They’re fine-ish. None of them were good. All I want is for something sane to happen when I double click a .md file, and the viewers you can grab off the App Store do at first seem sane. It’s only after you live with them for a bit that the problems become apparent. Several of them lack text search. Some have in-app purchases(?!). I settled on one, only to discover a couple days later that it didn’t support copying text into the paste buffer. At that point, I was done.
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.
❦
It took several hours to generate a better Markdown viewer than I could find on the App Store, but only about 30 minutes of that was interactive. The rest of it was spent yelling about zoning reform on Facebook while Claude chugged away. Behold, MDV.app:
Now, I’m cheating a little bit with that timeline, because I’d done some preparation weeks before. I recruited an old Macbook to run Claude on. I set up Xcode and git. I got Claude configured, and tracked down some Swift and macOS design skills. But the viewer itself, to a viable state, better than what was on the app store: about 30 minutes.
MDV isn’t the best macOS application ever built. Or even a particularly competent piece of software (although: it might well be the best dedicated macOS Markdown viewer). But it has improved my quality of life immensely.
It does all sorts of cool things. Claude and I have cracked the code on selecting and copying text out of documents, and on finding fixed strings inside of them. Also: MDV keeps a SQLite FTS index of all the Markdown files in its (editable) history, along with hot-keyed bookmarks and a table-of-contents nav. It remembers my place, across restarts, in documents as I toggle between them. And it has fussy color themes and decent typography, which is the most important feature a dedicated Markdown viewer can have. All this stuff just works now, any time I click a .md. It’s great.
❦
Here’s how I know this is a big deal: because every time someone sends me a Signal message, my screen flickers. It doesn’t stop until I explicitly hide the Signal app, which I always forget to do until I’ve been driven 30% of the way to a migraine by subtle flickering.
This is happening because Signal is an Electron app, which means that even though it looks like a native macOS app, it’s not. It’s a whole-ass copy of Chromium rendering a secret web page. It shares this property with virtually every UI app shipped in the last 10 years, each of which carries its own flickering copy of Chromium.
Electron isn’t good. But it’s always been good enough. Building real native user interfaces has historically been a difficult problem, beginning with finding even replacement-level talent to do the work. Capable macOS native UI developers are rare birds.
But Claude isn’t just a replacement-level SwiftUI developer. Claude is actually good.
❦
This isn’t a post about the impending death of Electron (if only). It’s also not about getting you to use my awesome Markdown viewer which is trivially easy to install and better than any viewer on the app store and you should definitely use it.
Actually, no! Stop. Don’t install it. Treat my awesome Markdown viewer, which is awesome, in the same way an Emacs user treats a particularly shiny .emacs. Steal the idea and make a better one.
For those unfamiliar, here’s how Emacs culture works: its lifers build whole applications in elisp (one of the world’s great awful languages). These “applications” are always started to scratch a personal itch related to text editing, and invariably expand in ambition and scope past any reasonable boundaries of what text editors should do. If you look at /r/emacs, it’s 0% Product Hunt, 100% show-and-tell.
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.
But AI agents have fracked Emacs culture, and it’s leaking out into the wider world. Given access to a screen and inputs, agents reliably build native user interfaces. Native UI was the province of professionally packaged programs. Now it’s all as bespoke as your editor configuration. And, while I’m sure there’s an upper limit to how good those interfaces can be (with current frontier models), that ceiling is higher than anything you can do in a TUI.
❦
What does it mean for software to be Emacsified? Let’s get into it.
First, it’s personal software. Most of it will be useful only to its creator, and then forgotten, just like the dozens of obsolete little elisp programs littering my .emacs. Personal software defines the ethos of Emacs, which was carefully designed over decades to nurture these kinds of tools. “Emacsification” clocks that everything now works this way, not just baroque text editors.
Still, every once in a while, one of these programs will escape containment. It’ll be useful enough for more than one person to install. But even then, the released artifact won’t be the most important thing about it. The source code won’t be either. If an agent wrote all the SwiftUI code in my project, what do you have to gain from closely reading it?
I’m probably only a little bit right about this, but I think a significant driver of new Emacs packages is a catalytic reaction between your messy local configuration and everyone else’s elisp code. Once you know how to get things done in elisp, it can be easier to build your own solution than to package-install an existing one. In that kind of environment, the code is of passing interest. 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.
If you’re a nerd comfortable with the idea of rolling your own software, everything is now programmable, not merely in a technical sense but a practical one. And that gets to a feeling I think a lot of people have when creating software with agents: what does it mean to say you’re “building” it? “Building” implies more effort than you’re expending. What you’re doing feels a lot more like configuring, on a platform that has suddenly become vastly more configurable. A platform that feels a lot more like Emacs.
❦
The first thing an AI-pilled developer tells you after taking the plunge is how they’re finally finishing all the random side projects they’d collected over the years.
That was an exciting prospect on its own. But it is now also the case that those things, hyperspecific as they might be, can also be pleasant to use. It’s not lost on me the irony of Emacsification undercutting many of the arguments for putting up with Emacs itself, and its janky user interfaces. Magit is still the best thing going. For now.
I don’t have a grand pronouncement to offer about the Future of Software. But I’m pretty sure nerd software is going to get a lot more interesting. How many clanky terminal apps can we drastically (and easily) improve? I’ll finally be able to understand iostat! Across a fleet of hosts, even. And bpftrace! Have you seen the shit Brendan Gregg had to put up with to do terminal visualizations from bpftrace? You don’t have to put up with any of this anymore. In fact, neither do I.
I’m a vulnerability researcher, and I’ve been like a kid in the candy shop for the first half of 2026 with all the exploit development breakthroughs in agent coding. But I understand that makes me a weirdo, and that for most of you all that comes with those advancements is dread.
So I’m glad to have something new to talk about that actually feels like an unalloyed good. Building native UI is now fun; a lot more fun than building web interfaces ever was. Give it a shot; make something stupidly specific to your own problems, enjoy it for a little while, and then share it somewhere — or, better yet, just a screenshot and the prompts you used to make it.