Emacs, Neovim, VS Code or Cursor: what editors programmers choose now

The Short Version

There is no single winner, and the four conversations show why: each programmer picks the editor that removes what slows that programmer down [1][2][3][4]. Guido van Rossum left Emacs after about four decades for VS Code because it keeps what he valued, a small core with packages that can extend nearly everything [1]. ThePrimeagen stays in Neovim because he wants every action on the keyboard and argues that anyone who will spend 50,000 hours programming should know an editor deeply [2]. The Cursor founders, all former Vim users, forked VS Code because they believe AI will change how software is built and a plugin would not give them enough control [3]. George Hotz barely cares about the editor and says the AI he wants is one that finds his bugs, not one that types for him, which is the sharpest disagreement in the set: whether a model writing more of the code is a help or a new source of errors [1][2][3][4].

Table of contents

What They Said

Guido van Rossum: from Emacs to VS Code, with PyCharm for the big codebase

Python's creator has used most of the options. He started on vi, used Emacs from the early 1980s until about two years before the conversation, and dabbled with PyCharm between 2013 and 2018 [1]. His use of PyCharm was specific: navigating Dropbox's 5-million-line codebase, while he did the actual editing in Emacs [1]. His comparison is that PyCharm is like driving an 18-wheeler and Emacs is a comfortable Toyota with 100,000 miles on it [1].

After joining Microsoft he tried VS Code and liked it, and he explains the appeal in architectural terms [1]. Emacs has a core engine, and, as he puts it, "what makes it an editor full of features is all the Lisp packages" [1]. VS Code is built the same way: "a base engine that you have no control over," a package manager, interfaces for packages, and conventions for how packages interact with the lower layers and with each other [1]. That is why he sees VS Code as the spiritual successor of Emacs [1]. The contrast with PyCharm came from experience: at Dropbox, a colleague writing a PyCharm extension to integrate the mypy type checker found that "it was really a struggle" to find documentation and get a development workflow going [1].

What he wants from an editor, then, is extensibility plus help with scale. The second need shows in his work on type hints, where a static type checker reads code without running it and flags inconsistencies; he notes that PyCharm has its own heuristic checker and believes many professional Python developers run one in continuous integration [1].

On AI he is a relaxed adopter. He uses GitHub Copilot every day [1]. Its suggestions are usually slightly wrong, he says, but they save him a lot of typing, often completing a whole line or a five-to-ten-line function if he names it well [1]. He does not think it threatens programmers any more than Stack Overflow did: "It helps you take care of the boring stuff" [1]. It works best as a reminder of things you could look up, while deciding what to build remains yours [1].

His general advice on tools applies to editors too: accept that not every choice will be perfect, keep a plan B, and do not overthink it [1]. Lex Fridman, who admits to a lingering attachment to Emacs, tells him he feels he should move on [1].

ThePrimeagen: Neovim, one monitor, and knowing the tool cold

Michael Paulson, known as ThePrimeagen, spent about ten years at Netflix and now teaches programmers online [2]. His setup is built around never leaving the keyboard: a single monitor with large text, Linux with the i3 window manager so every application is one keystroke away, tmux sessions with a fuzzy-find script to jump between projects, Neovim, and his own Harpoon plugin to pin four files [2].

His case for Vim motions is that they are a better language for editing text. You describe an action, such as deleting around a paragraph, without your hands leaving the keys [2]. He is honest that they are only worth it if you are willing to endure the learning curve [2].

The broader argument is not really about Neovim. If you spend 50,000 hours programming, he says, you should know your editor deeply, whatever it is [2]. Knowing his tools means fewer of what he calls "side quests," so he can write a thousand lines on a plane without looking anything up [2]. He guards against the opposite failure as well, limiting editor tweaking to about once a year to avoid endless tinkering [2].

On AI he is the most cautious voice with real experience of the tools. When he first used GitHub Copilot he was amazed, but over time he introduced more bugs: "I wasn't co-piloting well. I was autopilotting much better" [2]. Reading code, he found, engages a different skill than writing it [2]. He says AI is great for predictable work and weak in cutting-edge or poorly documented areas such as the Zig language [2]. His biggest worry is learned helplessness, with people offloading everything so that "juniors remain juniors forever" [2]. He wants an assistant that cares about the craft the way a good intern does, and says that even with an agent tool he often ends up rewriting the output himself [2].

Lex argues the other side in the same conversation: AI makes programming more fun and less lonely, speeds up tasks like wiring up an API, and working with it is a skill worth building, including learning what context the model is missing [2]. By this conversation Lex has moved from defending Emacs to using Cursor, and he wonders aloud whether he should try Neovim [2].

The Cursor founders: rebuild the editor around the model

Michael Truell, Sualeh Asif, Arvid Lunnemark and Aman Sanger describe a code editor as a souped-up word processor for programmers that understands the structure of code, and they expect that definition to change a lot over the next decade [3]. Their own path matters to this debate: all four started as Vim users and switched to VS Code in 2021 for GitHub Copilot [3]. Copilot felt like a friend finishing your sentences, and when it was wrong you just typed another character [3].

They forked VS Code rather than writing an extension because they believed models would change how software is built and a plugin would limit their control [3]. Being even a few months ahead matters enormously in this field, they argue: "I think the cursor a year from now will need to make the cursor of today look obsolete" [3]. They felt Copilot had gone stale even as models improved, and they stress that "we're making it for ourselves," with the people designing the interface and the people training the models sitting a few feet apart [3].

Their standard for the product is unusual. "I think also a code editor should just be fun," one of them says, and they throw out experiments that work but are not fun; much of fun, they add, comes from speed [3].

The signature feature, Cursor Tab, extends autocomplete from predicting characters to predicting your next edit, the next place you will jump, a change in another file or a terminal command [3]. Arvid describes the goal as making every zero-entropy action, where your intent is already clear but you would still have to type, happen with one press of Tab [3]. They also let a large model sketch a change and a separate trained model apply it, because frontier models are surprisingly bad at producing exact diffs [3].

They are candid about limits. Agents are really cool but not yet super useful for most tasks, because most programming is iterative and people want instant results to react to [3]. Frontier models are strikingly bad at finding bugs when simply asked [3]. And as models propose bigger changes, humans must review more; Aman says "Code review kind of sucks" and wants models to highlight the important parts of a diff and flag likely bugs [3]. They do not expect natural language to replace code entirely [3].

Their picture of the future keeps the human in charge. Michael says they are excited about a future that emphasizes the programmer's speed, agency and control, not one where you chat with a bot as if it were an engineering department [3]. Good engineering is made of countless micro-decisions, and handing them off loses control [3]. The company's own manifesto describes a hybrid human-AI engineer who will "iterate at the speed of their judgment" [3].

George Hotz: typing was never the bottleneck

Hotz, the founder of comma.ai and tiny corp, said at the time of his conversation that he did none of his programming with GPT [4]. His reason is a claim about where programming time goes: "I spend five percent of time typing and 95% of time debugging. The last thing I want is close to correct code. I want a machine that can help me with the debugging, not with typing" [4]. His summary elsewhere is "My programming speed is not at all limited by my typing speed" [4].

He has little interest in editor features in general. For years, he says, "I didn't even have auto complete," because such things helped so marginally [4]. What changed his mind slightly is that VS Code's autocomplete became good enough to need no setup: he can go into any codebase and it "is right 90% of the time" [4]. He also praises the company behind it, saying that between GitHub, VS Code and the improvements to Python, "Microsoft is doing the best work in the programming world" [4].

What he does want is "a very intelligent pair programmer" that pops up to say he wrote a bug on a particular line and what it is [4]. His model for that is not a language model but mypy, the Python type checker, which he loves, and he wishes Python had a runtime flag to enforce types [4]. "I want AI's reading my code and giving me feedback," he says, not writing half-finished completions [4].

He adds a jab at the main selling point of AI completion: if Copilot saves you lots of boilerplate, your framework is probably bad [4]. Still, he is not opposed in principle. "I don't think I'm going to have a problem at all adapting to the tools once they're good," he says, and he predicted he would use AI tools a little within two years and heavily within five [4]. He rates current AI as junior-engineer level for coding [4]. Lex, in the same exchange, says about 80% of his own quick, offhand code is written by GPT, though not library or performance code [4].

Where They Agree, and Where They Don't

Some things all four accept. Nobody argues for an editor without help from tools; even Hotz takes good autocomplete and loves a type checker [4]. Nobody expects AI to replace programmers soon: van Rossum compares Copilot to Stack Overflow [1], ThePrimeagen notes that no computing advance so far has reduced jobs [2], the Cursor team wants humans in the driver's seat [3], and Hotz rates the models as junior [4]. And everyone agrees the AI is weak at the hard part. The Cursor team says models are bad at bug finding [3]; ThePrimeagen and Lex agree AI is poor at hard debugging [2]; Hotz says debugging help is exactly what is missing [4].

VS Code is also the common ground of the moment. Van Rossum moved to it [1], the Cursor founders moved to it and then built on it [3], and Hotz credits its autocomplete [4]. ThePrimeagen is the holdout, and his conversation includes plenty of teasing about Emacs and Microsoft [2].

The disagreements are substantial.

Is slightly wrong code worth having? Van Rossum says yes: Copilot's suggestions are usually slightly wrong but save a lot of typing [1]. Hotz says no: close to correct is the last thing he wants, because he spends his time debugging, not typing [4]. ThePrimeagen's experience supports Hotz, since he found himself introducing more bugs [2]. The Cursor team sits with van Rossum on the value and with Hotz on the cost, which is why they treat review and verification as the deeper challenge [3]. The split follows from what each person thinks is scarce. If typing is a real cost, as it is for van Rossum, a self-described poor two-finger typist, a near-miss is a gift [1]. If attention for finding errors is the scarce thing, a near-miss is a liability [4].

Should AI be the center of the editor or a guest in it? The Cursor founders say the editor must be rebuilt around the model [3]. Van Rossum treats Copilot as one more extension in an extensible editor [1]. ThePrimeagen's whole method is mastery of a tool he controls, and he fears what offloading does to learning [2]. Hotz would rather fix the framework than automate the boilerplate [4].

Speed of hands or speed of intent? ThePrimeagen invests in motions that make his own editing fast [2]. The Cursor team wants the predictable keystrokes not to be typed at all [3]. Both are attacking the same waste from opposite ends, and Arvid's remark that pressing Tab is really injecting intent is close to how ThePrimeagen describes telling the editor what to do with a motion [2][3].

Stay or switch? ThePrimeagen says go deep on one tool [2]. The Cursor founders left Vim when a feature elsewhere was good enough [3]. Van Rossum did both: about forty years in one editor, then a switch to something he liked better [1].

What should AI do first? Hotz wants a bug finder [4]. The Cursor team builds prediction and editing first and admits bug finding does not work well yet, while exploring ways to train for it [3]. On this point the customer and the builders agree about the goal and differ only on what is possible now.

Why It Works

A small core with a package ecosystem. Van Rossum's explanation for both Emacs and VS Code is the same design: a base engine, powerful primitive operations, and packages that can override nearly everything [1]. Such an editor absorbs new needs, a type checker or an AI assistant, without the user changing tools. Cursor's choice to fork VS Code rather than start from nothing builds on that base [3].

Motions as a language. Vim-style editing lets you state an action on a unit of text, and ThePrimeagen's claim is that this is faster than reaching for a mouse once learned [2]. Combined with pinned files and one-keystroke window switching, it removes the small interruptions he calls side quests [2].

Code is predictable. Aman Sanger notes that code has lower loss per byte than natural language, meaning many characters are highly predictable [3]. That is why predicting the next edit works at all, and why the team can aim to remove zero-entropy keystrokes [3].

Speed makes it feel right. The Cursor team attributes much of an editor's fun to speed, and describes the engineering behind it: small low-latency models, caching reused across keystrokes, loading the current file before you finish typing, and computing the next suggestion as if you had already accepted the current one [3].

Where the time goes. Hotz's five percent typing and 95 percent debugging is his own estimate, not a measurement, but it explains his priorities [4]. Van Rossum, by contrast, values saved typing and believes the creative work stays with the programmer [1].

Reading is not writing. ThePrimeagen's observation that reviewing generated code uses a different skill than writing it explains how a tool can speed up output and still add bugs [2]. The Cursor team's worry about the growing burden of review is the same mechanism seen from the builder's side [3].

Trust is low. A developer survey discussed by ThePrimeagen and Lex showed most developers use or plan to use AI but only about 2.7% highly trust its output [2].

Where It Applies, and Where It Doesn't

Size of codebase. Van Rossum reached for PyCharm's heavier machinery to navigate five million lines [1]. The Cursor team notes that even the best laptop struggles with a big company's codebase, one reason their indexing and models run on servers [3].

How well-trodden the work is. AI assistance is strongest on predictable, well-documented work and weak on new or poorly documented languages [2]. Hotz's point about boilerplate implies the benefit is largest where the code is most repetitive [4].

Stage of learning. ThePrimeagen's fear is for juniors who offload before they have built skill [2]. Van Rossum, an expert using Copilot as a reminder of what he could look up, is the opposite case [1]. The Cursor team tells young people it is an exciting time to build software, with far less boilerplate than a decade ago [3].

Privacy. Arvid Lunnemark worries that more of the world's information will flow in plaintext through one or two centralized providers; Cursor stores only vectors of code, not the code itself, for its index [3]. Hotz distrusts the cloud because of who owns the off switch and says a cloud AI will always be aligned with its company [4]. Anyone working on sensitive code has to weigh this.

Willingness to pay the learning cost. Vim motions pay off only for those who will endure the curve [2]. Lex compares leaving Emacs to learning to touch type [1].

Time. These are snapshots. Hotz's refusal came with a forecast that he would be using the tools heavily within five years [4]. The Cursor team expects its own product to be obsolete in a year [3]. Their statement about which model was best for coding applied to that moment only [3]. What is durable in these conversations is the reasoning, not the rankings. Two of the four sources, the ThePrimeagen and Cursor conversations, are available here only as summaries, so their views are reported in less of their own words [2][3].

What To Do With It

1. Find your bottleneck before choosing. Ask whether you lose more time to typing, to navigating a large codebase, or to debugging. Van Rossum, ThePrimeagen and Hotz each chose according to a different answer [1][2][4].
2. Prefer an editor with a small core and a strong package ecosystem. It lets you add a type checker or an AI assistant later without switching tools [1].
3. Learn the editor you pick deeply. Master its motions, shortcuts and navigation so you rarely leave the keyboard or look things up, and cap configuration tinkering to roughly once a year [2].
4. Run a static type checker. Both van Rossum and Hotz rely on one, and it is the closest existing thing to the bug-spotting assistant Hotz wants [1][4].
5. Use AI completion for boring, predictable code, and name things well. Van Rossum gets whole functions when the name is clear [1]. If you find it saving you huge amounts of boilerplate, take Hotz's hint and look at whether the framework is the problem [4].
6. Read every suggestion as if someone else wrote it. Treat generated code as slightly wrong by default, and watch your own bug rate the way ThePrimeagen did [1][2].
7. Keep writing code yourself while you are learning. Offloading everything is how a junior stays a junior [2].
8. Give the model context, and keep the decisions. Learn what the model is missing, as Lex suggests, and keep the design choices in your own hands, as the Cursor team advises [2][3].
9. Do not rely on agents or AI bug finding for hard problems yet. The people building them say they are not there for most tasks [3].
10. Do not overthink it. Try something unusual, keep a plan B, and switch when another tool is clearly better for you [1].

Sources

1. Guido van Rossum on Python 3.11's Speedup, Type Hints, the GIL and the Future of Programming · Lex Fridman Podcast
2. The Primeagen: Programming, AI, ADHD, Productivity, Addiction, and God · Lex Fridman Podcast
3. Cursor Team: Future of Programming with AI · Lex Fridman Podcast
4. George Hotz on tiny corp, tinygrad, Open-Source AI Safety, Self-Driving, and Twitter · Lex Fridman Podcast