Ist die IDE tot? Entwickler verlassen den Editor kollektiv.

Das Übersetzungsbüro von Shenyi ist das Übersetzungsteam von 36Kr. Es konzentriert sich auf Bereiche wie Technologie, Geschäft, Arbeitsplatz und Lebensstil und stellt vor allem neue Technologien, neue Ansichten und neue Trends aus dem Ausland vor.

Herausgeberhinweis: Programmierer "schreiben" nicht mehr Code, sondern "verwalten" Agenten. Wenn die IDE zu einem untergeordneten Werkzeug wird, verschiebt sich der Schwerpunkt der Programmierung stark hin zur "Orchestrierungsebene". Dieser Artikel ist eine Übersetzung.

Der Schwerpunkt der Arbeit von Entwicklern verschiebt sich. Er verschwindet nicht, sondern wandert. Er geht von der kontinuierlichen, zeilenweisen Bearbeitung in einem einzigen Fenster hin zur Überwachung von Agenten, die Dateien planen, umschreiben, Tests ausführen und Änderungen zur Prüfung einreichen können. Die uns bekannte IDE wird möglicherweise nicht mehr das primäre Werkzeug für die Softwareentwicklung sein oder wird stark verändert werden.

In vielen Werkzeugen, die auch ich und viele andere Entwickler täglich nutzen - wie Conductor, Claude Code Web, GitHub Copilot Agent, Jules, Vibe KanBan und sogar cmux - zeigt sich dieser gleiche Wandel immer wieder: Die Steuerungsebene wird zur Hauptschnittstelle, während der Editor in den Hintergrund tritt und zu einem der darunter liegenden Werkzeuge wird.

Cursor hat gerade Glass veröffentlicht - eine neue Schnittstelle, die speziell dafür entwickelt wurde, "die Zusammenarbeit mit Agenten klar, intuitiv und kontrollierbar zu machen". Hier ist die Agentenverwaltung das Kernerlebnis, während der traditionelle Editor ein Werkzeug wird, das Sie nur nutzen, wenn Sie in die Details gehen müssen. Die Reaktion der Entwickler war sofort:

"Cursor fühlt sich jetzt eher wie ein Agentenorchestrator an als wie eine IDE. Die parallele Verwaltung von Agenten ist einfacher geworden."

Aber Glass ist nur ein Datenpunkt in einem größeren Trend. Terminal-UI wie cmux zeigen, wie sich die uns bekannten Schnittstellen entwickeln, um die Agentenworkflows besser zu verwalten.

Screenshot der cmux-Terminalanwendung

Von der Dateibearbeitung zum Workflowmanagement

Historisch gesehen wurden IDEs für "kompakte innere Schleifen" optimiert: Datei öffnen → bearbeiten → bauen → debuggen → wiederholen. Die These von der "Ende" der IDE ist, dass diese Schleife nicht mehr die zentrale Einheit der Produktivität ist, sobald Agenten die meisten dieser Schritte autonom ausführen können.

Die neue Schleife sieht so aus: Intention festlegen → Aufgabe zuweisen → beobachten → Unterschiede (Diffs) prüfen → zusammenführen. Der Unterschied zu "Autovervollständigung mit Chatfenster" besteht darin, dass es die Autonomie der Werkzeugnutzung hat und über Schnittstellen verfügt, die diese Autonomie kontrollierbar machen.

Sie können sehen, dass sich dieser Trend in bereits weit verbreiteten Werkzeugen abspielt. Claude Code Web (oder die Desktopversion) und Codex ermöglichen es Entwicklern, wohldefinierte Aufgaben an Agenten zu delegieren, die in einer isolierten Cloudumgebung laufen. Der Fortschritt ist im Browser sichtbar - ohne Terminal, ohne lokale Umgebungsconfiguration.

Die Agenten von GitHub Copilot können unabhängig Planungen erstellen und mehrdateienänderungen umsetzen, Branches erstellen, Tests ausführen und Pull Requests zur Prüfung einreichen. Die Hauptaufgabe der Entwickler wird die Prüfung der Ergebnisse und die Iteration, anstatt jeden Schritt zu steuern.

Conductor verfolgt einen anderen Ansatz: Eine Desktopanwendung, die mehrere Claude Code-Agenten in isolierten Arbeitsbereichen gleichzeitig ausführt und den Fortschritt aller Agenten in Echtzeit überwacht. Google's Jules hingegen behandelt asynchrone Hintergrundaufgaben - Sie weisen Aufgaben zu, es führt sie aus und Sie prüfen die Ergebnisse später.

Allen diesen Werkzeugen ist ein gemeinsames Mentalmodell gemein: Die Arbeitseinheit sind die Agenten, nicht die Dateien. Die zu optimierenden Schnittstellen sind diejenigen, die Ihnen helfen, Agenten zu steuern, zu überwachen und zu prüfen, nicht diejenigen, die Ihnen helfen, schneller zu tippen.

Die Orchestrierungsebene nimmt Gestalt an

Diese These von der "Ersetzung" der IDE wird erst überzeugend, wenn Sie bestimmte Schnittstellenmuster beobachten, die sich in verschiedenen Werkzeugen vereinheitlichen.

Arbeitsisolierung als Primitive. Parallel laufende Agenten müssen sich nicht gegenseitig stören. Fast alle seriösen Werkzeuge in diesem Bereich haben sich für git worktrees (oder ähnliche Technologien) als Lösung entschieden. Conductor ordnet jede Agentensitzung einem eigenen isolierten Arbeitsbereich zu. Vibe Kanban (wie oben gezeigt) macht dasselbe in seinem Kanban-gesteuerten Agentenworkflow. Dieses Muster ist fast überall zu finden, denn das Problem ist real: Ohne Isolierung würden parallel laufende Agenten Chaos stiften.

Planung und Aufgabenstatus als Haupt-UI. Werkzeuge wie Vibe Kanban haben "Tabs und Dateien" durch "Aufgaben und Status" als oberstes Mentalmodell ersetzt. Sie erstellen Aufgabenkarten (eine Landingpage, einen Backend-Service, eine E-Mail-Integration), weisen jede Aufgabe einem Agenten und einem Modell zu und verwalten die gesamte Arbeit wie ein leichtgewichtiges Projekt-Kanban - nur dass dieses "Team" autonom läuft. Dies ist eine Projektverwaltungs-Schnittstelle, die von Agenten umgesetzt wird.

Hintergrund-Agenten und asynchron-first-Design. Einige der interessantesten Werkzeuge in diesem Bereich lassen Sie gar nicht einmal versuchen, während der Ausführung synchron zu bleiben. Cursor, Copilot und Antigravity unterstützen Hintergrund-Agenten, die ohne Ihre Anwesenheit laufen können - Sie definieren die Intention, gehen weg und kommen zurück, um die Ergebnisse zu prüfen. Jules funktioniert ähnlich: Sie weisen Aufgaben zu und prüfen später die Codeunterschiede (Diff). Die Unterstellung ist, dass Ihre Aufmerksamkeit zu wertvoll ist, um sie mit dem Anstarren eines Fortschrittsbalkens zu verschwenden. Dies unterscheidet sich deutlich von der Echtzeit- und synchronen Rückkopplungsschleife der IDE.

Die Aufmerksamkeitsverwaltung von parallelen Agenten. Wenn viele Agenten gleichzeitig laufen, liegt die echte Engstelle darin, zu wissen, welcher Agent gerade Ihre Aufmerksamkeit benötigt. Deshalb zeigen Werkzeuge wie Conductor den Echtzeitfortschritt über alle Sitzungen hinweg, während cmux für Terminalfenster Benachrichtigungsringe und ungelesene Markierungen einführt. "Agenten brauchen Aufmerksamkeit" wird zu einem Ereignis erster Ordnung in der Entwicklerumgebung - eine Aufgabe, die geroutet und aufgeteilt werden muss, nicht nur bemerkt werden.

Agenten, die in den Software-Lebenszyklus eingebettet sind. GitHub's Copilot-Programmieragent ist asynchron, wird von der Steuerungsebene geschützt und wird von GitHub Actions angetrieben - er ist an die Art und Weise gekoppelt, wie der Code tatsächlich ausgeliefert wird (Issue → PR → CI → Zusammenführung), nicht nur an die Art und Weise, wie er geschrieben wird.

Kein Werkzeug behauptet, dass die IDE überholt ist - viele Werkzeuge interagieren weiterhin mit ihr. Aber diese wiederholten Muster (parallele Arbeitsbereiche, diffs-first-Prüfung, Aufgabenstatus, Hintergrundausführung, Lebenszyklusintegration) sind genau das, worauf die Anhänger der These von der "Ende der IDE" hinausweisen, wenn sie über die Verschiebung des Schwerpunkts sprechen.

Warum Entwickler immer noch eine IDE benötigen

Die beste Entgegnung auf die These "Die IDE ist tot" ist: Die IDE bringt immer noch mehrere wirklich schwierige Probleme in eine hochauflösende Rückkopplungsschleife: Präzises Navigieren, lokale Inferenz, interaktives Debuggen und die Fähigkeit, das System durch direkte Manipulation zu verstehen.

Selbst die ambitioniertesten Orchestrierungswerkzeuge behalten einen "Fluchtweg" für die manuelle Bearbeitung. Beispielsweise können Sie die Unterschiede innerhalb eines Threads prüfen, Kommentare zu den Änderungen abgeben und dann das Ergebnis im Editor öffnen, um manuelle Anpassungen vorzunehmen. Dies zeigt, dass die manuelle Intervention immer noch Teil des erwarteten Workflows ist.

Die Agentenwerkzeuge selbst zeigen auch die Grenzen auf. Die Mehrdateien-Refactoring in großen Repositories ist immer noch eine der größten Herausforderungen für Software-Engineering-Agenten. In diesen Szenarien sind die interaktive Code-Navigation und das menschliche Urteil immer noch am wichtigsten - Sie müssen ein globales Mentalmodell des Systems haben, das die Agenten allein aus dem Kontext nicht vollständig rekonstruieren können.

Das Fehlermuster, das Entwickler dazu bringt, weiterhin die IDE-Prüfunktionen zu nutzen, ist, dass "der Agent fast richtig liegt, aber noch etwas fehlt". Wenn etwas zu 90 % korrekt ist, aber noch kleine Fehler aufweist, ist die Kosten für das Finden der Probleme oft höher als die Kosten, es selbst zu schreiben. Für risikoreiche Änderungen ist die IDE immer noch das beste Werkzeug für eine tiefe und genaue Prüfung.

Neue Kosten: Prüfungsermüdung und Governance-Aufwand

Wenn die Entwicklung zu "parallelem Ausführen mehrerer Agenten" wird, erbt der Workflow einige Probleme, die eher der Verwaltung verteilter Systeme als der Textbearbeitung ähneln - Beobachtbarkeit, Berechtigungen, Isolierung und Governance.

Der Agentenworkflow kehrt das Arbeitsmuster um. Sie sind nicht mehr der Schreiber, sondern der Prüfer. Das klingt wie ein Fortschritt, bis Sie am Ende des Tages 12 Codeunterschiede (Diffs) von 12 parallelen Agenten anstarren. Die Prüfungsermüdung ist real, und deshalb konzentrieren sich die nachdenklichsten Werkzeuge in diesem Bereich auf die Aufmerksamkeitsrouting, strukturierte Pläne und prüfungsorientierte Schranken, anstatt standardmäßig vollständige Autonomie zu fordern.

Mit zunehmendem Zugang der Agenten zu mehr Werkzeugen, Repositories und externen Systemen erweitert sich auch die Sicherheitsfläche. Wenn Agenten das Internet durchsuchen, Datenbanken abfragen, Dateisysteme beschreiben und Bereitstellungen auslösen können, wird es genauso wichtig, was sie "erlaubt" sind, wie was sie "können".

In Bezug auf Beobachtbarkeit und Kontrolle hat das in die IDE integrierte Agentenmodell bereits die Einführung expliziter Werkzeugprotokolle und Genehmigungsschranken vorangetrieben. Sobald die Agenten asynchrone Operationen ausführen und die CI-Pipeline berühren, ist die Governance kein Luxus mehr.

Wer wird überleben: IDE, Steuerungsebene oder beides?

Eine klare Interpretation der gegenwärtigen Situation ist: Die These "Die IDE ist tot" ist in der Richtung richtig, aber als wörtliche Vorhersage falsch.

Die stärkste Version dieser These ist: Die IDE ist nicht mehr der Hauptarbeitsraum, sondern wird zu einem der untergeordneten Werkzeuge - für gezielte Prüfungen, Debugging und endgültige Bearbeitung. Die Planung, Orchestrierung, Prüfung und Agentenverwaltung werden auf Dashboards, Aufgabenverfolgungssysteme, beobachtbare Terminals und Cloud-Steuerungsebenen verlagert.

Das Konzept der "großen IDE" wird ebenfalls gut unterstützt. Die neue "IDE" ist ein System, das die Orchestrierung mehrerer Agenten, isolierte Arbeitsbereiche, Berechtigungen und Auditprotokolle, diffs-first-Prüfung, zuverlässige Werkzeugverbindungen und Aufmerksamkeitsrouting bietet. Der Dateieditor existiert weiterhin, aber er ist nicht mehr der Einstiegspunkt.

Die IDE stirbt nicht aus, sie wird "dezentralisiert". Der Schwerpunkt der Arbeit wandert nach außen - hin zu den Orchestrierungsschnittstellen, wo die Menschen die Intentionen definieren, an parallele Agenten-Umgebungen delegieren und mehr Zeit mit der Überwachung, Prüfung und Governance verbringen, anstatt auf die Tastatur zu tippen.

Die IDE ist immer noch wichtig für die Korrektheit, das Verständnis und die schwierigen Probleme, mit denen die Agenten noch Schwierigkeiten haben. Aber sie ist nicht mehr der einzige Ort, an dem man programmieren kann - und für immer mehr Menschen ist sie nicht mehr der erste Wahlort.

Übersetzer: boxi.