JetBrains packt einen Agent-Orchestrator in jede IDE, die es ausliefert

JetBrains hat am 1. Oktober den Early Access für Air in seinen IDEs geöffnet. Es ist als Plugin im JetBrains Marketplace oder gebündelt in den 2026.3-EAP-Builds von IntelliJ, PyCharm, WebStorm, Rider und dem Rest der Familie verfügbar und funktioniert ab Version 2026.2. Das Plugin ist kostenlos.

Die Einordnung ist der interessante Teil. Air ist weder ein Modell noch ein Agent. Es wird ohne installierte Agents ausgeliefert. JetBrains beschreibt es als einen Kanal für Agents und Abonnements, die ein Entwickler bereits bezahlt, und es erkennt, was bereits auf dem Rechner vorhanden ist, so wie die IDE Terminals erkennt.

Sessions statt Chat

JetBrains argumentiert, dass die gleichzeitige Orchestrierung mehrerer Aufgaben eine andere Tätigkeit ist als ein Gespräch mit einem Modell zu führen, und dass es ein Fehler war, eine einzige Oberfläche für beides zu verwenden. Klassische IDE-KI war auf Chat ausgerichtet. Air ist auf Sessions ausgerichtet.

Jede Session ist ein Agent, der an einer Aufgabe arbeitet, und die Oberfläche verfolgt sie gemeinsam: Aktivität, ungelesene Updates, geänderte Dateien, ausgehende Commits und die Kosten jeder Session in einer Ansicht. Sessions können projektübergreifend laufen, als Editor-Tabs erscheinen oder je nach Aufgabe in einem Terminal oder einem grafischen Chat bleiben. Ein Doppeltippen auf Strg an beliebiger Stelle in der IDE öffnet ein Prompt-Fenster mit dem aktuellen Kontext.

Die Isolation wird mit temporären Git-Worktrees hergestellt. Eine Session kann von jedem Branch aus starten, auf einem neuen Branch oder detached, und Ergebnisse werden per Cherry-Pick zurück in das Hauptprojekt übernommen. JetBrains sagt, dass die Ausgabe des Agents als überprüfbarer Diff innerhalb der IDE erscheint, mit denselben Werkzeugen, die ein Entwickler zum Review eines Pull Requests verwenden würde, und dass Änderungen nicht automatisch angewendet werden.

Der Protokoll-Schachzug ist der strategische Teil

Air verbindet Agents, die das Agent Client Protocol unterstützen, einen offenen Standard, den JetBrains gemeinsam mit Zed entwickelt und unter der Apache-Lizenz veröffentlicht hat. ACP verwendet JSON-RPC 2.0 über stdin und stdout, und JetBrains, Zed, Google, GitHub sowie mehr als 25 Agents haben es übernommen. Die beiden Unternehmen haben außerdem eine ACP Registry gestartet, ein auffindbares Verzeichnis kompatibler Agents, das in die IDE integriert ist.

Der einfachste Vergleich ist der mit dem Language Server Protocol. LSP ermöglichte es jedem Editor, jede Sprache über einen gemeinsamen Standard zu unterstützen, statt einer maßgeschneiderten Integration für jede Kombination. ACP will dasselbe für Agents erreichen.

JetBrains konkurriert um die Ebene, auf der Agents gestartet, überwacht und überprüft werden, statt um Modellqualität, und die Mitentwicklung des Protokolls, das regelt, wie Agents mit Editoren kommunizieren, ist ein Weg, Infrastruktur statt Feature zu sein. Die eigene Erklärung des Unternehmens ist unverblümter: Eine IDE, die Agents auf Abstand hält, wird es schwer haben, wenn agentische Entwicklung normal wird.

Zu den unterstützten Agents gehören Codex, Claude Agent, GitHub Copilot, Gemini, OpenCode und JetBrains' eigenes Junie sowie andere ACP-kompatible Tools. Ein Nutzer mit einem vorhandenen Anthropic-, OpenAI- oder Google-Schlüssel zahlt nichts an JetBrains. Für diejenigen ohne Agent-Abonnement bietet JetBrains kostenlose Junie-Lite-Ausführungen an, nachdem sie sich mit einem JetBrains-Konto angemeldet haben. JetBrains-AI-Credits beginnen bei zehn Dollar pro Monat für den Zugriff auf die unternehmenseigenen gehosteten Modelle.

Das Feature, das Cursor nicht hat

Das Alleinstellungsmerkmal, auf das JetBrains setzt, ist, dass mit Air verbundene Agents IDE-Werkzeuge als Skills aufrufen können. Ein Agent kann einen Debug-Lauf auslösen, um einen fehlschlagenden Test zu untersuchen, den Profiler ausführen oder die Refactoring-Engine mit vollständigem Multi-File-Kontext nutzen. Agents können IDE-Tools außerdem über MCP erreichen und mit strukturiertem Kontext statt eingefügtem Text arbeiten.

JetBrains sagt, dass dies bei manchen Aufgaben bessere Ergebnisse liefert und in einigen Fällen weniger Tokens verbraucht. Die Token-Behauptung stammt vom Unternehmen selbst, und es wurden keine unabhängigen Tests veröffentlicht.

Das zugrunde liegende Argument dreht sich darum, was ein Agent sehen kann. Ein Agent, der nur Dateien lesen und schreiben kann, arbeitet mit Text. Ein Agent, der eine langsame Funktion profilen und den Call Stack untersuchen kann, verfügt über den Kontext, den ein Senior-Entwickler bei der Diagnose desselben Problems hätte. JetBrains hat 26 Jahre in den Aufbau dieser Werkzeuge investiert, und Air ist das erste Mal, dass Agents Zugriff darauf erhalten.

Warum das Timing Sinn ergibt

JetBrains bringt dies in einem Moment auf den Markt, in dem der Review-Schritt zum anerkannten Engpass geworden ist. Code zu schreiben ist für viele Teams nicht mehr die Einschränkung. Zu prüfen, was geschrieben wurde, ist es.

Diese Einschätzung zeigt sich gleichzeitig im gesamten Tooling-Markt. Qodo hat in derselben Woche Version 3.0 mit Review als Kernstück veröffentlicht, und Cursor hat seinem Agent-Workflow einen Review-Bot hinzugefügt. Dass drei Anbieter zur selben Schlussfolgerung kommen, deutet darauf hin, dass sich die Einschränkung dauerhaft verschoben hat: Wenn Agents Code schneller produzieren können, als Menschen ihn lesen können, verschiebt sich der Wert auf alles, was die Lesekosten senkt.

Das Design von Air spiegelt das wider. Das Produkt behandelt parallele Agent-Sessions als Warteschlange zu überprüfender Arbeit statt als Gespräch, das gesteuert wird, und es zeigt die Kosten pro Session in derselben Ansicht wie geänderte Dateien. Für einen Engineering-Manager, der entscheidet, wie viele Agents laufen sollen, ist diese Kostenzeile die praktische Grenze.

Die Anzeige der Kosten pro Session ist ein kleines Feature mit übermäßig großer Wirkung auf das Verhalten. Ein Team, das nicht sieht, was ein lang laufender Agent kostet, neigt dazu, einen Agent vorsichtig laufen zu lassen. Ein Team, das die Zahl pro Session sieht, ist eher bereit, mehrere laufen zu lassen, weil die Entscheidung zu einer Zuteilung statt zu einem Glücksspiel wird. Das ist dieselbe Verschiebung, die bei Cloud-Ausgaben-Dashboards stattgefunden hat, und sie verändert, wie Menschen Arbeit organisieren.

Es gibt außerdem ein Koordinationsproblem, das Air zu lösen versucht. Ein Team, das Claude für eine Aufgabe, Codex für eine andere und Copilot für eine dritte laufen lässt, hat am Ende drei getrennte Oberflächen und keine gemeinsame Aufzeichnung darüber, was jede davon berührt hat. Sie in einer IDE zu konsolidieren, die bereits über Diffs, Inspektionen und Versionskontrolle verfügt, ist eine kleinere Veränderung als die Einführung eines neuen Tools, und für Teams, die auf JetBrains für Java, Kotlin oder Python standardisiert sind, vermeidet es, alle nur wegen der Agents auf einen anderen Editor zu drängen.

Was noch nicht geklärt ist

Air ist eine Early-Access-Version. JetBrains sagt, dass man mit rauen Kanten, Änderungen an UI und Verhalten sowie Updates etwa jede Woche rechnen sollte. Ein Datum für die allgemeine Verfügbarkeit wurde nicht genannt. Cloud-Ausführung für lang laufende Aufgaben ist auf Organisationen mit AI-Seats beschränkt, und JetBrains hat keine Preisangabe dafür gemacht.

Zur Privatsphäre sagt das Unternehmen, dass nichts den Rechner verlässt, wenn kein Agent angemeldet ist, und dass bei einem Drittanbieter-Abonnement Daten gemäß der bestehenden Vereinbarung an diesen Anbieter gehen und nicht über JetBrains. Das Deaktivieren des Plugins ändert nichts anderes, und der separate AI Assistant wird weiterhin unterstützt.

Die Behauptung, die es wert ist, im eigenen Repository eines Teams getestet zu werden, ist die zum Review. Air macht es einfacher, mehrere Agents gleichzeitig laufen zu lassen. Ob das mehr gemergte Arbeit oder mehr Diffs produziert, die niemand liest, ist eine empirische Frage, und sie wird im ersten Monat der Nutzung beantwortet statt in einem Launch-Post.