The Emacsification of Software
456 points
• 6 days ago
• Article
Link
作者认为，软件正在经历他所称的"Emacs 化"，这一变化由 AI 代码代理推动。 Emacs 文化是指用户为了解决自己特定的问题，构建个人化、常带个人风格的工具，这类工具往往牺牲了可发现性和广泛可用性。现在这种理念正从文本编辑器蔓延到应用开发领域。原本构建原生用户界面很难，需要专业开发者，但有了代理，任何人都能迅速"挤出"定制化应用。这些应用不挣钱、没有明显的市场定位，仅仅是让一小撮极客的生活稍微好一点。
这一浪潮源于对现有工具糟糕体验的失望。作者指出，虽然 Markdown 已成为软件开发的通用语言，但在终端里用等宽字体阅读常令人疲惫；而图形化编辑器又对只是"查看"文件来说太过侵入。为了解决这个问题，作者用 Claude 代理做出了 MDV.app——一个专门的原生 macOS Markdown 查看器。它包含搜索、书签、复制粘贴等常规功能，注重排版并用 SQLite FTS 建索引。大约用了 30 分钟的互动时间，就做出了一款比 App Store 上现有工具更能提升他日常体验的产品。
作者认为 MDV.app 预示着更大趋势的开端。开发者不再需要依赖臃肿的、把 Chromium 打包进来的单体 Electron 应用，而会越来越多地用代理去构建专门的原生 UI 工具——关键在于创意而非源代码本身。他明确鼓励读者不必拘泥于使用他的工具，而是"拿去这个想法"，做出更好的变体。这是向个人化软件的转变：一波开发者会为了解决自身痛点去打造界面优雅、针对特定"极客"问题的工具，而这些工具以前难以证明投入的价值。
所谓软件的"Emacs 化"，就是向个人化、定制化应用的转变。在这个生态里，驱动软件的提示词和背后的想法，比源代码更有价值。作者形容这种"Emacs 化"被 AI 代理"撬开"，让原生 UI 开发变得可接近且有趣。他把这种体验比作配置 Emacs：软件开发平台变得极具可配置性。这一趋势会让"极客软件"更有吸引力，人们会用新工具替代那些糟糕的终端专用工具。
作者还举出超出简单 Markdown 查看器的例子：用代理为复杂的系统监控工具（如 bpftrace 、 iostat）构建原生 UI，取代丑陋的终端可视化。他把这种变化看作"纯粹的好事"，尽管围绕 AI 的安全隐忧仍然存在。他鼓励大家别把构建软件当成传统的体力活，而是开始用代理去"配置"。建议极客们去试一试，做"某个愚蠢但非常特定的东西"，然后分享成果，或者至少分享所用的提示词。
作者认为，这种转变会催生一波缺乏广泛商业吸引力的个人软件。这些工具可能只服务小群体，甚至只是开发者本人。 Emacs 化让任何人都能创建这些小众、个性化的工具，代表了从单体 Electron 应用向小型、原生、按需定制软件的转变。用于创建这些工具的提示与想法，与工具本身一样重要，构建软件的过程正在演变成一种配置行为。
The author argues that software is undergoing what he calls "Emacsification," a shift driven by AI code agents. Emacs culture is defined by users building personal, often idiosyncratic tools to solve their own specific problems, frequently at the expense of discoverability or broad usability. With AI agents, this same ethos is now leaking out of text editors and into application development. Building native user interfaces used to be difficult work that required professional software developers, but agents now allow anyone to quickly "extrude" bespoke applications. These applications make no money and have no obvious market fit. They simply make life slightly better for a small group of nerds.
The phenomenon was triggered by frustration over the poor quality of existing tools. The author suggests that while Markdown has become the universal language of software development, the tools used to read it in the terminal are often fatiguing when rendered in monospaced fonts. Graphical UI editors are too intrusive for just "viewing" a file. To solve this, the author used the Claude agent to build MDV.app, a dedicated native macOS Markdown viewer. The tool includes standard features like search, bookmarks, and copy-paste, along with good typography and a SQLite FTS index. It took about 30 minutes of interactive time to build something that improves the author's daily quality of life better than anything currently on the App Store.
The author believes SDV.app marks the start of a larger trend. Instead of relying on awful, monolithic Electron apps that carry their own copy of Chromium, developers will increasingly use agents to build specialized native UI tools where the key artifact is the idea rather than the source code. He explicitly encourages readers not to necessarily use his tool, but to "steal the idea" and build their own better versions. This represents a shift toward personal software. He suggests that we will see a wave of builders scratching their own itches, solving specific "nerd" problems with pleasant interfaces that were previously too difficult to justify the effort of building.
The "Emacsification" of software refers to the shift toward personal, bespoke applications. In this ecosystem, the prompts and the ideas behind the software are more valuable than the source code itself. "Emacsification" is described as "fracked" by AI agents, making native UI development accessible and fun. The author compares the experience to configuring Emacs, because the platform of software development has become vastly more configurable. He suggests that this trend will make "nerd software" more interesting as people build tools to replace terrible terminal-only utilities.
The author concludes by providing examples of this trend beyond simple Markdown viewers. He mentions using agents to build native UI for complex system monitoring tools like `bpftrace` and `iostat`, replacing ugly terminal visualizations. He frames this as an "unalloyed good," even amidst the dread surrounding AI and security vulnerabilities. He encourages readers to stop thinking of software construction as "building" in the traditional, labor-intensive sense and instead start "configuring" with agents. He advises nerds to give it a shot, "make something stupidly specific," and then share the results, or at least the prompts.
He suggests that this shift will lead to a wave of "personal software" that lacks broad commercial appeal. These tools will be created for small groups, or even just the developers themselves. He suggests that the "Emacsification" of software is making the creation of these personal, niche tools accessible to everyone. This represents a move away from monolithic Electron apps. It shows that the future of software might be small, native, and custom-built for specific problems. The prompts used to create these tools are as important as the tools themselves, and the act of building software has become a form of configuration.
283 comments • Comments Link
• LLMs 实现了"个人软件"：用 AI 构建高度定制、一次性的应用以精准契合个人工作流，原本打包出售的专业软件正在被个人夺回。随之而来，消费成为新的瓶颈，因为分享或维护这些个性化的数字"茧房"越来越困难。
• "配置管理"成为下一个前沿：当软件易于生成但难以分享或版本化时，关注点从编写代码转向管理"源代码"——包括提示词、生成日志和截图等，这对 GitHub 以外的协作模式提出了新挑战。
• 这类似于"Lisp 程序员的困境"：高度定制带来生态碎片化，解决方案各不相同、难以被他人采用。借助 LLM，这种被称为"双向情感障碍的 Lisp 程序员"(BBM) 的心态可以被放大复制，可能催生"AI 唯我论"。
• "配方"比"工件"更有价值：用户不应只关注分享静态软件二进制，而应分享用于生成应用的提示词和逻辑——具体的代码不如创造它的想法与配方重要。
• 软件的"Emacs 化"：LLM 让非专家像 Emacs 用户几十年来那样调整和定制他们的数字环境。但如果缺乏真正的交互式、实时调试循环，这些生成工具可能缺乏传统软件的稳定性。
• 维护比创建更难：虽然现在生成一次性脚本比安装新应用更容易，但为调试边缘案例或随时间更新个人工具所付出的意愿仍然有限，这促成了"杂乱堆"或一次性设计的文化。
• 原生平台 vs 跨平台垃圾：用户可以用 LLM 生成"足够好"的原生应用（如 SwiftUI）或高度专业化的 CLI 工具，从而绕过那些试图面面俱到的替代品，更好地匹配他们的心智模型和性能需求。
• 我们是否在失去软件的"通用语言"？界面和文件格式的高度定制化使互操作更复杂，增加了专业团队协作和未来标准化数字出版的难度，可能迫使 AI 为每个专有生态构建一次性转换器。
• 等宽文字并非普遍"令人疲劳"：虽然有人认为比例字体更易阅读，但等宽字体仍是数十亿用户的强烈偏好，在代码或符号数学中通常必不可少。软件的"Emacs 化"让用户能够把 UI 包装成符合自己阅读偏好的样子，而不是被迫接受通用默认。
• 家用计算的原始愿景：上世纪 60 年代的设想是每个家庭终端都能为个人需求编写自定义程序。 LLM 最终把入门门槛降到足够低，从而有可能实现这一愿景，即便生成的"代码"对人类的可读性不如 80 年代的 BASIC 。
• 讨论强调了从"消费优先"的软件经济向以 LLM 为核心的"个人自动化"经济的范式转变。与会者普遍认为 AI 已将定制软件的门槛几乎降为零，当前情形类似于家用计算或高度可定制的 Lisp 环境的早期阶段。但对这种"唯我论"长期影响存在重大分歧，尤其在可维护性、共享标准碎片化以及"氛围编码"能否经受住调试个性化工具的枯燥现实方面。一些人把这视为"高级用户"的新黄金时代，另一些人则警告说，缺乏文档和标准化可能导致不可用的"杂乱堆"。 • LLMs enable "personal software." Packaged, professional software is being reclaimed by individuals using AI to build hyper-specific, "throw-away" apps tailored to their exact idiosyncratic workflows. This shift makes consumption the new bottleneck as sharing or maintaining these personalized digital "cocoons" becomes increasingly difficult.
• "Configuration management" is the next frontier. As software becomes easy to generate but hard to share or version, the focus shifts from writing code to managing "the source." This includes prompts, generated logs, and screenshots, which creates pressure for new collaboration models beyond traditional platforms like GitHub.
• This mirrors the "Lisp programmer's dilemma." High levels of customization led to a fragmented ecosystem where solutions are unique to the individual and difficult for others to adopt. With LLMs, this "Bipolar Lisp Programmer" (BBM) mindset is now scalable, potentially leading to a state of "AI solipsism."
• The value of "recipes" over "artifacts." Instead of sharing static software binaries, users should focus on sharing the prompts and logic used to generate the application. The specific code output is less important than the "idea" and the "recipe" used to create it.
• The "Emacsification" of software. LLMs allow non-experts to tweak and customize their digital environments in the same way Emacs users have done for decades. However, without the interactive, "live" debugging loop of a true programming environment, these generated tools may lack the stability of traditional software.
• Maintenance is harder than creation. While it is now easier to generate a one-off script than to install a new app, the willingness to debug edge cases or update personal tools over time remains a significant hurdle, creating a "cruft heap" or "throwaway design" culture.
• Native platforms vs. cross-platform slop. Users can bypass "replacement-grade" software that attempts to serve everyone poorly by using LLMs to generate "good-enough" native applications (e.g., SwiftUI) or highly specialized CLI tools that better match their mental models and performance needs.
• Are we losing the "common language" of software? The customization of user interfaces and file formats makes interoperability more difficult. This complicates professional teamwork and the future of standardized digital publishing, potentially requiring AI to build "throw-away converters" for every proprietary ecosystem.
• Monospaced text is not universally "fatiguing." While some find proportional fonts easier to read, monospaced text remains a strong preference for billions of users and is often essential for code or mathematical notation. The "Emacsification" of software allows users to shrink-wrap the UI to their specific reading preferences rather than accepting a universal default.
• The original vision of home computing. The 1960s vision was that every home terminal would be used to write custom programs for personal needs. LLMs finally bring the barrier to entry low enough to realize this vision, even if the "code" produced is less comprehensible to a human than 80s-era BASIC.
• The discussion highlights a paradigm shift from a "consumption-first" software economy to a "personal-automation" economy using LLMs. Participants generally agree that AI has lowered the barrier to entry for custom software to near zero, comparing the current moment to the early days of home computing or the highly customizable Lisp environments. However, there is significant debate over the long-term implications of this "solipsism," particularly regarding maintainability, the fragmentation of shared standards, and whether the novelty of "vibe coding" will survive the tedious reality of debugging personalized tools. While some see this as a new golden age for "power users," others warn that the lack of documentation and standardization could lead to an unusable "cruft heap."