Cursor erreicht fünf Millionen Entwickler. VS Code beobachtet das genau.

VS Code ist nach wie vor das dominierende Entwickler-Tool in jeder relevanten Kennzahl: 75,9 Prozent tägliche Nutzung im Jahr 2025, ein riesiges Erweiterungs-Ökosystem, tiefe Integration mit GitHub und Microsofts volle Ingenieurskraft im Rücken. Und dennoch erreichte Cursor – ein drei Jahre alter Fork von VS Code, der auf KI-first-Workflows setzt – im selben Jahr ein jährliches Wachstum von 120 Prozent und bis Mai 2026 insgesamt fünf Millionen Entwickler. 67 Prozent der Fortune-500-Unternehmen setzen Cursor in mindestens einem Team ein.

Diese Entwicklung verdient Aufmerksamkeit. Nicht weil VS Code verliert, sondern weil Cursors Wachstum zeigt, was Entwickler heute von ihren Werkzeugen erwarten.

Was „KI-nativ“ wirklich bedeutet

Die meisten IDE-Plugins und Erweiterungen fügen KI als Seitenleiste hinzu – ein Chat-Panel, das man aufruft, einen Vorschlag, den man annehmen oder verwerfen kann. Cursors Ansatz ist anders: Die Codebasis dient als primärer Kontext für alle KI-Interaktionen. Der Composer-Modus ermöglicht Änderungen an mehreren Dateien gleichzeitig, unter Bezugnahme auf Funktionen und Datenstrukturen im gesamten Projekt – nicht nur in der aktuell bearbeiteten Datei.

Die diff-basierte Autovervollständigung schlägt nicht nur Zeilen-Ergänzungen vor – sie schlägt mehrzeilige Refactorings im Kontext des umgebenden Codes vor, oft mit Voraussicht auf den Zweck der Änderung basierend auf Funktionssignatur und benachbartem Code. Der codebasisbewusste Chat ermöglicht Fragen wie „Warum lehnt die Authentifizierungs-Middleware Anfragen mit diesem Header ab?“ und erhält eine Antwort, die tatsächlich die Middleware-Implementierung gelesen hat, statt eine generische Erklärung zur Funktionsweise von JWT zu liefern.

Diese Funktionen lassen sich nicht sauber in ein Plugin-Modell einfügen. Sie erfordern Zugriff auf den vollständigen Workspace-Zustand auf IDE-Ebene. Deshalb musste Cursor ein Editor sein, keine Erweiterung.

Der VS-Code-Vorteil, der auch eine Einschränkung ist

VS Codes Dominanz beruht teilweise auf seinem Erweiterungs-Ökosystem: über 50.000 Erweiterungen für jede Sprache, jedes Framework und jeden Workflow. Cursor erbt dieses vollständig – es führt VS-Code-Erweiterungen nativ aus, was die Umstellungshürde nahezu eliminiert. Ein Entwickler, der von VS Code zu Cursor wechselt, verliert weder sein Theme noch seinen Language Server oder seine Debugger-Konfiguration.

Aber dieselbe Abwärtskompatibilität schafft Einschränkungen. VS Codes Architektur wurde entworfen, bevor große Sprachmodelle existierten. Die Extension-API spiegelt Annahmen wider, wie eine „Code-Vorschlag“ auszusehen hat, die nicht gut auf mehrzeilige generative Bearbeitungen passen. Microsoft hat KI-Funktionen über Copilot hinzugefügt, arbeitet aber innerhalb einer Architektur, die dafür nicht ausgelegt war.

Cursor, da es VS Code auf Basisebene geforkt hat, kann die Kernfunktionen des Editors auf eine Weise instrumentieren, die Erweiterungen nicht können. Hier liegt seine Leistungsfähigkeit bei Mehrdatei-Aufgaben – es ist kein Workaround, sondern architektonischer Zugang.

Zed: Die andere Herausforderung

Während Cursor auf KI-Tiefe setzt, konkurriert Zed auf grundlegender Ebene. Der in Rust geschriebene native Editor startete im April 2026 mit Version 1.0, mit Startzeiten von 0,12–0,4 Sekunden (vs. VS Codes 1,2–3,0 Sekunden) und einem Ruhemodus-Speicherverbrauch von 142–200 MB (vs. VS Codes 650 MB bis 1,2 GB).

Für Entwickler, die auf MacBooks mit 16 GB RAM und einem Dutzend geöffneter Browser-Tabs arbeiten, ist der Speicherunterschied spürbar. Zeds 120fps-Rendering durch GPU-beschleunigtes Textlayout macht das Scrollen durch große Dateien kategorial anders als das browserbasierte Rendering, das VS Code von Electron erbt.

Zeds Erweiterungsmodell verwendet WASM-basierte Sandboxing – kleineres Ökosystem als VS Code, aber leistungsfähiger und sicherer. Die KI-Integration läuft über eine offene API statt über eine herstellerspezifische Implementierung, was den Austausch zugrunde liegender Modelle erleichtert.

Was Entwickler tatsächlich wählen

JetBrains' AI Pulse Survey vom Januar 2026 ergab, dass 18 Prozent der Entwickler Cursor bei der Arbeit nutzen und 18 Prozent Claude Code – den Kommandozeilen-Coding-Agent – auf nahezu gleichem Niveau, aber deutlich unter VS Codes Basis. GitHub Copilot bleibt das am weitesten verbreitete KI-Coding-Tool in absoluten Zahlen, aber sein Wachstum hat sich verlangsamt, da Alternativen an Zugkraft gewinnen.

Das sich abzeichnende Muster: Cursor dominiert bei Teams, die Greenfield-Entwicklung betreiben oder an großen, komplexen Codebasen arbeiten, bei denen Mehrdatei-Kontext wichtig ist. Zed zieht Entwickler an, für die Leistung eine Einschränkung darstellt – große Monorepos, ältere Hardware oder Vorliebe für leichtgewichtige Werkzeuge. VS Code bleibt der Standard für Teams, bei denen Standardisierung und Plugin-Kompatibilität mehr zählen als KI-Tiefe oder Rohleistung.

Die Frage an Microsoft

Microsoft hat die Ressourcen, um das zu bauen, was Cursor gebaut hat – und hat sich mit der zunehmend tiefen Integration von GitHub Copilot in VS Code in diese Richtung bewegt. Die Herausforderung ist, dass Architekturentscheidungen von 2015 heute einschränken, was ohne einen großen Rewrite möglich ist.

Die IDE-Kriege sind nicht vorbei, und VS Code ist nicht in Gefahr, seine Führungsposition zu verlieren. Aber die Definition von „bestes Entwickler-Tool“ verschiebt sich von „meiste Funktionen und Erweiterungen“ hin zu „am effektivsten bei KI-gestützter Entwicklung“. Das ist ein Rennen, bei dem ein kleiner, fokussierter Konkurrent mit architektonischer Flexibilität Vorteile hat, die Marktanteil und Legacy nicht ausgleichen können.