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

There is no single winning editor. Each programmer in these four conversations picks the one that removes what slows that programmer down. The sharpest disagreement is whether a model writing more of the code is a help or a new source of errors.

Guido van Rossum, the creator of Python, left Emacs after about four decades for VS Code. He likes it for the same reason he liked Emacs: a small core with packages that can extend nearly everything. He used the heavier PyCharm to navigate a codebase of five million lines. He uses GitHub Copilot every day. Its suggestions are usually slightly wrong, he says, but they save a lot of typing, and of the tool he says "It helps you take care of the boring stuff". His advice on tools is to keep a plan B and not overthink it.

ThePrimeagen, who spent about ten years at Netflix, stays in Neovim. He wants every action on the keyboard and argues that anyone who will spend 50,000 hours programming should know an editor deeply, whichever it is. He limits tinkering with his setup to about once a year. On AI he is cautious from experience. He was amazed by Copilot at first, then found he was introducing more bugs, since reading code is a different skill from writing it. His biggest worry is that juniors who offload everything stay juniors.

The four founders of Cursor all started as Vim users and moved to VS Code for Copilot. They forked VS Code because they believe AI will change how software is built and a plugin would not give them enough control. Their main feature predicts the next edit, so that actions whose intent is already clear take one key press. They admit that agents are not yet useful for most tasks, that models are bad at finding bugs, and that reviewing larger changes is a growing burden. They want the programmer to keep speed and control.

George Hotz barely cares about the editor. He says he spends five percent of his time typing and 95 percent debugging, so "The last thing I want is close to correct code." He wants an AI that reads his code and points out bugs, much as a type checker does. He expected to use the tools more as they improve.

All four use tool help, none expects AI to replace programmers soon, and all agree it is weak at hard debugging. They split on whether slightly wrong code is worth having, which follows from whether typing or attention is the scarce thing. These are snapshots in a fast-moving field, so the reasoning lasts longer than the rankings.

What to do with it: find your bottleneck before choosing, whether typing, navigating or debugging. Prefer an editor with a small core and a strong package ecosystem. Learn the one you pick deeply. Run a static type checker. Use AI completion for boring, predictable code and name things well. Read every suggestion as if someone else wrote it. Keep writing code yourself while you are learning. Weigh privacy for sensitive code. Do not rely on agents for hard problems yet.