JetBrains Air in IDEs startet EAP, doch Orchestrierung ist die eigentliche Wette

JetBrains hat JetBrains Air in IDEs für den Early Access geöffnet und bringt fünf unterstützte Coding-Agenten in einen Arbeitsbereich für parallele Aufgaben. Dabei geht es weniger darum, einen weiteren Chatbot hinzuzufügen, als darum, wo Entwickler KI-generierten Code künftig überwachen werden.

Air unterstützt Codex, Gemini, GitHub Copilot, Claude Agent und JetBrains’ eigenes Junie direkt. Über das Agent Client Protocol, kurz ACP, eine gemeinsame Schnittstelle zwischen Coding-Agenten und Entwicklungsumgebungen, lassen sich zudem andere kompatible Tools anbinden.

Damit stellt sich JetBrains gegen eine modellzentrierte Sicht auf die Softwareentwicklung. In diesem Modell folgen Entwickler jeweils dem Agenten, der aktuell die besten Ergebnisse liefert. JetBrains setzt darauf, dass das nachhaltige Produkt die Umgebung ist, die Kontext bereitstellt, parallele Arbeit verfolgt und Menschen dabei hilft, jede Änderung zu prüfen.

Die erste Schlagzeile sprach von einem EAP, das fünf IDEs erreicht. Die aktuelle Dokumentation von JetBrains besagt nun, dass das Plugin die gesamte IDE-Produktpalette mit Ausnahme von Android Studio unterstützt und der spätere Umfang damit größer ist als zunächst dargestellt. Die wichtigere Zahl bleibt bei fünf Agenten, weil Air sie als austauschbare Arbeitskräfte innerhalb einer gemeinsamen Steuerungsoberfläche behandelt.

JetBrains fordert Entwickler nicht dazu auf, Codex, Claude, Gemini, Copilot oder Cursor aufzugeben. Stattdessen sollen diese Systeme innerhalb von JetBrains-Produkten arbeiten. Diese Unterscheidung macht JetBrains Air EAP zu einem Test dafür, ob die IDE das Zentrum der Softwareentwicklung bleiben kann, wenn Agenten einen größeren Teil der Implementierung übernehmen.

JetBrains Air in IDEs trennt Arbeitsbereich und Modell

JetBrains Air in IDEs ist eine Orchestrierungsebene, kein neues Modell und kein Ersatzname für AI Assistant.

JetBrains startete das EAP Anfang Oktober über den Marketplace und die 2026.3-EAP-Builds seiner IDEs. Die Ankündigung zu Air EAP besagt, dass das Plugin ohne installierten Agenten ausgeliefert wird und nicht als KI-Anbieter fungiert.

Dieses Design ist wichtig, weil es drei Produkte voneinander trennt, die Nutzer häufig als ein gebündeltes Erlebnis wahrnehmen. Das Modell erzeugt oder interpretiert Text. Der Coding-Agent plant Aufgaben, bedient Tools, bearbeitet Dateien und führt Befehle aus. Air organisiert diese Agenten und ihre Arbeit innerhalb der IDE.

Entwickler können Agenten anbinden, die sie bereits verwenden, vorbehaltlich der Authentifizierungsregeln des jeweiligen Anbieters. Sie benötigen kein JetBrains-AI-Abonnement, nur um einen kompatiblen Drittanbieter-Agenten auszuführen. Air kann lokal installierte Agenten erkennen, Agenten über eine Registry anbieten und unterstützte Autorisierungsmethoden wiederverwenden.

Fünf Agenten erhalten ausdrücklich erstklassige Unterstützung: Codex, Gemini, GitHub Copilot, Claude Agent und Junie. Cursor und andere Tools können über ACP-Kompatibilität eingebunden werden, wobei die genaue Schnittstelle und der Autorisierungsweg je nach Agent unterschiedlich sein können.

Das Produkt organisiert die Arbeit um Sitzungen statt um einen einzigen fortlaufenden Chat. Jede Sitzung steht für eine Aufgabe, ihren Agenten, ihren Kontext, ihren Fortschritt und die von ihr erzeugten Änderungen. Entwickler können aktive Arbeit über Projekte hinweg sehen, Sitzungen mit ausstehender Eingabe identifizieren und abgeschlossene Änderungen zur Überprüfung öffnen.

Air unterstützt außerdem Voreinstellungen. Eine Voreinstellung speichert einen Agenten, die Modellauswahl, den Reasoning-Aufwand, die Zugriffsebene und weitere Starteinstellungen. So kann ein Team unterschiedliche Konfigurationen für Routinekorrekturen, größere Refactorings, Reviews oder Experimente erstellen.

Diese Struktur macht die IDE zu einer Vermittlungsinstanz. Ein Entwickler könnte einen fehlgeschlagenen Test an Codex senden, Gemini mit Dokumentationsänderungen beauftragen und Junie bitten, ein Performance-Problem zu untersuchen. Air behauptet nicht, dass diese Agenten als kollektive Intelligenz zusammenarbeiten werden. Es gibt jeder Aufgabe einen sichtbaren Platz und hält ihre Ergebnisse innerhalb eines Review-Workflows.

Die Unterscheidung verhindert ein wichtiges Missverständnis rund um die Formulierung „führt fünf KI-Agenten aus“. Air unterstützt fünf benannte Agenten direkt, verlangt jedoch nicht, dass alle fünf gleichzeitig laufen. Es garantiert auch nicht, dass parallel arbeitende Agenten kompatiblen Code erzeugen.

Die aktuelle Air-Dokumentation von JetBrains besagt, dass lokale Agenten auf dem Rechner des Entwicklers laufen. Air kommuniziert mit ACP-kompatiblen Agenten über das Protokoll, während Kommandozeilen-Agenten ihre Terminal-Schnittstellen innerhalb der IDE beibehalten können.

Das Plugin lässt sich für Versionen 2026.2 installieren und ist in 2026.3-EAP-Builds enthalten. JetBrains dokumentiert inzwischen Unterstützung für seine IDEs mit Ausnahme von Android Studio. Verfügbarkeit, Agentenautorisierung und Cloud-Ausführung können weiterhin von der Produktversion des Nutzers und den Einstellungen der Organisation abhängen.

Diese Details machen daraus mehr als ein Distributionsupdate. JetBrains organisiert seine KI-Schnittstelle um delegierte Arbeit herum neu und hält dabei den bestehenden Editor, Debugger, Inspektionen, die Navigation und Versionskontrollwerkzeuge nah am Ergebnis.

Warum JetBrains über das KI-Chat-Panel hinausgeht

Der Druck auf JetBrains entsteht durch eine Veränderung im Verhalten von Entwicklern, nicht allein durch leistungsfähigere Sprachmodelle.

Die erste Generation KI-basierter IDE-Funktionen drehte sich um Autovervollständigung und Chat. Ein Entwickler markierte Code, stellte eine Frage, erhielt eine Antwort und entschied, was eingefügt oder angewendet werden sollte. Diese Interaktion passte gut in ein Seitenpanel.

Coding-Agenten schaffen ein anderes Verwaltungsproblem. Sie können mehrere Dateien lesen, einen Plan entwickeln, Befehle ausführen, ein Repository verändern und Tests laufen lassen, bevor sie die Kontrolle zurückgeben. Ein Entwickler kann außerdem eine weitere Aufgabe starten, während der erste Agent aktiv bleibt.

JetBrains erklärt, man habe versucht, mehr Agenten im bestehenden AI-Assistant-Chat unterzubringen. Das Unternehmen kam zu dem Schluss, dass die Überwachung paralleler Aufgaben ein Produkt erfordert, das um Arbeitsstatus statt um Gesprächsverlauf organisiert ist.

Diese Schlussfolgerung erklärt, warum Air und AI Assistant während des EAP getrennt bleiben. AI Assistant bietet weiterhin Chat, Vervollständigung, Code-Insights, Vorschläge für die nächste Bearbeitung und Agentenzugang innerhalb der etablierten IDE-Erfahrung. Air behandelt Agenten und Sitzungen als die zentralen Arbeitseinheiten.

JetBrains erwartet, dass Air im Laufe der Zeit zur primären agentischen Schnittstelle wird, hat jedoch keine Abschaffung von AI Assistant angekündigt. Nutzer können AI Assistant installiert lassen, obwohl die Installation von Air über eine AI-Assistant-Benachrichtigung das ältere Plugin deaktiviert, damit nicht beide Schnittstellen gleichzeitig laufen. Über die Plugin-Einstellungen kann es wieder aktiviert werden.

Die tieferliegende Wettbewerbsfrage betrifft die Aufmerksamkeit der Entwickler. Agentenorientierte Editoren und Kommandozeilen-Tools können Arbeit von der traditionellen IDE wegziehen. Wenn Entwickler den Großteil ihrer Zeit damit verbringen, Prompts zu erteilen und Patches andernorts zu prüfen, droht die IDE zu einem sekundären Ort für schwieriges Debugging zu werden.

Air versucht, diesen Fluss umzukehren. Statt Entwickler zur Wahl zwischen JetBrains und einem externen Agenten zu zwingen, holt es den externen Agenten in die JetBrains-Umgebung. Der Agent liefert Planung und Generierung, während die IDE Repository-Kontext und Verifizierungswerkzeuge bereitstellt.

Dieser Ansatz adressiert auch den Modellwechsel. Das führende Coding-Modell kann sich schneller ändern, als eine Organisation ihre Entwicklungsumgebung wechselt. Ein Unternehmen kann einen Agenten für Java-Migrationen, einen anderen für Interface-Arbeit und einen internen Agenten für Repositories mit eingeschränktem Code bevorzugen.

JetBrains muss nicht jedes Vergleichsergebnis mit Junie gewinnen, solange Air der Ort bleibt, an dem diese Systeme verwaltet werden. Das Unternehmen kann von stärkeren Drittanbieter-Agenten profitieren, weil diese den gemeinsamen Arbeitsbereich nützlicher machen.

Deshalb spielt ACP eine zentrale Rolle. Der ACP-Vertrag definiert eine gemeinsame Verbindung zwischen einem Client, etwa einer IDE, und einem Agenten. Der Agent behält seine eigene Modellauswahl, Tools, Authentifizierung und sein Planungsverhalten.

JetBrains vergleicht diese Grenze mit der Rolle des Language Server Protocol. Ein Editor benötigt nicht für jeden kompatiblen Language Server eine eigene private Integration. ACP soll den Bedarf an maßgeschneiderten Plugins zwischen jedem Agenten und jeder Entwicklungsumgebung reduzieren.

Die Analogie hat Grenzen. Coding-Agenten können Befehle ausführen und große Teile eines Repositorys verändern, weshalb ihre Berechtigungen und Nebenwirkungen ein höheres Risiko bergen. Dennoch reduziert eine gemeinsame Verbindungsebene den Integrationsaufwand und macht den Wechsel zwischen Agenten weniger störend.

Für JetBrains eröffnet das eine strategische Chance. Cursor, Codex, Claude, Copilot und Gemini müssen nicht auf Modellebene besiegt werden. Sie können zu Auswahlmöglichkeiten innerhalb einer JetBrains-Multi-Agenten-IDE werden.

Die IDE wird zur Steuerungsebene für Agentenarbeit

Die zentrale Wette von Air lautet, dass Verifizierung wertvoller wird, je einfacher die Codegenerierung wird.

Das Erzeugen eines Patches ist nur ein Teil der Softwareentwicklung. Jemand muss feststellen, ob der Patch die Anforderung erfüllt, die Architektur bewahrt, Tests besteht, Sicherheitsgrenzen respektiert und unter realen Bedingungen korrekt funktioniert.

JetBrains besitzt bereits viele der für diese Arbeit genutzten Tools. Seine IDEs verstehen Symbole, Typen, Referenzen, Projektstrukturen, Test-Runner, Versionskontrolle, Datenbanken, Debugger und Performance-Profile. Air verbindet die Aktivität von Agenten mit diesen bestehenden Oberflächen.

Ein Agent kann Dateien, Commits, Screenshots und wiederverwendbare Anweisungen als Kontext erhalten. Der Entwickler kann geänderte Dateien untersuchen, Diffs vergleichen, zu zugehörigem Code navigieren und das Projekt ausführen, ohne das Ergebnis in eine andere Anwendung übertragen zu müssen.

Diese Verbindung kann doppelte Erkundungsarbeit reduzieren. Ein Coding-Agent verwendet häufig Tokens darauf, Verzeichnisse aufzulisten, Konfigurationsdateien zu öffnen und relevante Symbole zu finden. Von der IDE bereitgestellter Kontext kann ihn früher zum richtigen Code führen, auch wenn die Einsparungen je nach Agent und Aufgabe variieren werden.

Air verschafft unterstützten Agenten zudem Zugriff auf IDE-Skills für Aktivitäten wie Debugging, Profiling, Datenbankerkundung und semantische Codesuche. JetBrains sagt, diese Tools könnten die Ergebnisse bei einigen Aufgaben verbessern, doch diese Behauptung benötigt noch breite Tests über Repositories und Sprachen hinweg.

Die Agentensitzung wird zum Container für diesen Workflow. Sie zeichnet den ausgewählten Agenten, die Unterhaltung, Aktivitäten, geänderte Dateien, Commits und gemeldete Kosten auf. Sitzungen können über mehrere Projekte hinweg sichtbar bleiben, sodass ein Entwickler abgeschlossene oder eingriffsbedürftige Arbeit erkennen kann.

Dieses Modell unterscheidet sich davon, fünf Chat-Tabs zu öffnen. Ein Chat-Tab bewahrt hauptsächlich eine Unterhaltung. Eine Air-Sitzung verbindet die Unterhaltung mit dem Repository-Status und Review-Aktionen.

Stellen wir uns einen Entwickler vor, der für einen Service mit einem fehlgeschlagenen Integrationstest verantwortlich ist. Eine Sitzung kann den Fehler untersuchen. Eine zweite kann eine zugehörige Abhängigkeit in einem isolierten Branch aktualisieren. Eine dritte kann die von der Änderung betroffene Dokumentation prüfen.

Der Entwickler kann im Haupt-Checkout weiterarbeiten, während diese Sitzungen fortschreiten. Wenn eine abgeschlossen ist, wird die IDE zum Ort für die Prüfung des Diffs, das Ausführen von Inspektionen, das Kontrollieren der Tests und die Entscheidung, ob das Ergebnis in den Ziel-Branch gehört.

Dieser Prozess passt zu einem umfassenderen Wandel der Engineering-Arbeit. Entwickler koordinieren zunehmend generierte Änderungen, statt jede Implementierung direkt selbst zu schreiben. Ihre Verantwortung verschwindet nicht. Sie verlagert sich auf das Spezifizieren von Aufgaben, das Bereitstellen von Kontext, die Prüfung von Nachweisen und das Lösen von Konflikten.

JetBrains positioniert die IDE als Steuerungsebene für diese Verantwortlichkeiten. Der Begriff bezeichnet eine Oberfläche, die Arbeitskräfte und Status koordiniert, ohne selbst die Arbeit auszuführen. Air muss nicht den besten Patch erzeugen, um wertvoll zu sein, wenn es mehrere Agenten leichter überwachbar macht.

Das Modell bewahrt zudem die Wahlfreiheit der Nutzer. Entwickler können, sofern der Anbieter es erlaubt, ein bestehendes Abonnement verbinden, JetBrains AI auswählen oder einen lokal konfigurierten ACP-Agenten verwenden. Air selbst stellt kein proprietäres Modell bereit.

Diese Flexibilität ist strategisch wichtig. Ein geschlossenes Arbeitsumfeld, das an ein Modell gebunden ist, übernimmt dessen Schwächen und kommerzielle Veränderungen. Ein Multi-Agent-Workspace kann Entwicklern erlauben, den Agenten auszutauschen und gleichzeitig Projektgewohnheiten sowie Review-Werkzeuge beizubehalten.

Teams, die bereits durchsuchbaren Engineering-Kontext aufbauen, dürften darin ein bekanntes Muster erkennen. Der dauerhafte Wert liegt nicht in einer einzelnen Antwort, sondern in der Struktur, die Code, Entscheidungen, Dokumente und Reviews verbindet. Eine technische Wissensdatenbank kann Agent-Sitzungen ergänzen, indem sie Informationen bewahrt, die über eine einzelne Programmieraufgabe hinaus bestehen sollen.

Air löst dieses umfassendere Wissensproblem nicht allein. Eine Sitzung enthält nützlichen Arbeitskontext, doch Teams benötigen weiterhin dauerhafte Aufzeichnungen für Architekturentscheidungen, Vorfälle und Anforderungen. Die IDE kann die Umsetzung koordinieren, während gemeinsame Wissenssysteme bewahren, warum die Umsetzung existiert.

Parallele Agenten schaffen ein Merge- und Aufmerksamkeitsproblem

Mehr Agenten steigern den Durchsatz nur, wenn Entwickler ihre Ergebnisse prüfen, zusammenführen und ihnen vertrauen können.

Air ermöglicht es Entwicklern, Sitzungen von einem Branch aus zu starten und die Arbeit in einem temporären Git-Worktree abzulegen. Ein Worktree ist eine separate Arbeitskopie, die mit derselben Repository-Historie verbunden ist. Er hält die Änderungen eines Agenten von der aktuellen Checkout-Umgebung des Entwicklers getrennt.

Diese Isolation ist für parallele Arbeit unerlässlich. Zwei Agenten, die dieselben Dateien in einem Workspace bearbeiten, können Annahmen überschreiben oder Änderungen erzeugen, die einzeln funktionieren, zusammen jedoch scheitern. Getrennte Worktrees verringern direkte gegenseitige Störungen.

Air kann das Ergebnis anzeigen und dem Entwickler erlauben, ausgewählte Commits zurück in das aktive Projekt zu übertragen. Sein dokumentierter Sitzungs-Workflow unterstützt die Prüfung von Änderungen, bevor sie per Cherry-Pick in den Ziel-Branch übernommen werden.

Isolation beseitigt die Integrationsarbeit nicht. Wenn fünf Agenten verbundene Bereiche ändern, kann der Entwickler mit fünf Branches, doppelten Änderungen, uneinheitlichen Abstraktionen und Merge-Konflikten konfrontiert sein. Jeder Agent kann ein plausibles lokales Ergebnis erzeugen, während das Gesamtsystem weniger kohärent wird.

Der Engpass verlagert sich dann von der Codeproduktion zur menschlichen Aufmerksamkeit. Ein Entwickler muss verstehen, was jeder Agent geändert hat und warum. Zudem muss er entscheiden, welche Tests aussagekräftige Belege liefern, statt eine grüne Zusammenfassung zu akzeptieren, die von demselben System erzeugt wurde, das den Code geschrieben hat.

Die Sitzungsübersicht von Air hilft dabei, diesen Arbeitsaufwand sichtbar zu machen. Sie kann aktive Sitzungen, ungelesene Aktualisierungen, geänderte Dateien, ausgehende Commits und Aufgaben anzeigen, die auf Eingaben warten. Diese Transparenz ist nützlich, kann jedoch nicht entscheiden, ob die zugrunde liegenden Entscheidungen korrekt sind.

Das ist der zentrale Zielkonflikt hinter dem JetBrains Air EAP. Parallelität kann Wartezeiten verkürzen, aber sie kann auch Review-Pflichten vervielfachen. Ein Team, das Agenten schneller startet, als es deren Arbeit prüfen kann, erzeugt lediglich eine größere Warteschlange unsicherer Patches.

Presets bringen eine weitere Governance-Frage mit sich. Sie machen Konfiguration wiederholbar, doch Teams müssen entscheiden, welche Modelle, Berechtigungen und Aufwandsstufen zu welcher Aufgabenklasse gehören. Ein Agent mit weitreichendem Zugriff, der für ein entbehrliches Test-Repository geeignet ist, kann für Produktionsinfrastruktur inakzeptabel sein.

Auch die Authentifizierung bleibt uneinheitlich. JetBrains unterstützt mehrere Wege, darunter vom Anbieter verwaltete Logins, Zugangsdaten von Drittanbietern und JetBrains AI. Ein Abonnement, das in einer Oberfläche nutzbar ist, kann jedoch denselben Agenten in einer anderen Oberfläche möglicherweise nicht autorisieren.

Claude veranschaulicht diese Komplexität. JetBrains erklärt, dass ein Claude-Abonnement über die Terminal-Oberfläche verwendet werden kann, während Claude Agent im strukturierten Chat JetBrains AI oder einen Anthropic-API-Schlüssel mit API-Abrechnung erfordert. Entwickler sollten die aktuellen Autorisierungsregeln prüfen, bevor sie Air als universellen Abonnement-Hub behandeln.

Die Cloud-Ausführung fügt weitere Grenzen hinzu. Lokale Sitzungen laufen auf dem Rechner des Entwicklers, doch berechtigte Organisationen können bestimmte Aufgaben an die JetBrains-Infrastruktur senden. Cloud-Läufe können fortgesetzt werden, nachdem die IDE geschlossen wurde, obwohl die Verfügbarkeit von Organisationseinstellungen, dem Repository-Hosting und einem JetBrains-AI-Abonnement abhängt.

Die Datenverarbeitung hängt daher vom gewählten Weg ab. JetBrains erklärt, dass Daten von Drittanbieter-Agenten bei Nutzung eines Drittanbieter-Abonnements direkt unter der bestehenden Vereinbarung des Nutzers an diesen Anbieter gehen. JetBrains AI und Cloud-Funktionen unterliegen ihren jeweils geltenden Bedingungen.

Die EAP-Vereinbarung macht auch den Reifegrad ausdrücklich. Early-Access-Software kann Fehler enthalten, sich unerwartet verhalten und während der Entwicklung ändern. Teams sollten das EAP-Label nicht als gewöhnliches Abzeichen behandeln, wenn Agenten Dateien bearbeiten und Befehle ausführen können.

Eine vorsichtige Einführung würde mit unkritischen Repositories und engen Berechtigungen beginnen. Teams sollten menschliche Reviews verlangen, wiederherstellbare Branches erhalten und unabhängige Tests vor dem Mergen ausführen. Sensibler Code benötigt eine klare Entscheidung zu Anbieter und Datenrouting, bevor ein Agent Kontext erhält.

Diese Kontrollen sind keine Argumente gegen JetBrains Air in IDEs. Sie sind die Voraussetzungen dafür, dass sein paralleles Modell nützlich wird. Orchestrierung schafft nur dann Hebelwirkung, wenn sie Verantwortung sichtbarer macht, statt sie hinter Aktivitäts-Dashboards zu verbergen.

JetBrains macht Rivalen zu austauschbaren Komponenten

Air fordert agentenorientierte Editoren heraus, indem es deren Agenten aufnimmt und zugleich die JetBrains-Entwicklungsumgebung bewahrt.

Der wichtigste Gegner ist nicht ein einzelnes Unternehmen. Es ist die Vorstellung, dass der Coding-Agent den gesamten Entwickler-Workspace besitzen sollte.

Ein agentenorientierter Editor kann jede Interaktion auf ein integriertes System ausrichten. Das schafft eine fokussierte Erfahrung, kann aber auch den Workflow des Entwicklers von der Modellweiterleitung, den Interface-Entscheidungen und dem Veröffentlichungsrhythmus dieses Produkts abhängig machen.

JetBrains vertritt die gegenteilige Position. Die IDE bleibt stabil, während Agenten innerhalb der IDE um Aufgaben konkurrieren. Entwickler können vertraute Werkzeuge für Navigation, Refactoring, Debugging und Inspektion behalten, während sie das System wechseln, das Code erzeugt.

ACP macht dieses Versprechen glaubwürdig. Ohne ein gemeinsames Protokoll würde die Unterstützung vieler Agenten eine wachsende Sammlung privater Integrationen erfordern. Jedes Anbieter-Update könnte einen Connector beschädigen oder Funktionen über Produkte hinweg uneinheitlich machen.

Mit ACP umfasst die austauschbare Einheit mehr als ein Modell. Ein Agent bringt seine Planungslogik, Werkzeuge, Berechtigungen, Modellweiterleitung und sein Interface-Verhalten mit. Air verbindet sich über eine gemeinsame Client-Grenze mit diesem vollständigen Paket.

Das gibt JetBrains eine Möglichkeit, von externer Innovation zu profitieren. Wenn Codex bei repository-weiten Änderungen besser wird, können Air-Nutzer es auswählen. Wenn Gemini für eine andere Arbeitslast besser wird, muss sich der Workspace nicht verändern. Ein interner ACP-Agent kann eingeschränkte Aufgaben übernehmen.

Die fünf genannten Agenten sind daher eine Anfangsaufstellung, keine feste Obergrenze. Codex, Gemini, GitHub Copilot, Claude Agent und Junie bieten dem EAP erkennbare Auswahlmöglichkeiten. Die Registry und die benutzerdefinierte Konfiguration erweitern die mögliche Auswahl.

Cursor ist ein aufschlussreiches Beispiel. Es konkurriert als KI-orientierte Coding-Umgebung um die Aufmerksamkeit von Entwicklern, doch sein Agent kann sich über ACP auch mit JetBrains-Produkten verbinden. JetBrains kann ein Produkt, das mit dem Wechsel von Editoren assoziiert wird, zu einem verfügbaren Mitarbeiter innerhalb der eigenen IDE machen.

Das garantiert nicht, dass Nutzer bleiben. Ein natives agentenorientiertes Produkt kann weiterhin ein kohärenteres Interface, eine schnellere Funktionsbereitstellung oder eine engere Integration mit seinem bevorzugten Modell bieten. Protokollkompatibilität macht die Erfahrung in jedem Client nur selten identisch.

Air muss auch die Komplexität der Auswahl rechtfertigen. Fünf Agenten mit unterschiedlichen Berechtigungen, Abonnements, Modi und Stärken können schwerer zu verwalten sein als ein vertrautes Werkzeug. Der Workspace benötigt klare Statusinformationen, vorhersehbare Konfiguration und vertrauenswürdige Review-Informationen.

Die eigene Produktpalette von JetBrains fügt ein weiteres Risiko hinzu. Nutzer begegnen bereits AI Assistant, Junie, Air, ACP-Agenten, Anbieter-Konten und JetBrains AI. Air schafft eine klarere konzeptionelle Trennung, doch die Übergangsphase kann sich weiterhin fragmentiert anfühlen.

Das Unternehmen versucht, dieses Problem zu lösen, indem es Air zur dedizierten Umgebung für agentische Workflows macht und AI Assistant für Chat sowie Inline-Unterstützung beibehält. Ob Nutzer diese Aufteilung verstehen und bevorzugen, wird ein zentrales EAP-Ergebnis sein.

JetBrains stellte die eigenständige Air-Umgebung zunächst als einen Ort vor, der um Agenten herum aufgebaut ist, statt als Editor mit angehängter KI. Die öffentliche Vorschau im März etablierte parallele Delegation als zentrale Idee des Produkts.

Die Übertragung dieser Erfahrung in etablierte IDEs verändert das Wertversprechen. Entwickler müssen keine separate Anwendung mehr übernehmen, um den Workflow zu testen. JetBrains kann Air über Produkte verteilen, die bereits in Engineering-Teams verankert sind.

Dieser Vertriebsvorteil ist bedeutsam, doch die Akzeptanz hängt vom täglichen Nutzen ab. Entwickler werden nicht nur deshalb ein weiteres Tool-Fenster behalten, weil es mehrere Agenten erkennt. Air muss parallele Arbeit leichter verständlich, überprüfbar und zusammenführbar machen als separate Terminals oder Anbieter-Anwendungen.

Was nach dem JetBrains Air EAP zu beobachten ist

Der nächste Test lautet nicht, wie viele Agenten Air aufführt, sondern ob Teams reale Arbeit mit weniger Kontextwechseln und beherrschbaren Review-Kosten erledigen.

Das erste Signal ist die Nutzung in gewöhnlichen Repositories. JetBrains benötigt Belege dafür, dass Entwickler Air weiter verwenden, nachdem die Neuheit paralleler Sitzungen nachlässt. Wiederholte Nutzung bei Debugging, Wartung, Tests und Refactoring würde die Orchestrierungs-These stützen.

Die nützliche Kennzahl ist nicht die Anzahl der Prompts. Teams sollten abgeschlossene Aufgaben, akzeptierte Änderungen, Review-Zeit, erneut geöffnete Fehler und den Umfang manueller Nacharbeit nach Abschluss eines Agenten untersuchen. Ein hohes Sitzungsvolumen kann Ergebnisse geringer Qualität verschleiern.

Das zweite Signal ist die Zuverlässigkeit der worktree-basierten Integration. Air sollte Branch-Status, nicht festgeschriebene Änderungen, Konflikte und Übertragungsziele eindeutig machen. Ein System für parallele Agenten muss verhindern, dass Entwickler Arbeit verlieren oder einen korrekten Patch auf den falschen Branch anwenden.

JetBrains dokumentiert Schutzmechanismen und Review-Kontrollen, doch das EAP wird zeigen, wie sie sich unter täglichem Druck verhalten. Große Repositories, generierte Dateien, Monorepos und überlappende Refactorings werden schwierigere Tests bieten als isolierte Demonstrationen.

Das dritte Signal ist die Wettbewerbsreaktion von Agent-Anbietern und konkurrierenden Editoren. Eine breitere ACP-Akzeptanz würde die Open-Workspace-Strategie von JetBrains stärken, weil Entwickler Agenten zwischen unterstützenden Clients bewegen könnten. Anbieter könnten stattdessen proprietäre Funktionen bevorzugen, die am besten innerhalb ihrer eigenen Anwendungen funktionieren.

Die Unterstützung gemeinsamer Fähigkeiten wird ebenso wichtig sein wie die Agentenzahl. Berechtigungen, Tool-Aufrufe, Kontextanhänge, Kostenberichte, Wiederaufnahme von Sitzungen und Diff-Attribution benötigen ein einheitliches Verhalten. Ein Protokoll, das viele Agenten verbindet, aber nur deren kleinsten gemeinsamen Funktionsumfang offenlegt, würde den Vorteil von Air begrenzen.

Organisationen sollten außerdem administrative Kontrollen beobachten. JetBrains erklärt, dass Unternehmen Air über verwalteten KI-Zugriff deaktivieren können, doch die Dokumentation weist darauf hin, dass die Verwaltung von IDE Services noch nicht vollständig ist. Eine Einführung im Unternehmen erfordert klare Richtlinien für Anbieter, Zugangsdaten, Cloud-Läufe, Datenrouting und Auditierbarkeit.

Die Beziehung zwischen Air und AI Assistant ist ein weiteres konkretes Signal. JetBrains zufolge wird AI Assistant weiterhin unterstützt, während Air zur bevorzugten agentischen Erfahrung wird. Künftige Releases werden zeigen, ob diese Aufteilung einfacher wird oder sich überschneidende Oberflächen hervorbringt.

Ein erfolgreicher Übergang würde Entwicklern einen klaren Ort für delegierte Aufgaben und einen anderen für leichte Inline-Hilfe bieten. Ein verwirrender Übergang hingegen würde Nutzer dazu zwingen, zu verstehen, welches Plugin für welchen Agenten, welches Abonnement oder welchen Chatmodus zuständig ist.

Die fünf unterstützten Agenten werden außerdem zeigen, ob Spezialisierung praktischen Nutzen bringt. Entwickler benötigen nachvollziehbare Gründe, Codex für eine Aufgabe und Junie oder Gemini für eine andere auszuwählen. Andernfalls wird die Auswahl zu einer administrativen Entscheidung statt zu einer Produktivitätsfunktion.

JetBrains Air in IDEs basiert letztlich auf einer tragfähigen Annahme: Generierter Code erhöht den Wert von Kontext und Prüfung. Die offene Frage ist, ob eine IDE genügend Agenten organisieren kann, ohne Entwickler zu hauptberuflichen Warteschlangenmanagern zu machen.

Probieren Sie die EAP in einem wiederherstellbaren Branch aus und geben Sie ihr eine Aufgabe, die mehrere Dateien, Tests und Prüfschritte umfasst. Vergleichen Sie anschließend den vollständigen Workflow mit Ihrem aktuellen Agenten-Setup. Hat Air Kontextwechsel reduziert, Änderungen leichter prüfbar gemacht und die Kontrolle über das Repository bewahrt? Oder hat es lediglich fünf Oberflächen in einem Fenster zusammengeführt? Die Antwort darauf, wiederholt in realen Teams, wird entscheiden, ob JetBrains Air zur Betriebsebene für agentische Entwicklung wird oder ein interessantes Experiment bleibt.