Ein Jahr lang mussten Java- und Kotlin-Teams eine unbequeme Frage beantworten: Bleiben wir in IntelliJ, oder wechseln wir für die besseren Coding Agents zu Cursor? An der Antwort hingen ein neuer Beschaffungszyklus, eine erneute Datenschutzprüfung und Wochen, in denen sich ein Team an eine fremde Umgebung gewöhnt. Seit dem 4. März 2026 ist die Frage in dieser Schärfe überholt. An diesem Tag wurde Cursor in JetBrains-IDEs verfügbar: nicht als Ersatz für den Editor, sondern als Agent im JetBrains-Chat, der sich über eine Registry installieren lässt.
Damit verschiebt sich der Fokus. Für Teams, die seit Jahren auf IntelliJ IDEA, PyCharm oder Rider standardisiert sind, geht es 2026 strategisch nicht mehr zuerst um die Wahl der IDE. Entscheidend ist, welche Agenten man in der bestehenden Entwicklungsumgebung zulässt und welche Governance-Regeln für sie gelten. Wer die Einführung im Team von Grund auf sortieren will, findet im Leitfaden für die Agent-Einführung im Team den Rahmen dazu.
Die Plattformfrage lautet 2026 nicht mehr „Cursor oder IntelliJ“. Sie lautet: Welche Agenten dürfen in derselben IDE arbeiten, wer steuert ihre Kosten und Datenflüsse, und wer kann sie wieder abschalten?
Die IDE ist kein Texteditor mit Plugins
Wer die Berichterstattung über KI-Tools verfolgt, bekommt den Eindruck, ernsthafte Entwicklungsarbeit finde in VS Code und Cursor statt. Der Stack Overflow Developer Survey 2025 stützt das für den breiten Markt: VS Code und Visual Studio liegen weltweit vorn. Das beschreibt den Gesamtmarkt, aber nicht die Realität in jedem Team.
Für viele Java-, Kotlin-, Python- und .NET-Teams sieht der Alltag anders aus. IntelliJ IDEA Ultimate, PyCharm Professional und Rider sind bezahlte, über Jahre eingerichtete Umgebungen, in denen jahrelang eingeübte Routinen stecken. Diese IDEs sind keine Texteditoren mit ein paar Plugins. Sie bringen ein semantisches Modell des Codes mit: strukturierte Refaktorierungen, Inspektionen, ein Debugger für gemischten Managed- und Native-Code, Projektmodell und Test-Runner. Ein neues Werkzeug muss an dieses Verständnis entweder herankommen oder es bewusst umgehen.
Wie viel KI in diesen Teams längst Alltag ist, zeigt die eigene Entwicklerumfrage von JetBrains, der State of Developer Ecosystem 2025: 85 Prozent der Befragten nutzen regelmäßig KI-Tools beim Programmieren, 62 Prozent mindestens einen Assistenten, Agenten oder KI-Editor. Die Zahl stammt aus einer Anbieterumfrage mit vermutlich überdurchschnittlich vielen JetBrains-Nutzern. Als Marktbeweis taugt sie nicht, als Stimmungsbild der eigenen Zielgruppe schon.
Was sich Anfang 2026 verschoben hat
Zwei Ereignisse haben die Lage für JetBrains-Teams verändert, und beide lassen sich an einem konkreten Datum festmachen.
Am 28. Januar 2026 haben JetBrains und Zed die ACP Agent Registry gestartet. ACP steht für Agent Client Protocol. Dahinter steht ein offener Standard, der Coding Agents von der IDE entkoppelt. JetBrains zieht selbst den Vergleich zu LSP: So wie das Language Server Protocol Sprachen von Editoren entkoppelt hat, entkoppelt ACP Agenten von IDEs. Die Registry ist der Katalog, über den sich diese Agenten installieren lassen.
Am 4. März 2026 hat sich Cursor dieser Registry angeschlossen und ist damit in den JetBrains-IDEs verfügbar geworden, was Cursor am selben Tag bestätigt hat. Damit kippt die alte Empfehlung. Wer Cursors Agenten nutzen wollte, musste bisher die IDE verlassen. Jetzt ist der Agent im JetBrains-Chat nutzbar.
Praktisch heißt das: Man braucht eine JetBrains-IDE ab Version 2025.3.2 und das JetBrains-AI-Plugin. ACP-Agenten lassen sich auch ohne JetBrains-AI-Abo nutzen, für einzelne Agenten kann aber ein eigenes Konto oder Abo nötig sein. Neben Cursor sind Junie, der hauseigene Agent von JetBrains, Anthropics Claude Agent und OpenAIs Codex, seit Januar 2026 im JetBrains-Chat verfügbar. So lassen sich mehrere Agenten in derselben Oberfläche nutzen und je nach Aufgabe wechseln.
Damit ist das stärkste Argument für den IDE-Wechsel 2026 deutlich schwächer, aber nicht verschwunden. Eine ACP-Anbindung bedeutet nur, dass der Agent verfügbar ist, nicht dass er denselben Funktionsumfang wie die eigenständige Cursor-IDE bietet. Indexierung, Cursor Rules, MCP-Anbindungen und einzelne Arbeitsabläufe können sich unterscheiden. Für viele Aufgaben ist der Wechsel der IDE trotzdem nicht mehr der erste Schritt.
Governance ist der eigentliche Unterschied
In deutschen Unternehmen entscheidet sich der Rollout oft nicht im Editor, sondern in der Datenschutzprüfung, in der Mitbestimmung und in der Budgetkontrolle. Genau hier hat JetBrains etwas vorzuweisen, das es im VS-Code-Umfeld nicht in dieser Geschlossenheit gibt.
JetBrains Console ist verfügbar und bietet eine organisationsweite Verwaltung: Nutzungsanalysen, gemeinsam genutzte AI-Credit-Pools, Credit-Limits, Zugriffssteuerung pro Agent und Berichte zur Nutzung im Team. Das ist der konkret verfügbare Teil für den Einkauf und die Engineering-Leitung.
Davon zu unterscheiden ist JetBrains Central, angekündigt am 24. März 2026. Central ist breiter angelegt: Governance, Identity- und Access-Management, Auditierbarkeit, Observability und Kostenzurechnung. Allgemein verfügbar war es bei der Ankündigung nicht. Geplant ist ein Early-Access-Programm ab dem zweiten Quartal 2026 mit ausgewählten Designpartnern. Console ist heute nutzbar, Central ist der größere, noch nicht eingelöste Ansatz.
In Deutschland ist das vor allem aus rechtlichen Gründen wichtig. Nach § 87 Abs. 1 Nr. 6 Betriebsverfassungsgesetz hat der Betriebsrat mitzubestimmen, sobald eine technische Einrichtung objektiv geeignet ist, Verhalten oder Leistung der Beschäftigten zu überwachen. Auf die Überwachungsabsicht des Arbeitgebers kommt es dabei nicht an. Das Bundesarbeitsgericht legt den Begriff weit aus. Viele zentral betriebene Agenten erzeugen Nutzungsdaten, Telemetrie oder Zugriffsprotokolle. Genau dort beginnt die Mitbestimmungsfrage. Ein Urteil des Arbeitsgerichts Hamburg grenzt das ein: 2024 hat es entschieden, dass die bloße Erlaubnis von ChatGPT über private Konten nicht mitbestimmungspflichtig war. Das war allerdings kein Freibrief: Die Entscheidung fiel nur so aus, weil der Arbeitgeber keinen Zugriff auf die Nutzungsdaten hatte. Der Unterschied liegt im arbeitgeberseitig bereitgestellten, überwachbaren Werkzeug, nicht in der Technologie an sich. Wer firmeneigene Agent-Accounts mit Admin-Zugriff ausrollt, sollte die Mitbestimmung früh einplanen, nicht erst nach dem Pilotprojekt.
Der organisatorische Vorteil ist größer als der technische: Wer JetBrains-Lizenzen ohnehin zentral beschafft, kann die Verwaltung der Agenten im bestehenden Lizenz- und Vertragsrahmen mitführen, ohne separaten Beschaffungszyklus. Die Vertragslage hilft dabei. Laut den AI-Nutzungsbedingungen verwendet JetBrains Eingaben, Daten, Ausgaben und Vorschläge ohne ausdrückliche Zustimmung nicht zum Training von Sprachmodellen. Dieser Trainingsausschluss ist aber nur ein Baustein, nicht die ganze Prüfung: Auftragsverarbeitung und die Übermittlung in Drittländer bleiben für jeden Anbieter gesondert zu klären. Es heißt auch nicht, dass kein Code die Organisation verlässt, denn das hängt vom gewählten Agenten und seinem Anbieter ab. Was dabei tatsächlich zu prüfen ist, zeigt der Beitrag dazu, warum nicht das Werkzeug, sondern erst sein Betrieb DSGVO-konform ist.
IntelliJ, PyCharm, Rider: drei Realitäten
Der gemeinsame Agenten-Pool ist überall derselbe. Das Anforderungsprofil je IDE ist es nicht.
IntelliJ IDEA. Der am besten unterstützte Fall. Mit ACP, Cursor und Junie können Java- und Kotlin-Teams experimentieren, ohne ihre semantische IDE zu verlassen. Eine sinnvolle, praxisnahe Aufteilung wäre folgende, ausdrücklich nicht als Benchmark-Aussage: Junie als Standard für die Arbeit am gewachsenen Monolithen, bei der die tiefe Integration in die JetBrains-Inspektionen zählt, und Claude Agent oder Cursor für Neuentwicklungen und größere dateiübergreifende Refaktorierungen. Ein unabhängiger, sprachspezifischer Benchmark, der Junie auf der JVM als objektiv beste Wahl ausweist, existiert nicht. Die Empfehlung ist eine Praxiseinschätzung, kein Messergebnis.
PyCharm Professional. Der Pool ist derselbe, das Profil ein anderes. Data-Science- und ML-Teams brauchen oft eher einen Chat, der den Projektkontext kennt: den Zustand eines Notebooks, die intern gepflegten Python-Pakete, das Datenmodell hinter einer Funktion. Das liegt näher an gezielter Assistenz als an vollautonomen Agentendurchläufen. Interessant wird PyCharm für Teams mit harten Anforderungen an die Datenresidenz, etwa in Pharma, Versicherungen und Finanzbranche. Hier ist Mellum2 der relevante Baustein: JetBrains hat das Modell am 4. Juni 2026 unter Apache 2.0 als Open-Source-Modell veröffentlicht, ein 12B-MoE-Modell mit rund 2,5 Milliarden aktiven Parametern pro Token. Mellum2 ist dabei kein fertiger Coding Agent zum Einsetzen, sondern ein Baustein für selbst betriebene Abläufe: für die Vorauswahl zwischen Modellen, die Anbindung interner Wissensquellen oder vorgelagerte Teilagenten. Ein Modell, das man selbst betreibt, verschiebt vor allem die Frage der Übermittlung in Drittländer von „Dürfen wir das nutzen?“ zu „Wie betreiben wir es?“. Rechtsgrundlage und der Personenbezug im Code bleiben davon unberührt.
Rider. Rider ist der schwierigere Fall. Gerade hier lohnt die ehrliche Einordnung. Rider 2026.1 bringt die ACP Registry sowie integrierten Zugriff auf Junie, Claude Agent und Codex, außerdem externe Agenten wie GitHub Copilot und Cursor. Wichtig ist eine Unterscheidung, die in der Praxis untergeht: Der Claude Agent in Rider über JetBrains AI ist etwas anderes als Claude Code als CLI mit JetBrains-Plugin. Anthropics eigene Dokumentation nennt Rider nicht in der Liste der unterstützten JetBrains-IDEs, und im offiziellen Claude-Code-Repository finden sich mehrere Nutzerberichte zu IDE-Erkennung und WSL-Pfaden unter Windows. Das ist kein Beweis gegen Rider, aber ein guter Grund, Claude Code als CLI mit Plugin vor einem .NET-Rollout gesondert zu testen. Die saubere Reihenfolge für .NET-Teams ist deshalb: zuerst die nativen JetBrains-Integrationen, also Junie, Claude Agent und Codex über die Registry, und erst danach der Rollout auf Claude Code CLI mit Plugin.
Was das praktisch heißt
Wer heute auf JetBrains-IDEs standardisiert ist, sollte nicht zuerst die IDE wechseln. Das Argument für einen IDE-Wechsel ist 2026 schwächer geworden, und der Wechsel kostet mehr, als er einbringt.
Stattdessen bietet sich eine knappe Reihenfolge an: zuerst die ACP Registry aktivieren, statt sich auf einen einzelnen Agenten festzulegen. Dann zwei bis drei Agenten an klar abgegrenzten Aufgaben testen, nicht organisationsweit. Parallel die Fragen klären, die hierzulande über den Rollout entscheiden: Governance, Kosten, Datenflüsse und Betriebsrat. Wo der Compliance-Druck hoch ist, gehört Mellum2 lokal auf den Prüfstand und die Console-Funktionen fest in die Planung.
Die Wahl des Agenten ist dabei kein Selbstzweck. Sie entscheidet mit, wie stark das Review-Volumen am Ende wächst, denn der eigentliche Engpass entsteht nach dem Rollout im Pull Request. Ein Agent, der dreimal so schnell schreibt, hilft wenig, wenn niemand das Ergebnis prüfen kann.
Die beste Coding-Agent-Strategie für ein JetBrains-Team fragt 2026 nicht mehr: „Welches Tool?“ Sondern: „Welche Plattform erlaubt es mir, Agenten auszuwechseln, ohne die IDE wechseln zu müssen?“ In der JetBrains-Welt ist die Antwort inzwischen unaufgeregt einfach.
Wer diese Reihenfolge auf die eigene Codebasis anwenden will, kann das im 3-Tage-Intensivworkshop oder in einer gezielten Beratung zu Rollout und Compliance tun.
