Hyping an Editor in the Age of AI

There is a certain kind of tool that generates enormous excitement in the developer community not necessarily because it solves a pressing problem, but because it is built with the right technology, by the right people, at a moment when developers are hungry for something new to talk about. A code editor announced in 2023 — right as AI-assisted coding was beginning to reshape how software gets written — and which shipped its first stable release in 2025, when vibe coding and LLM-driven development had already become the new normal, is a fascinating case study in that phenomenon.

Let’s think about this honestly.

The Speed Argument

The editor’s core pitch is speed. It is written in Rust, takes advantage of the GPU for rendering, and distributes work across multiple CPU cores. The result is an editor that opens files fast, scrolls smoothly, and responds to keystrokes with minimal latency.

That is genuinely impressive engineering. But it prompts an obvious question: who is this for?

Any computer manufactured in the last decade runs VS Code without any noticeable delay. Open a project, navigate files, edit code — it all happens at human-perceptible speeds, which is to say, fast enough that the bottleneck is never the editor. VS Code is a mature, well-optimised product backed by Microsoft, and it has spent years proving itself across millions of developers and every imaginable hardware configuration. It is not slow.

JetBrains IDEs? Absolutely. Those are genuinely heavy applications with indexing pipelines and background processes that can make an older machine genuinely struggle. But conflating VS Code with that category of tooling is a stretch. If the argument for a new editor rests on the premise that the existing options are sluggish, it needs a more specific target than “editors in general.”

The Hardware Question

Here is another angle worth considering. Developers who earn their living writing software are not, as a rule, working on underpowered machines.

There is a longstanding culture in professional development of investing in your tools, and that very much includes hardware. High-RAM laptops, fast SSDs, dedicated GPUs — these are standard-issue for anyone doing this professionally. The developer who buys a mechanical keyboard because it shaves milliseconds off their typing feedback is not going to be running their IDE on a five-year-old budget laptop.

So the question becomes: for whom, exactly, is the one or two seconds saved by a faster editor a meaningful improvement to their daily working life?

The Bigger Picture

This is where things get interesting, and a little uncomfortable for the argument.

It is 2026. Look at any developer forum, any team chat, any honest account of how software gets built today. A significant and growing portion of what developers do is write prompts, review AI-generated code, guide agents through tasks, and integrate the output into their existing codebase. The raw act of manually typing code — the activity that a fast, responsive text editor is specifically optimised to support — is no longer the dominant activity in a developer’s day.

This is not a fringe observation. It is the direction the entire industry has moved. AI-assisted coding went from an interesting novelty in 2023 to a core professional practice in 2025, precisely the window in which this editor was built and shipped.

Which raises the real question: what does a new editor bring to the table in 2026 that the existing ecosystem does not already provide? The answer on the home page is three things: speed, AI integration, and collaborative editing. Speed we have covered. The other two deserve the same scrutiny.

The AI Integration Argument

AI integration sounds more promising — until you look at what already exists. Cursor, a VS Code fork, has been purpose-built around AI-assisted development for years. VS Code itself ships with GitHub Copilot tightly integrated. And increasingly, the most capable AI coding tools are not editor features at all: Claude Code and OpenAI’s Codex CLI operate at the command line, attached to no particular editor, answerable to no UI. The trend is clearly moving away from editor-bound AI and toward agents that work independently of whatever text editor happens to be open.

Building AI integration into a brand-new editor in this climate means starting from scratch in a race that others are already winning — and one that may not even matter much longer.

The Collaborative Editing Argument

The third pillar is collaborative editing — multiple developers working in the same file, in real time.

This is a real feature. But it raises an honest question: why does delivering it require building a new editor from the ground up?

To be fair, this is one area where the existing ecosystem has not fully delivered. VS Code’s Live Share exists, but it has never gained serious traction and most developers rarely touch it. So the problem is real, and a well-executed collaborative editing experience would be genuinely useful.

But that still does not answer the question: why a brand-new editor? VS Code has a massive, battle-tested extension API and an entire ecosystem of forks built on top of it. If the goal is better collaborative editing, a focused VS Code extension or a purpose-built fork would get you there with a fraction of the overhead — and would immediately inherit the plugin library, the keybindings, the themes, and the muscle memory of millions of existing users. Starting from scratch means asking everyone to give all of that up in exchange for a feature that, one suspects, could have shipped as a plugin.

And stepping back even further: what percentage of developers are actually working in real-time pairs on the same file at any given moment? Pair programming has its advocates, but it is not the dominant mode of professional software development. It is a niche use case being offered as a headline justification for a very large bet.

The Horse-Drawn Carriage Problem

There is a historical parallel that keeps coming to mind.

The team behind this editor was previously responsible for one of the most iconic text editors of the previous generation — a tool that was widely beloved, widely adopted, and then widely abandoned. Its downfall was, ironically, performance. It became notorious for sluggishness as projects scaled, and it ultimately lost the market to VS Code.

So the instinct to rebuild from scratch with performance as the north star is understandable. It makes complete sense as a response to how the previous chapter ended.

But the timing. Imagine a master carriage builder in 1910, watching their previous horse-drawn carriage business collapse because a rival built a lighter, faster carriage that everyone preferred. Their natural response, their logical next move, would be to design the most aerodynamic, well-crafted carriage possible — to finally get it right. And then they step outside and the streets are full of automobiles.

The craft is real. The execution is impressive. The moment is off.

To Be Clear

None of this is a criticism of the people who built this tool. Building a performant, well-designed editor in Rust is genuinely hard, and the technical achievement deserves recognition. Anyone can start any project, and curiosity-driven software has its own value.

The question is not whether the editor is good. By many accounts it is. The question is why so many developers — people who are spending their days prompting LLMs and reviewing generated code — are enthusiastically rallying behind an editor whose three selling points are, on closer inspection, each either unnecessary, already solved, or quietly becoming irrelevant.

Part of the answer is probably that developers enjoy talking about developer tools. Part of it is that Rust carries a certain prestige right now. Part of it is that the people who built it have credibility and an audience from their previous work.

But if you strip away the halo effect and ask the plain question — does a faster text editor materially improve your life as a developer in 2026 — the honest answer for most people is probably not really.

And that gap between the hype and the honest answer is worth at least pausing on.