JetBrains Air einrichten: Sicher mit Coding-Agenten starten

Mit JetBrains Air lässt sich direkt in einer JetBrains-IDE ein Coding-Agent starten, gezielt mit Projektkontext versorgen und seine Arbeit dort prüfen, wo Code ohnehin bearbeitet und getestet wird. Für den Einstieg empfiehlt sich keine groß angelegte Refaktorierung. Installieren Sie Air Alpha, verbinden Sie einen Agenten, übergeben Sie ihm eine Datei und einen fehlgeschlagenen Test – und übernehmen Sie erst dann etwas, wenn Diff und Testergebnis nachvollziehbar sind.

Der schnelle Einstieg

JetBrains Air dient als Kontrollzentrale für Agenten, nicht als Autocomplete-Schaltfläche. Der Agent erledigt die Arbeit; Air bündelt die Sitzung, übermittelt den IDE-Kontext und bringt das Ergebnis in eine IDE-native Prüfoberfläche zurück.

Für die erste Sitzung reichen diese Schritte:

1. Installieren Sie Air Alpha über den IDE Marketplace.
2. Öffnen Sie ein leicht zurücksetzbares Projekt oder einen entsprechenden Branch mit einem ausführbaren Test.
3. Wählen Sie unter New Session eine Voreinstellung und bleiben Sie bei Standard Access.
4. Senden Sie die erste Nachricht und schließen Sie bei Bedarf die Anmeldung ab.
5. Hängen Sie die relevante Datei mit @file: an.
6. Beauftragen Sie eine kleine Korrektur samt Test.
7. Prüfen Sie unter Agent Sessions jede geänderte Datei.
8. Führen Sie den Test selbst aus und entscheiden Sie danach, ob Sie die Änderung behalten, bearbeiten, committen oder zurücksetzen.

Damit ist der entscheidende Ablauf vollständig. Parallele Sitzungen, weitere Agenten, Organisationskontrollen und die Übergabe an die Cloud können warten, bis dieser Prozess zuverlässig funktioniert.

Was ist JetBrains Air eigentlich?

Air bildet die Schicht zwischen einem JetBrains-Projekt und einem oder mehreren Coding-Agenten. Man kann es sich wie den Prüfstand einer Modellbauwerkstatt vorstellen: Ein Agent legt ein vorgeschlagenes Bauteil vor, doch die IDE liefert weiterhin Maße, Passproben und die Grundlage für die endgültige Entscheidung.

Mit dem Release vom 22. September wurde Air zu einem breiteren System mit drei benannten Bestandteilen: Air in JetBrains IDEs für die individuelle Arbeit, Air Teams für Koordination und Automatisierung sowie Air Governance für Richtlinien, Transparenz und Kostenkontrolle. Dieser Leitfaden konzentriert sich auf den lokal ausführbaren Weg mit dem Air Alpha IDE plugin.

Das IDE-Plugin ist kein neues Basismodell. Es kann Codex, Gemini, GitHub Copilot, Claude und Junie ohne zusätzliche Einrichtung ausführen; laut JetBrains lassen sich weitere Agenten über ACP anbinden. ACP, kurz für Agent Client Protocol, ist eine gemeinsame Schnittstelle zwischen IDE und vollständiger Arbeitsumgebung eines Agenten – einschließlich seiner Tools und Modellweiterleitung.

Auf der aktuellen Air-Seite für IDEs ist die Übergabe lokaler Sitzungen an die Cloud weiterhin als „coming soon“ gekennzeichnet. Für einen verlässlichen ersten Durchlauf sollte die Aufgabe klein und lokal bleiben.

Was vor der Installation zu prüfen ist

Air Alpha ist eine öffentliche Alpha-Version, kein unauffälliges stabiles Werkzeug. JetBrains weist darauf hin, dass sich Oberfläche und Verhalten ändern können und ungefähr wöchentliche Updates zu erwarten sind. Bevor die Fehlersuche beginnt, sollte daher zuerst die Kompatibilität geprüft werden.

Am 23. September 2026 war für die Produktlinie 2026.2 im Marketplace das Paket Air 262.8665.463 aktuell. Es unterstützt IntelliJ IDEA 2026.2 bis 2026.2.3 sowie die entsprechenden 2026.2-Versionen der aufgeführten JetBrains-IDEs. Im Marketplace gibt es außerdem Builds für die Produktlinie 2026.3; der genaue Plugin-Build kann deshalb je nach IDE-Zweig abweichen.

Kompatibilitätsprüfung in diesem Test

IntelliJ IDEA 2026.2.3, Build IU-262.10968.63, lud Air 262.8665.463 in einem isolierten Profil und indizierte ein entbehrliches Node-Projekt ohne Plugin-Fehler. Als Agent wurde codex-cli 0.153.4 erkannt, er war jedoch abgemeldet und der Host verfügte über keine grafische Sitzung. Ein interaktiver Air-Auftrag, ein erzeugter Diff oder ein erfolgreicher, vom Agenten geschriebener Test werden hier ausdrücklich nicht behauptet. Die folgenden Schritte orientieren sich am aktuellen JetBrains-Quickstart und an den Bezeichnungen, die in diesem Plugin-Build enthalten sind.

JetBrains Air installieren und Schritt für Schritt nutzen

1. Air Alpha installieren

Öffnen Sie die IDE-Einstellungen, wählen Sie Plugins, wechseln Sie zu Marketplace, suchen Sie nach Air Alpha und klicken Sie auf Install. Starten Sie die IDE neu, falls sie dazu auffordert.

Air selbst ist kostenlos. Für den dahinterliegenden Agenten können dennoch ein Konto, ein Abonnement oder eine API-Abrechnung erforderlich sein. Falls die Kostenfrage die Entscheidung blockiert, trennt Ist JetBrains Air kostenlos? die Plugin-Kosten von den Kosten des Agenten.

2. Ein Projekt mit einem leicht überprüfbaren Fehler öffnen

Beginnen Sie mit einem vorhandenen Projekt, das sich problemlos verwerfen oder zurücksetzen lässt. Eine gute erste Aufgabe betrifft genau eine relevante Datei, hat einen klar beobachtbaren Fehler und einen einzelnen Befehl, der den Erfolg der Änderung belegt.

Geeignet sind etwa eine Slug-Hilfsfunktion, die wiederholte Leerzeichen falsch behandelt, ein Formatierer mit einer fehlenden Randfallbehandlung oder eine kleine Validierungsfunktion mit einem fehlgeschlagenen Unit-Test. Migrationen, Authentifizierung, Deployment-Code und umfassende Abhängigkeitsaktualisierungen gehören nicht in den ersten Durchlauf.

Halten Sie vor dem Start der Sitzung den Ausgangszustand fest:

• den aktuellen Branch oder den entbehrlichen Worktree;
• den genauen Testbefehl;
• ob dieser Test derzeit erfolgreich ist oder fehlschlägt;
• welche Dateien voraussichtlich geändert werden müssen.

So wird die Prüfung zu einem Vergleich statt zu einer Bauchentscheidung.

3. Eine New-Session-Voreinstellung wählen

Die Schaltfläche New Session in der Hauptsymbolleiste startet die aktuell gewählte Voreinstellung. Über den zugehörigen Pfeil lässt sich eine andere auswählen.

Eine Voreinstellung ist eine gespeicherte Startkonfiguration. Sie legt den Agenten fest und kann Modell, Reasoning-Aufwand, Zugriffsstufe und Sitzungsoberfläche vorgeben. Air zeigt auf dem Rechner erkannte Agenten neben den integrierten Voreinstellungen an. Fehlt der ausgewählte Agent, kann das Plugin dessen Installation anbieten.

Für die erste Aufgabe empfiehlt sich Standard Access. In der aktuellen Plugin-Version darf der Agent damit innerhalb des Projekts lesen, bearbeiten und Befehle ausführen; für Dateien außerhalb des Projekts oder Netzwerkzugriffe ist eine Genehmigung nötig. Full Access hebt diese Rückfragen für die Netzwerknutzung und Änderungen an beliebigen Stellen des Rechners auf. Als Standardeinstellung für die erste Sitzung ist das ungeeignet.

4. Die erste Nachricht senden und den Agenten autorisieren

Die Autorisierung beginnt erst, wenn der Agent sie tatsächlich benötigt. Schreiben Sie eine kurze erste Nachricht und drücken Sie die Eingabetaste. Findet Air bereits auf dem Rechner verwendete Zugangsdaten des Agenten, läuft die Sitzung weiter. Andernfalls erscheint Choose a sign-in method to continue.

Der verfügbare Weg hängt vom Agenten ab:

• Eine Agentenanmeldung kann im Browser oder Terminal fortgesetzt werden.
• Eine berechtigte JetBrains-AI-Lizenz oder ein Organisations-Workspace kann Credits bereitstellen.
• Add an AI provider öffnet Tools | Air | Accounts, um ein Drittanbieter-Abonnement oder einen API-Schlüssel zu hinterlegen.

Wählen Sie unter Accounts die Option More Providers, tragen Sie die erforderlichen Zugangsdaten ein, prüfen Sie die Verbindung über Test Connection, speichern Sie mit OK und kehren Sie anschließend zur Sitzung zurück, um den Anbieter auszuwählen.

Fügen Sie niemals ein Geheimnis in den Aufgaben-Prompt ein. Zugangsdaten gehören in den vorgesehenen Verbindungsdialog des Anbieters.

5. Nur den wirklich benötigten Kontext hinzufügen

Über die Kontextsteuerung kann Air Dateien, Commits und Skills anhängen. Alternativ lässt sich mit @file: eine Datei oder mit @folder: ein Ordner angeben. Der Unterschied ist entscheidend: Eine relevante Datei anzuhängen gleicht der Übergabe eines defekten Bauteils an die Werkstatt; das gesamte Repository anzuhängen heißt, die komplette Garage auf der Werkbank auszuleeren.

Für den ersten Durchlauf genügt die Implementierungsdatei zusammen mit dem Testbefehl. Eine Testdatei sollte nur hinzukommen, wenn der Agent ein bestehendes Muster verstehen muss.

6. Eine klar begrenzte Änderung mit Nachweis beauftragen

Ein guter Prompt benennt den Fehler, den erlaubten Umfang und den Prüfungsbefehl. Zum Beispiel:

Korrigiere die Verarbeitung wiederholter Leerzeichen in @file:src/slug.js. Ergänze oder aktualisiere den kleinsten relevanten Test. Führe node --test aus. Ändere keine Abhängigkeiten und fasse keine nicht beteiligten Dateien an. Falls sich der Testbefehl nicht ausführen lässt, halte an und erkläre den Grund.

Dieser Prompt gibt dem Agenten eine klare Ziellinie. „Verbessere diese Hilfsfunktion“ tut das nicht.

7. Die Sitzung verfolgen, aber nicht den Fortschrittsbericht bewerten

Der Agent meldet seinen Fortschritt und stellt möglicherweise Rückfragen. Ergänzen Sie fehlende Anforderungen, genehmigen Sie nur nachvollziehbare Aktionen und achten Sie besonders auf unerwartete Netzwerkanfragen oder Zugriffe außerhalb des Projekts.

Der Fortschrittstext liefert hilfreichen Kontext, ist aber kein Nachweis. Entscheidend sind der entstandene Diff und ein Test, der sich unabhängig wiederholen lässt.

8. Die Änderung in Agent Sessions prüfen

Öffnen Sie Agent Sessions und klappen Sie die abgeschlossene Sitzung auf. Sehen Sie sich für jede geänderte Datei den Diff an. Das aktuelle Paket enthält die Aktionen Show Diff, Generate summary... und Revert. Laut JetBrains-Quickstart lassen sich die geänderten Dateien behalten, bearbeiten, committen oder zurücksetzen.

Die Prüfung sollte in dieser Reihenfolge erfolgen:

1. Umfang: Wurden ausschließlich die erwarteten Dateien geändert?
2. Verhalten: Behebt die Implementierung genau den beschriebenen Fehler?
3. Testqualität: Würde der neue Test ohne die Korrektur fehlschlagen?
4. Nebenwirkungen: Haben sich Konfiguration, Abhängigkeiten oder öffentliche Schnittstellen verändert?
5. Verifikation: Ist der Test erfolgreich, wenn Sie ihn unabhängig vom Bericht des Agenten ausführen?

Ist der Diff fast richtig, korrigieren Sie ihn selbst oder geben Sie präzises Feedback für einen weiteren Durchlauf. Überrascht der Umfang, setzen Sie die Änderung zurück und beginnen Sie mit einem enger gefassten Prompt neu. Eine plausibel klingende Erklärung ist kein Grund für einen Commit.

Die Kostenrechnung für Unternehmen

Air verändert die Kostenposition für die Orchestrierung, nicht den Preis der dahinterliegenden Intelligenz. Das Plugin selbst verursacht $0 Softwarekosten; der verbundene Agent kann dagegen ein bestehendes Abonnement, API-Guthaben oder JetBrains-AI-Credits beanspruchen.

Das ist relevant, wenn ein Team bereits für Agenten bezahlt. Eine zweite Kontrolloberfläche bedeutet oft einen zusätzlichen Lizenzplatz, noch bevor feststeht, ob sie die Prüfung verbessert. Als öffentlicher Vergleichswert nennt GitHub derzeit $19 pro Nutzer und Monat für Copilot Business sowie $39 für Enterprise. Zehn Business-Lizenzen kosten $190 pro Monat, zusätzliche Nutzung noch nicht eingerechnet. Air kann unterstützte Agenten ohne zusätzliche Plugin-Gebühr anbinden, beseitigt aber weder IDE-Lizenz und Anbieterabonnement noch API-Nutzung oder menschliche Prüfzeit.

Die praktische Budgetfrage ist daher eng umrissen: Kann eine kostenlose lokale Prüfoberfläche vorhandene Agentenausgaben besser steuerbar und überprüfbar machen? Das sollte zunächst mit einem Team und einer einzigen Aufgabenklasse getestet werden, bevor weitere Käufe oder Standards folgen.

Sechs Anwendungsfälle – sortiert nach dem größten Nutzen

1. JetBrains-Teams, die bereits mehrere Agenten bezahlen

Ein Entwicklungsteam, das Codex für einen Aufgabentyp und Claude für einen anderen nutzt, kann beide aus derselben IDE-Umgebung starten, denselben Projektkontext anhängen und geänderte Dateien zentral prüfen. Der Vorteil sind nicht automatisch günstigere Tokens, sondern weniger Werkzeugwechsel und eine einheitliche Prüfroutine für bereits vorhandene Abonnements.

2. Maintainer mit kleinen, testbaren Fehlern

Ein Maintainer kann die fehlerhafte Hilfsfunktion anhängen, eine einzelne Regression beschreiben, einen fokussierten Test verlangen und den erzeugten Diff prüfen, bevor er einen Branch erreicht. Das lohnt sich, wenn die Diagnose feststeht, die mechanische Korrektur aber Zeit für anspruchsvollere Arbeit bindet.

3. Beratende in einer unbekannten Kunden-Codebasis

Wer neu in eine Kunden-Codebasis einsteigt, kann über die Code-Navigation der IDE Symbole untersuchen, nur die relevanten Dateien anhängen und einen Agenten mit einer eng begrenzten Änderung beauftragen. Die Arbeit in einem entbehrlichen Branch mit Standard Access senkt das Risiko, dass unbekannte Repository-Konventionen in ausufernde Änderungen münden. Der Nutzen liegt in schnellerer Orientierung – ohne vorzugeben, der Agent kenne unausgesprochene Regeln des Kunden.

4. QA-Fachleute, die einen reproduzierbaren Fehler in einen Regressionstest überführen

Wer einen Fehler reproduzieren kann, hängt die betroffene Datei und den relevanten Testbereich an, fordert den kleinsten passenden Regressionstest an und prüft, ob dieser das Problem tatsächlich erfasst. So verkürzt sich der Weg von der Reproduktion zu einem prüfbaren Entwicklungsartefakt.

5. Senior-Entwickler, die Review anhand konkreter Diffs vermitteln

Ein Senior-Entwickler kann einen Agenten eine kleine Implementierung vorschlagen lassen und anschließend mit einem weniger erfahrenen Teammitglied Umfang, Annahmen, Testdesign und Entscheidungen zum Zurücksetzen in der vertrauten IDE durchgehen. Das Ergebnis ist nicht nur Code, sondern eine sichtbare Review-Übung an einem echten Änderungssatz.

6. Plattformteams, die Agenten an derselben Aufgabe vergleichen

Ein Plattformteam kann dieselbe begrenzte Aufgabe mit unterschiedlichen Voreinstellungen ausführen und geänderte Dateien, Testverhalten, Freigaben und Prüfaufwand vergleichen. Das liefert eine aussagekräftigere Bewertung als der Vergleich von Chat-Antworten, denn beurteilt wird eine verifizierte Änderung im selben Repository.

Zwei Produkte, die sich darauf aufbauen lassen

1. Ein Review-Evidence-Sidecar für Änderungen von Agenten

Hier liegt die stärkere Chance. Denkbar ist ein kleines Begleitwerkzeug, das eine Agentensitzung in ein Prüfprotokoll überführt: Aufgabe, angehängter Kontext, geänderte Dateien, Testbefehl, Testergebnis, menschliche Entscheidung und Referenz des finalen Commits. Engineering-Führungskräfte und regulierte Teams würden für eine saubere Dokumentation bezahlen, die unabhängig vom erzeugenden Agenten funktioniert.

Die Nachfrage ist konkret genug, um relevant zu sein: ai powered code review platform erzielt in den USA etwa 1,900 Suchanfragen pro Monat und hat kommerzielle Suchintention. Die GitHub-Preise von $19 für Business und $39 für Enterprise zeigen zudem, dass Teams bereits Budgets für Coding-Unterstützung und Governance einplanen.

Die kleinste verkaufsfähige Version muss den Agenten nicht steuern. Sie kann einen Diff und eine Testausgabe einlesen, eine Reviewer-Checkliste verlangen und einen signierten Markdown- oder JSON-Nachweis exportieren. Das Risiko liegt in der Plattformabhängigkeit: Air ist eine Alpha-Version, seine Schnittstellen können sich wöchentlich ändern und JetBrains könnte selbst umfangreichere Nachweis- oder Audit-Funktionen ergänzen. Der Schutzwall muss aus agentenübergreifenden Richtlinien und dauerhaftem Reporting bestehen, nicht aus einer dünnen Schaltfläche in einer einzigen IDE.

2. Ein Repository-spezifischer Einrichtungsassistent für Agenten

Ein solches Onboarding-Werkzeug untersucht Sprachen, Testbefehle, sensible Pfade und Beitragsregeln eines Repositorys und empfiehlt daraus eine sichere Vorlage für die erste Aufgabe samt passenden Voreinstellungen. Abnehmer wären Teams, die Agenten in unterschiedlichen Repositorys einführen und deren Entwickler die Einrichtung bislang jedes Mal erneut erledigen.

Die breite Nachfrage ist groß: ai coding assistant kommt in den USA auf etwa 18,100 Suchanfragen pro Monat, ai powered coding agent auf etwa 8,100. Ein MVP kann aus einem Repository-Fragebogen, generierten Einrichtungshinweisen, begrenzten Start-Prompts und einer Smoke-Test-Checkliste bestehen. Eine tiefe IDE-Integration ist anfangs nicht erforderlich.

Die Schwäche liegt in der Abgrenzung. JetBrains, Anbieter von Agenten oder Repository-Vorlagen können allgemeine Einrichtungstipps leicht übernehmen. Ein tragfähiges Produkt braucht unternehmensspezifische Richtlinienprüfungen und Belege dafür, dass seine Empfehlungen fehlgeschlagene oder zu weit gefasste Änderungen reduzieren.

Grenzen und eine ehrliche Einordnung

Air ist vor allem dann sinnvoll, wenn eine JetBrains-IDE bereits das bevorzugte Arbeitsumfeld ist und Agentenwahl mit IDE-nativer Prüfung verbunden werden soll. Es ist kein Grund, eine riskante Änderung zu delegieren, deren Ergebnis sich nicht verifizieren lässt.

Drei Einschränkungen sind derzeit besonders wichtig:

• Es ist eine Alpha-Version. Bezeichnungen und Verhalten können sich im Rhythmus ungefähr wöchentlicher Releases ändern.
• Das Plugin ist kostenlos, die Arbeit nicht. Agentenautorisierung, Abonnements, API-Nutzung, IDE-Lizenzen und menschliche Prüfung bleiben separate Kostenpunkte.
• Lokal ist der verlässliche Ausgangspunkt. Die IDE-Seite führt die Cloud-Übergabe weiterhin als „coming soon“; der erste Workflow sollte also nicht darauf beruhen, dass die Arbeit bei geschlossenem Laptop weiterläuft.

Standard Access ist außerdem kein schreibgeschützter Modus. Änderungen und Befehle innerhalb des Projekts sind erlaubt. Verwenden Sie einen entbehrlichen Branch oder Worktree, prüfen Sie den Diff und führen Sie den Test selbst erneut aus.

Die Einordnung ist einfach: Wer täglich in JetBrains arbeitet, sollte Air an einer kleinen Änderung ausprobieren. Für sensible Repositorys ist es noch zu früh, das Werkzeug ohne Rücksetzplan, Anbieterrichtlinie und belastbare Review-Nachweise zum Pflichtweg zu machen.

Der nächste sinnvolle Schritt am Montag

Wählen Sie einen Fehler, der sich mit einem einzigen Befehl testen lässt. Legen Sie ihn auf einen entbehrlichen Branch, installieren Sie den passenden Air-Alpha-Build auf einem Entwicklerrechner, wählen Sie Standard Access, hängen Sie eine relevante Datei an und fordern Sie die kleinste Korrektur samt Regressionstest an. Übernehmen Sie die Änderung nur, wenn der Diff eng begrenzt ist und der Test beim eigenen Durchlauf erfolgreich bleibt. Diese eine Schleife liefert mehr Erkenntnisse als eine Woche voller Agenten-Demos.

Was macht JetBrains Air?

JetBrains Air koordiniert Coding-Agenten sowie deren Kontext, Sitzungen und Prüfung innerhalb und außerhalb von JetBrains-IDEs. Im lokalen IDE-Plugin wählen Sie einen Agenten, senden eine Aufgabe mit Projektkontext und prüfen anschließend die entstandenen Änderungen unter Agent Sessions.

Was unterscheidet JetBrains Air von Claude Code?

Claude Code ist ein einzelner Coding-Agent. Air ist eine agentenübergreifende Steuerungs- und Prüfoberfläche, die Claude neben Codex, Junie, GitHub Copilot, Gemini, OpenCode und ACP-kompatiblen Agenten ausführen kann – abhängig von verfügbaren Integrationen und Autorisierung.

Welche IDE eignet sich am besten für agentisches Programmieren?

Einen universellen Sieger gibt es nicht. Air ist attraktiv, wenn ein Team bereits auf Navigation, Inspektionen und Diff-Werkzeuge von JetBrains setzt. Die beste Wahl ist die Umgebung, in der sich die Arbeit eines Agenten zuverlässig begrenzen, prüfen, testen und zurücksetzen lässt.

Kann JetBrains kostenlos genutzt werden?

Das Air-Alpha-Plugin ist kostenlos. Für die JetBrains-IDE und den hinter Air arbeitenden Agenten können separate Lizenz-, Abonnement- oder API-Kosten anfallen.

Wenn ein sicherer Agenten-Workflow passend zu Ihren Repositorys und Review-Regeln entstehen soll, finden Sie weitere Informationen unter Entwicklung von KI-Agenten.