The Ghosts in the Machine
GitHub Copilot suggests entire functions. Cursor and Zed offer AI-native editing experiences. JetBrains integrates machine learning into refactoring. The message is clear: the future of coding is automated, intelligent, and increasingly opaque. Yet, in quiet corners of engineering teams and on remote servers, Emacs and Vim persist—not as relics, but as deliberate choices. These editors, born in the 1970s and refined over decades, refuse to die because they solve a problem AI hasn’t cracked: the tension between automation and agency.
Modern development tools optimize for speed and suggestion. They assume the developer wants help. Emacs and Vim assume the developer wants control. This distinction becomes critical when AI begins to shape not just syntax, but intent. When an IDE auto-generates a function, it makes assumptions about logic, error handling, and style. But when a programmer crafts a macro in Vim or a custom mode in Emacs, they embed their understanding directly into the tool. The editor becomes an extension of thought, not a crutch.
The Tyranny of the Default
AI-driven editors thrive on defaults. They learn from millions of repositories, then apply statistical patterns to new code. This works well for boilerplate, but falters at the edges—where innovation happens. The most valuable code is often the least common, the most idiosyncratic. It’s where domain-specific logic lives, where performance constraints defy convention, where a single misplaced abstraction breaks everything.
Emacs and Vim, by contrast, are blank slates. They don’t presume to know your workflow. They don’t suggest code you didn’t ask for. Instead, they reward mastery. A Vim user who spends years learning modal editing gains a kind of muscle memory that turns keystrokes into commands with surgical precision. An Emacs user who writes Elisp to automate their build process isn’t just saving time—they’re encoding their mental model into the environment. This is the opposite of AI’s black-box assistance: it’s transparent, inspectable, and fully owned.
The rise of AI coding assistants has also exposed a fragility in modern tooling. When an IDE suggests a completion, it’s often pulling from a model trained on public code—code that may be outdated, insecure, or subtly wrong. The suggestion feels confident, but it’s not reasoning. It’s pattern matching. In contrast, the logic in a well-tuned Emacs configuration or a carefully crafted Vim script is deterministic. It does exactly what the programmer defined. There’s no hallucination, no drift, no surprise behavior when the model updates.
Extensibility as Resistance
What makes Emacs and Vim uniquely resilient is their architecture. Emacs isn’t just an editor—it’s a Lisp interpreter with a text interface. Vim isn’t just modal editing—it’s a language for manipulating text. This means both can be reshaped to fit any workflow, not just the ones their creators imagined. Need to integrate a custom linter? Write a function. Want to navigate a codebase like a filesystem? Build a plugin. The barrier isn’t technical—it’s time.
AI tools, by design, resist this kind of deep customization. They’re closed systems optimized for broad usability. You can tweak settings, but you can’t rewrite the core logic. This creates a paradox: the more intelligent the tool becomes, the less it can be truly owned. When GitHub Copilot suggests a flawed import, you can’t fix the model. You can only accept, reject, or disable it. In Emacs or Vim, you fix the problem at the source.
This isn’t to say AI has no place. It excels at repetitive tasks, documentation, and boilerplate generation. But it thrives best when paired with tools that allow humans to retain final authority. The most effective developers aren’t those who let AI write their code—they’re the ones who use AI as a collaborator, then verify, refine, and own the output. And for that, they need an environment that doesn’t hide the mechanics.
The Human Cost of Convenience
There’s a quiet erosion happening in software development: the loss of tactile understanding. When an IDE auto-formats code, you no longer internalize spacing rules. When a model completes a function, you don’t think through edge cases. The convenience is real, but the cognitive trade-off is steep. Mastery requires friction.
Emacs and Vim are friction machines. They demand attention. They force you to learn syntax, structure, and semantics. They make you slow down—not because they’re inefficient, but because they respect the complexity of the task. In an era where speed is equated with productivity, this slowness is radical. It’s also why developers who use these editors often report deeper comprehension and fewer bugs.
AI promises to remove friction. But some friction is necessary. It’s the friction of thinking, of questioning, of building mental models. The best tools don’t eliminate this—they scaffold it. Emacs and Vim do this better than anything built in the last decade. They don’t just edit text. They shape how you think about code.
The future won’t be won by the editor with the most AI features. It will be won by the one that best amplifies human intention. And in that contest, two old programs still have the lead.