Die IDE der Zukunft

Wir befinden uns mitten in der KI-Transformation der Softwareentwicklung, und ich kann schwer einschätzen, ob wir erst bei 20 % oder schon auf halbem Weg sind. Klar ist jedoch, dass wir weitere Veränderungen erleben werden, die sich nicht nur auf Tools und Modelle auswirken, sondern auch auf Engineering-Praktiken und Überzeugungen, an die wir uns gewöhnt haben.

Ich beobachte die Entwicklung von Entwickler-Tools nun schon seit vielen Jahren und finde es faszinierend zu sehen, was derzeit aus der IDE wird. Obwohl das Konzept der IDE (Integrated Development Environment) in den letzten Jahrzehnten eine gewisse Evolution und eine Explosion an Komplexität erfahren hat, würde ich behaupten, dass es sich im Kern nicht fundamental verändert hat: Turbo Pascal aus den frühen 90er Jahren verfügte bereits über die meisten grundlegenden Konzepte heutiger IDEs: einen Code-Editor, einen Compiler, eine Build-Integration und einen Debugger. Viele andere Konzepte kamen im Laufe der Zeit hinzu, aber sie alle mussten sich in ein editor-zentriertes Weltbild einfügen.

Jetzt erleben wir eine tektonische Verschiebung. Ich wage die Prognose, dass sich IDEs grundlegend verändern werden. Und der Treiber dieses Wandels ist natürlich die Integration von Agenten in den Entwicklungsprozess. Agenten bearbeiten Dateien, aber sie nutzen Editoren nicht auf dieselbe Weise wie wir. Sie führen Code aus und debuggen ihn manchmal, aber sie nutzen dafür andere Ansätze. Und sie sind allgegenwärtig und gekommen, um zu bleiben.

Im Folgenden möchte ich die Fähigkeiten durchgehen, die eine IDE (bisher) ausgemacht haben, und aufzeigen, wie sie sich verändern. Dabei treffe ich die folgenden Annahmen, die Ende 2025 ziemlich realistisch erscheinen:

1. Der Großteil des Codes wird von Agenten geschrieben.
2. Agenten laufen parallel und müssen überwacht werden, da sie Fehler machen.
3. Der Mensch trägt weiterhin die Verantwortung für die resultierende Software.

Schauen wir uns die einzelnen Bereiche also genauer an:

Der Editor

Der Editor war bisher das zentrale UI-Element jeder IDE. Hier wird der Code zum Leben erweckt. Er bietet komplexe Syntax und andere Hervorhebungen, die die Wahrnehmung der Nutzer unterstützen und relevante Informationen gezielt hervorheben.

Wenn Agenten den Großteil der Codeänderungen vornehmen, degradiert der Editor zu einem bloßen Viewer, vielleicht mit der Option, gelegentlich eine kleine Anpassung vorzunehmen oder eine Anmerkung hinzuzufügen.

Die zentrale Agenten-Schleife

Agenten haben in diesem Jahr enorme Fortschritte gemacht, aber ihre Grundlagen haben sich kaum verändert. Ich gehe daher davon aus, dass die IDE einen Agenten-Loop enthält oder mit einem solchen kommuniziert. Dieser Loop verwaltet den Kontext, die Konversation und stellt Dateien sowie ein Terminal über sogenannte „Tools“ zur Verfügung. Wir haben einige Neuerungen beim Kontextmanagement gesehen, wie etwa die Verwaltung von Agenten-Instruktionsdateien und Skills (schrittweise entdeckbare Anweisungen für bestimmte Aufgabentypen). In diesem Bereich wird es vermutlich weitere Innovationen geben, die es Modellen ermöglichen, ihren begrenzten Kontext besser zu nutzen.

Muss dieser Agenten-Loop Teil der IDE sein oder kann es sich um eine eigenständige Produktkategorie handeln? Das ist eine berechtigte Frage, aber wir können sie auch umdrehen: Können wir uns eine nützliche IDE vorstellen, die einen Agenten-Loop nicht als fundamentalen Baustein enthält? Ich denke, die Antwort lautet Nein. Der Agent mag über ein Protokoll wie ACP mit den anderen Komponenten verbunden sein, aber er wird ein integraler Bestandteil des Entwickler-Toolings sein.

Agenten-Orchestrierung

Ein einzelner Agent ist erst der Anfang. Wir sehen bereits viele Entwickler, die mehrere Agenten gleichzeitig einsetzen, sei es für unterschiedliche Aufgaben oder manchmal für dieselbe Aufgabe. Derzeit gibt es keine gute Benutzeroberfläche zur Überwachung mehrerer unabhängiger (oder sequenzieller) Agenten, und hier besteht eindeutig Bedarf.

Integration der Versionsverwaltung

Heutige IDEs wären unvollständig ohne eine gewisse Git-Integration. Deren aktueller Workflow ist jedoch meist auf manuelle Commits, Pushs/Pulls und Merges ausgelegt. Gleichzeitig haben viele Coding-Agenten eine eigene Form von Undo-Funktionalität erfunden. Diese baut zwar manchmal auf Git auf, führt aber einen weiteren (primitiven, nicht-verzweigenden) Begriff von Historie und Änderungen ein, obwohl uns eigentlich schon ein viel mächtigeres Konzept zur Verfügung stünde.

Momentan dominiert Git den Markt vollständig, aber wir sehen bemerkenswerte konzeptionelle Vereinfachungen in Jujutsu, die uns von einigem Ballast befreien könnten, sobald es populärer wird.

In meiner Vorstellung einer zukünftigen IDE ist die Integration nahtlos: Wenn Agenten Modifikationen vornehmen, werden diese Änderungen bei jedem Konversationsschritt als Changeset getrackt, möglicherweise zusammen mit dem aktuellen Zustand der Konversation. Das würde ihre Aktionen nachvollziehbar machen und einen einfachen Weg bieten, verzweigte Agenten-Konversationen zu führen.

Bevor wir Änderungen jedoch in der unveränderlichen Ewigkeit festschreiben, werden wir selbstverständlich einen Teil der feingranularen Historie verwerfen und durch hilfreiche Zusammenfassungen ersetzen. Genauso, wie wir es bereits bei der lokalen Bearbeitungshistorie tun. Das zugrunde liegende formale System bleibt dabei jedoch stets dasselbe.

Man muss bedenken, dass die Kombination aus Versionsverwaltung und Agenten-Orchestrierung eine Form der Isolation zwischen den Agenten auf Dateisystemebene erfordert. Einige nutzen dafür heute separate Git-Worktrees, aber das ist weit entfernt von einer guten User Experience: Wenn ich das tue, möchte ich alle Änderungen sofort in einem Revisionsgraphen sehen. Ich möchte in der Lage sein, heranzuzoomen und zu sehen, was jeder Agent gerade tut, und ich möchte die von jedem Agenten produzierten Änderungen direkt im Editor sehen. Ich erwarte von einer IDE, dass sie mich dabei unterstützt.

Sprachintegration

Eine IDE muss die Programmiersprache verstehen, um Navigation und kontextbezogene Bearbeitungsschritte zu ermöglichen, die auf Sprachabstraktionen basieren. Frühe IDEs mussten ihre eigenen internen Abstraktionen bauen, aber vor kurzem wurde dies über das LSP-Protokoll an Sprachserver (Language Server) ausgelagert. Das Gute daran ist, dass diese Sprachserver wahrscheinlich auch in der nächsten Generation von IDEs wiederverwendet werden können.

Auch Agenten werden sprachspezifische Tools nutzen: Einige Agenten-Werkzeuge (z. B. opencode) bieten solche Integrationen schon länger, und nun folgt Claude Code. Ich schätze also, dass bald alle Agenten Sprachserver unterstützen werden. Ich kann mir auch Erweiterungen für LSP vorstellen, die besser mit Agenten als Clients funktionieren. Es ist gut möglich, dass eine fortgeschrittene Integration von Sprachservern auch voraussetzt, dass wir die Modelle darauf trainieren, diese neuen agentischen Fähigkeiten besser zu nutzen. Es fällt jedoch schwer, sich eine Zukunft vorzustellen, in der grundlegende Refaktorisierungen in Form von atomaren Textbearbeitungen anstatt als echte, semantische Refaktorisierungsoperationen auf dem Code formuliert werden.

Tool Integration

Das Integrieren der unterschiedlichsten Tools zum Bauen, Prüfen, Testen, Packen und Deployen macht das „I“ in IDE aus. Es macht Entwickler produktiv, indem es die verschiedenen Werkzeuge in einer kohärenten, effizient bedienbaren Benutzeroberfläche zusammenführt.

Diese Integration muss nun für Agenten neu gedacht werden, da diese eine textbasierte Interaktion gegenüber Tastatur und Maus bevorzugen. Ich sehe hier die Chance, diese Form von Entwickler-Tooling in einem völlig neuen Licht zu betrachten. Einige Primitive sind immer gleich: Das Überwachen von Dateien und das automatische Neuerzeugen abgeleiteter Artefakte, wenn sich etwas ändert (wobei ein abgeleitetes Artefakt auch ein Testbericht sein kann). Oder das Anreichern des Quellcodes mit zusätzlichen Informationen (z. B. aus statischen Analysen oder Tests). Wir benötigen eine einheitliche Laufzeitumgebung für diese Dinge, die erweiterbar und für Agenten leicht zugänglich ist.

Auch die Werkzeuge selbst müssen sich verändern. Die Ausgabe sollte textbasiert, gut strukturiert und vor allem prägnant sein, um den Agenten nicht mit zu viel Müll in ihrem Kontext zu überlasten. Momentan ordne ich das unter dem Begriff „Agent Developer Experience“ ein: Tools müssen einfach zu bedienen sein, prägnantes und selbsterklärendes Feedback liefern und sie müssen schnell sein, denn wir werden sie in geschlossenen Schleifen laufen lassen wollen, um unseren Agenten direktes Feedback zu geben.

Review Support

Ja, wir werden Software reviewen, die von Agenten geschrieben wurde. Aber dieses Review wird nicht immer auf Basis eines klassischen Text-Diffs zwischen zwei Revisionen stattfinden, wie es heute üblich ist. Das werden wir zwar gelegentlich tun, aber unser Review sollte sich primär auf die High-Level-Bausteine konzentrieren, auf deren Beziehungen zueinander und darauf, wie sich die Änderung auf die strukturellen Eigenschaften unserer Software sowie auf ihr durch Tests beschriebenes Verhalten auswirkt.

Reviews auf architektonischer Ebene sind bisher weitgehend unerforschtes Terrain, zumindest in der Industrie. Wie fasst man Codeänderungen prägnant zusammen (ohne einfach blind auf ein LLM zurückzugreifen, das Änderungen übersehen oder falsch darstellen könnte)? Wie visualisiert man strukturelle Veränderungen, wie etwa geänderte Abhängigkeiten zwischen Modulen? Wie zeigt man, wie Code wiederverwendet oder entkoppelt wurde? Ich hoffe sehr auf Innovationen in diesem Bereich, denn wir werden sie dringend benötigen, um auf einer höheren Abstraktionsebene arbeiten zu können.

Agenten-Isolation und Sandboxing

Unsere neue Agenten-Realität bringt eine massive Einschränkung mit sich: Agenten sind gleichzeitig intelligent und dumm und anfällig für Prompt-Injection-Angriffe. Insbesondere die Kombination aus dem Zugriff auf unvertrauenswürdige Inhalte, dem Zugriff auf Code und potenziell private Daten auf dem Entwicklungsrechner sowie der Tatsache, dass Daten relativ leicht exfiltriert werden können (diese Kombination wurde als „Lethal Trifecta“ – das tödliche Trio – bezeichnet), macht das gesamte Setup sehr verwundbar. Zudem ist das Generieren und anschließende Ausführen von beliebigem Code mit den Rechten des Entwicklers und Zugriff auf dessen lokalen Daten ein Rezept für eine Katastrophe.

Derzeit gibt es nur zwei valide Ansätze. Der eine besteht darin, jede einzelne Aktion des Agenten manuell genauestens zu prüfen, was jedoch schnell zu einem neuen, nervigen Bottleneck und Frustrationsquelle wird. Der andere Ansatz ist, den Agenten mittels Sandboxing mit so wenig Rechten und Datenzugriffen wie möglich laufen zu lassen. Wir wollen, dass der Agent nur begrenzten Zugriff auf das Dateisystem hat, um ihm genau den Code zu geben, den er braucht – aber eben nicht die anderen Dinge auf der Festplatte des Nutzers, wie persönliche Informationen, API-Keys usw. Wir wollen auch in der Lage sein, den Internetzugang für den Agenten einzuschränken, was den Zugriff auf (potenziell bösartige) Daten da draußen unterbindet und Exfiltrationskanäle blockiert.

Da wir postuliert haben, dass die IDE der Zukunft Agenten verwaltet und orchestriert, muss sie sich auch um das Sandboxing kümmern. Eine Agenten-Definition wird dann nicht mehr nur Anweisungen und Tool-Definitionen enthalten, sondern auch Zugriffsberechtigungen und Isolationskonfigurationen. Wir müssen dann in der Lage sein, über die verschiedenen Agententypen und ihre Eigenschaften zu urteilen, um die Sicherheit des gesamten agentischen Prozesses abzuleiten.

Ausführung in der Cloud

Die erfolgreichsten Coding-Agenten laufen derzeit lokal auf dem Rechner des Entwicklers. Die Idee einer IDE in der Cloud ist jedoch nicht neu. Bisher hat sie sich nie so richtig durchgesetzt, und ich kann nur mutmaßen, warum. Die Kombination aus guter Bereitstellungslatenz, einer performanten Maschine (vergleichbar mit einem guten Entwickler-Laptop) und wettbewerbsfähigen Kosten ist schwer hinzubekommen und das Portieren einer traditionellen IDE in die Cloud ist ebenfalls alles andere als trivial.

Wenn wir uns jedoch in ein Terrain bewegen, in dem Agenten autonom für ein paar Stunden laufen (aktuelle Forschungen legen nahe, dass wir dies erwarten können, wenn wir den aktuellen Kurs beibehalten), dann ist das lokale Ausführen nicht mehr praktikabel. Wir werden den Prozess in die Cloud verlagern wollen, in eine vordefinierte Laufzeitumgebung, die auch das notwendige Sandboxing bereitstellt.

Neben den technischen Herausforderungen ist dies ein konzeptioneller Wandel: Traditionell hatten wir eine Trennung zwischen der lokalen Entwicklung auf dem Rechner des Entwicklers und einer CI, die auf einem Server lief. Der Wechsel zwischen beiden Welten wurde durch die Versionsverwaltung vermittelt. In einem zukünftigen Szenario sehe ich diese Unterscheidung zwischen lokal und Server verschwinden. Stattdessen entstehen drei neue Schleifen (Loops), basierend darauf, wessen Aufmerksamkeit sie erfordern:

Die innere Schleife: Wird autonom von einem Agenten ausgeführt. Der Agent interagiert mit der Codebasis sowie den Tools und entscheidet selbst, wann er glaubt, fertig zu sein. Er kann auch automatisches Feedback von spezialisierten Feedback-Agenten und deterministischen Tools wie Tests und Lintern erhalten.

Die mittlere Schleife: Wird vom Entwickler gesteuert, der für diesen spezifischen Satz an Änderungen verantwortlich ist. Er leitet und überwacht die Agenten und trifft Richtungsentscheidungen bezüglich Design und Umfang der jeweiligen Aufgabe.

Der äußere Schleife: Betrifft andere Teammitglieder, typischerweise in Form von Reviews, Merges oder Ritualen wie Sprint-Reviews. Dies ist naturgemäß der langsamste Prozess.

Die IDE der Zukunft muss alle drei Schleifen unterstützen, darf aber die genutzten Prozesse, insbesondere im Outer Loop, nicht starr diktieren.

Was können wir erwarten?

Wir sehen einige dieser Elemente bereits heute, aber man kann das Gesamtpaket noch nicht als fertiges Produkt herunterladen oder kaufen. Das ist auch völlig in Ordnung, da noch viele Details ausgearbeitet werden müssen und nicht alles, was mir bei einem Spaziergang einfällt, auch praktisch umsetzbar sein wird. Wir sehen jedoch zweierlei:

1. Die Produktkategorie der IDE erhält ein monumentales Update. Es ist völlig unklar, ob die bestehenden Player (JetBrains, ich schaue in eure Richtung) sich rechtzeitig neu erfinden können, um in der nächsten Generation eine Rolle zu spielen. Agenten sind jedenfalls nicht einfach nur ein weiteres IDE-Plugin, das in einer Seitenleiste lebt.
2. Die IDE wird nicht zu einer simplistischen Terminal-Anwendung schrumpfen, wie wir es derzeit an vielen Stellen sehen. Sie bleibt ein komplexes Integrationsprodukt, das KI-Agenten, spezialisierte GUIs und Systemintegration miteinander verbindet.

In einem solchen System kann ich mir vorstellen, den Revisionsgraphen zu öffnen und drei aktive Agenten-Branches zu sehen, jeder mit eigenem Diff, Testergebnissen, verbrauchtem Budget und zugewiesenen Berechtigungen. Nachdem ich die architektonischen Auswirkungen visualisiert und geprüft habe, dass es keine unerwarteten Abhängigkeiten gibt, und nachdem ich festgestellt habe, dass die Tests die Eigenschaften abdecken, die ich sehen möchte, übernehme ich einen Branch und fasse die Provenienz zu einem Review-Changeset zusammen, das ich später mit einem Teamkollegen besprechen werde. Einen anderen Branch pushe ich direkt, da es sich um eine einfache Änderung handelt, und den dritten verwerfe ich, weil er nicht meinen Annahmen entsprach. Aus dem fehlgeschlagenen Versuch habe ich dennoch etwas gelernt, und diese Erkenntnis ergänze ich in meinem kompakten Spezifikationsdokument, das den Agenten beim Neustart eines weiteren Versuchs anleiten wird.

Ich freue mich darauf, diese neue Generation von IDEs zu nutzen. Bis dahin müssen wir uns mit den einzelnen Bausteinen behelfen, die mithilfe eigener Skripte zusammengefügt werden, wobei wir einige Bestandteile klassischer IDEs wiederverwenden.

Sebastian Macke hat wertvolle Anregungen und Gedanken beim Review eines Entwurfs dieses Artikels geliefert.