Air
An agentic development environment
Air Teams: Bringen Sie Ihre besten agentenbasierten Workflows ins ganze Team – und automatisieren Sie wiederkehrende Arbeit
Heute stellen wir JetBrains Air Teams vor – das Team-Produkt für die agentenbasierte Entwicklung. Es gibt Menschen und Agenten den gemeinsamen Kontext, die Umgebungen, Tools und Anweisungen, die sie brauchen, um über den gesamten Entwicklungszyklus hinweg effektiv zusammenzuarbeiten.
Air Teams steht JetBrains-Geschäftskunden bereits zur Verfügung; der Zugang für Einzelkunden soll später folgen.
Das neue Kapitel: Von einzelnen Entwickler*innen zu Teams
Vor einigen Monaten haben wir die Air-App als unseren ersten Schritt in die agentenbasierte Entwicklung vorgestellt. Seitdem haben wir viel gelernt und echte Produktivitätsgewinne bei Entwickler*innen beobachtet, die mit Agenten arbeiten.
Bei der Weiterentwicklung von Air wurde uns zweierlei zunehmend klar. Erstens brauchen Entwickler*innen keine weitere eigenständige App – Tools und Agenten sollten in die Umgebung integriert sein, in der sie ohnehin schon arbeiten. Zweitens verlagerte sich der eigentliche Engpass zunehmend auf die Team-Ebene, je produktiver einzelne Entwickler*innen mit Agenten wurden.
Deshalb erweitern wir Air von einer eigenständigen Desktop-App zu einem umfassenderen System. Air unterstützt agentenbasierte Entwicklung jetzt auf drei Ebenen: einzelne Entwickler*innen, Teams und Organisationen. Sehen wir uns im Detail an, was Air Teams für Engineering-Teams bringt.
Was ist Air Teams?
Air Teams ist eine gemeinsame Umgebung, in der Entwicklungsteams Coding-Agenten betreiben und wiederverwenden, was funktioniert. Heute findet die meiste agentenbasierte Arbeit auf einzelnen Laptops statt: Alle Entwickler*innen haben ihre eigene Setups und eigene Prompts, und was für eine Person funktioniert, lässt sich nicht unbedingt auf den Rest des Teams übertragen. Air Teams bringt Ihre agentenbasierten Workflows an einem Ort zusammen: Was ein*e Entwickler*in herausfindet, kann das gesamte Team nutzen.
Air Teams besteht aus vier Teilen:
Automatisierungen erledigen wiederkehrende Arbeiten eigenständig, etwa Code-Reviews, Fehlerkorrekturen und Aktualisierungen für Abhängigkeiten. Ein Event oder ein Zeitplan startet jeden Durchlauf.
Gemeinsame Cloud-Umgebungen geben Agenten die Tools, Abhängigkeiten und Anmeldedaten, die sie zum Bauen und Testen des Codes brauchen. Das Team richtet sie einmal ein, und alle nutzen sie danach weiter.
Cloud-Tasks laufen parallel in diesen Umgebungen, ohne den Laptop von irgendjemandem zu blockieren. Sie können sie aus Ihrer IDE oder Ihrem Browser starten und verfolgen – bald auch vom Smartphone aus.
Projekte bringen alles zusammen: mit gemeinsamen Credits, klaren Rollen und Automatisierungen, die nicht von einer einzelnen Person abhängen.
Schauen wir uns die einzelnen Teile im Detail an.
Automatisierungen: Schluss mit dem Babysitting für Agenten
Agenten können schnell arbeiten, aber noch immer warten sie darauf, dass Menschen Aufgaben starten, Anweisungen geben und den nächsten Schritt einleiten. Irgendwann wird die manuelle Orchestrierung jedes einzelnen Durchlaufs selbst zum Engpass.
Air Automations sind agentenbasierte Workflows, die eigenständig in der Cloud laufen und durch ein Event oder einen Zeitplan ausgelöst werden – nicht durch eine Person. Sie sind gemeinsame Ressourcen des Teams: Ein*e Entwickler*in kann eine Automatisierung erstellen, und das ganze Team kann sie ausführen, wiederverwenden und weiterentwickeln. Was für eine Person gut funktioniert, kann Teil der Arbeitsweise des gesamten Teams werden. Eine Automatisierung kann zum Beispiel jeden neuen Pull-Request direkt beim Öffnen reviewen oder zweimal pro Woche Abhängigkeiten aktualisieren.
Wie Automatisierungen funktionieren
Automatisierungen eignen sich für wiederkehrende Arbeiten, die einem festen Muster folgen: Ein Pull-Request muss reviewt werden, ein gelabeltes Issue muss untersucht werden, oder Abhängigkeiten müssen jede Woche geprüft werden.
Sie richten vier Dinge einmalig ein, und die Automatisierung nutzt sie bei jedem Durchlauf erneut:
Anweisungen: was der Agent tun soll.
Umgebung: wo der Agent läuft.
Tools: was der Agent nutzen kann, einschließlich Jira, Figma und Linear über Connectors.
Trigger: wann der Agent startet – sei es durch ein GitHub- oder Jira-Event, einen Webhook oder einen Zeitplan, wobei weitere Trigger-Typen bereits in Vorbereitung sind.
Hier ist ein Beispiel: eine Automatisierung, die durch ein Label ausgelöst wird. Sobald jemand das Label Bug hinzufügt, startet die Automatisierung einen Agenten. Der Agent liest das Issue und das verknüpfte Jira-Ticket, findet die Ursache im Code und öffnet einen Pull-Request mit einem Lösungsvorschlag, den ein*e Entwickler*in reviewen kann.
Automatisierungen gehören zu einem Team-Projekt, sodass das gesamte Team dieselbe Automatisierung nutzt, statt dass jede Person ihre eigene baut. Sobald sich eine Automatisierung bewährt hat, kann sie über das Projekt hinauswachsen: Das Team kann sie in einem anderen Repository wiederverwenden oder als Vorlage speichern, die jede*r in der Organisation unverändert oder angepasst nutzen kann.
Beispiele für Automatisierungen
Hier sind drei Automatisierungen, die wir in unserem eigenen Team einsetzen:
Code-Reviews. Sobald ein Pull-Request geöffnet wird, liest ein Agent den relevanten Code und die Diskussion, hinterlässt Inline-Kommentare und eine Zusammenfassung und kann den Pull-Request genehmigen oder Änderungen anfordern. Jeder neue Commit startet einen weiteren Durchlauf: Der Agent liest sein vorheriges Review und etwaige Antworten, notiert, welche Probleme behoben wurden und welche noch bestehen, und klappt seine alten Reviews ein, sodass nur das neueste sichtbar bleibt. Ein KI-Agent sollte Ihren Workflow unterstützen, nicht blockieren. Wenn Sie entscheiden, ein Problem in einem separaten Pull-Request zu beheben, respektiert der Agent Ihre Entscheidung und schließt seine Prüfung ab.
Fehlerbehebungen. Sobald ein Teammitglied ein kleines, klar abgegrenztes Issue in YouTrack taggt, sammelt ein Agent den Kontext, versucht eine Lösung und öffnet einen Pull-Request zum Review. Dieselbe Automatisierung kümmert sich auch um Review-Feedback. Erhält ein von einer Automatisierung geöffneter Pull-Request Review-Kommentare – von einem Teammitglied oder von der Code-Review-Automatisierung –, greift der Agent sie auf und behebt sie.
Aktualisierungen der Abhängigkeiten. Zweimal pro Woche aktualisiert ein Agent die Abhängigkeiten des Projekts und überspringt dabei alle, die laut seinen Anweisungen unangetastet bleiben sollen. Er baut das Projekt und führt die Tests aus. Bricht ein Upgrade etwas, behebt der Agent den betroffenen Code, ohne dessen Verhalten zu verändern – oder macht das Upgrade rückgängig, wenn das nicht möglich ist. Anschließend öffnet er einen Pull-Request, der auflistet, welche Upgrades angewendet, übersprungen oder rückgängig gemacht wurden. Ist der vorherige Pull-Request noch nicht gemergt, schließt der Agent ihn, sodass dem Team immer genau ein aktueller Pull-Request zum Mergen vorliegt, sobald es so weit ist.
Weitere Automatisierungen behandeln wir in kommenden Beiträgen – inklusive, wie wir sie einrichten und nutzen.
Sie behalten die Kontrolle
Eine berechtigte Sorge bei KI-Agenten ist Rauschen: Kommentare, die niemand liest, und Pull-Requests, die niemand angefordert hat. Automatisierungen belassen die Entscheidungen beim Team. Entwickler*innen entscheiden, woran ein Agent arbeitet, und seine Anweisungen können den Output klein halten, wie in den Beispielen oben: ein offener Pull-Request für Dependency-Updates, ein aktuelles Review pro Pull-Request. Jeder Durchlauf bewahrt außerdem die vollständige Konversation und alle Tool-Aufrufe des Agenten, sodass das Team nachvollziehen kann, warum ein Ergebnis falsch aussieht. Jede Codeänderung kommt als Pull-Request an, und ein*e Entwickler*in entscheidet, ob er gemergt wird.
Erstellen Sie Ihre erste Automatisierung
Gemeinsame Cloud-Umgebungen: ein Setup, das Ihr Team und Ihre Agenten wiederverwenden können
Jede Automatisierung läuft, genau wie jeder Cloud-Task, in einer Umgebung – und ein Agent kann nur so gut arbeiten, wie es seine Umgebung zulässt. Bevor er irgendetwas bauen oder testen kann, braucht er das, was auch ein*e neue Entwickler*in am ersten Tag braucht: die richtigen Tools, Abhängigkeiten, Anmeldedaten und Netzwerkzugriff. Ein kleines Projekt kommt vielleicht mit den Standardeinstellungen aus, aber die meisten Codebasen brauchen mehr – etwa eine private Paket-Registry, fest verankerte Toolchain-Versionen oder ein internes Issue-Tracking-System, das der Agent erreichen muss. Jemand muss das einrichten – und einmal sollte reichen.
In Air Teams lebt dieses Setup in einer teilbaren Cloud-Umgebung. Sie erstellen eine für ein Repository in Ihrem Team-Projekt. Wählen Sie die VM-Größe, legen Sie fest, welche Domains die Maschine erreichen darf, und fügen Sie die Variablen und Secrets hinzu, die der Build braucht. Das Setup selbst liegt in Ihrem Repository unter .air/cloud/startup.sh, sodass Ihr Team es zusammen mit dem restlichen Code versioniert und reviewt.
Sie können den ersten Durchgang auch einem Agenten überlassen. Er untersucht das Repository, führt die tatsächliche Installation und den Build aus, fragt nach fehlenden Secrets und committet ein getestetes Startup-Skript in einen separaten Branch. Sie reviewen es wie jede andere Änderung.
Sobald die Umgebung bereit ist, speichert Air sie als Snapshot, und Sie teilen sie mit dem Team. Das Setup zu teilen heißt nicht, Anmeldedaten zu teilen. Mit gemeinsamen Secrets können Ihre Teammitglieder und Automatisierungen einen Wert nutzen, ohne ihn zu sehen, während persönliche Secrets und der Repository-Zugriff bei jeder Person bleiben.
Ab dann wählen Teammitglieder die Umgebung für ihre Cloud-Tasks, und die Automatisierungen des Projekts laufen darauf. Kein Agent verschwendet Zeit und Tokens damit, erneut herauszufinden, wie das Repository gebaut wird. Jeder Task beginnt direkt mit der eigentlichen Arbeit.
Erfahren Sie, wie Sie Umgebungen konfigurieren
Cloud-Tasks: Arbeiten Sie von Ihrer IDE und jedem Gerät aus
Sobald die Umgebungen eingerichtet sind, können Sie Agenten Arbeit zuweisen. Wählen Sie eine Umgebung und einen Agenten aus, und beschreiben Sie den Task. Wenn Ihr Repository kein individuelles Setup braucht, nutzen Sie die Standardumgebung.
Sie können einen Task lokal oder in der Cloud ausführen. Die richtige Wahl hängt vom Task ab, vom benötigten Setup und davon, wie eng Sie mit dem Agenten zusammenarbeiten möchten.
| Lokaler Agent | Cloud-Agent | |
| Erste Schritte | Ein vorhandener Workspace ist sofort einsatzbereit. Ein neuer Worktree oder Container muss unter Umständen erst eingerichtet werden. | Die Umgebung muss zuerst starten und das Repository kopieren. Wenn Sie sie vorab konfigurieren und als teilbare Umgebung mit zwischengespeichertem Status sichern, verkürzt das die Wartezeit. |
| Maschinenressourcen | Builds und Tests teilen sich CPU und Arbeitsspeicher Ihrer Maschine mit Ihrer sonstigen Arbeit. | Builds und Tests laufen auf einer Cloud-Maschine und schonen so lokale Ressourcen. |
| Dateien und Tools | Der Agent arbeitet mit Ihren lokalen Tools und Ihrer Arbeitskopie, einschließlich nicht committeter Änderungen. | Der Agent arbeitet von einem Remote-Branch aus, mit den Tools, Abhängigkeiten und Anmeldedaten, die für die Umgebung konfiguriert sind. |
| Agenten und Konten | Sie können jeden unterstützten oder ACP-kompatiblen Agenten verwenden, den Sie installiert haben, mit einem von ihm unterstützten Konto. | Sie können die unterstützten Cloud-Agents verwenden, die Ihre Organisation aktiviert hat. |
| Das Setup wiederverwenden | Teammitglieder können Setup-Skripte teilen, aber jede Person bereitet weiterhin ihre eigene Maschine vor. | Teammitglieder teilen sich eine Umgebung, und jeder Task läuft in einer eigenen Kopie davon. |
| Nachverfolgen | Ihre Maschine muss eingeschaltet bleiben. Der Remote-Zugriff hängt von Ihren eigenen Tools ab. | Der Task läuft weiter, auch wenn Ihre Maschine ausgeschaltet ist. Sie können den Fortschritt über Air in JetBrains-IDEs oder im Web verfolgen – bald auch mobil. |
Der entscheidende Unterschied ist, dass Cloud-Tasks nicht an das Gerät gebunden sind, auf dem Sie sie gestartet haben. Sie können einen Task in Ihrer IDE starten und später im Web weiterführen. Der Agent arbeitet weiter, auch nachdem Sie Ihren Laptop zugeklappt haben.
Den Cloud-Task-Workflow ansehen
Team-Projekte: Arbeit, die dem Team gehört
Ein Team-Projekt ist die gemeinsame Heimat für die agentenbasierte Arbeit eines Teams. Es bringt Teammitglieder, gemeinsame Umgebungen, MCP-Connectors und Automatisierungen zusammen.
Zwei Rollen legen fest, wer was tun kann. Projekt-Admins verwalten die Mitgliedschaft, Umgebungen, Connectors und Automatisierungen. Sie können bestimmten Mitgliedern außerdem erlauben, eine Umgebung zu bearbeiten. Mitglieder nutzen die gemeinsamen Umgebungen, erstellen ihre eigenen Automatisierungen und sehen die Ergebnisse jedes Durchlaufs.
Automatisierungen müssen nicht von der Person abhängen, die sie erstellt hat. Jedes Projekt hat sein eigenes Service-Konto und eigene KI-Credits, und ein Projekt-Admin entscheidet, ob die Automatisierungen des Projekts diese Credits verwenden oder die ihrer Ersteller. Bei Projekt-Credits laufen Automatisierungen unter dem Konto des Projekts und weiter, auch wenn ihr*e Ersteller*in das Projekt verlässt.
Erfahren Sie mehr über Projektrollen und Credits
Erste Schritte mit Air Teams
Mit Air Teams wird agentenbasierte Arbeit zu etwas, das das gesamte Team gemeinsam nutzt. Automatisierungen erledigen wiederkehrende Arbeit, gemeinsame Umgebungen geben jedem Task dasselbe Setup, Cloud-Tasks laufen weiter, nachdem Sie Ihren Laptop zugeklappt haben, und Team-Projekte stellen sicher, dass nichts davon von einer einzelnen Person abhängt.
Probieren Sie Air Teams unter air.jetbrains.cloud aus. Alles oben Beschriebene ist für die gemeinsame Nutzung gemacht – laden Sie Ihre Teammitglieder also von Anfang an ein.
Die gesamte Air-Produktfamilie finden Sie unter jetbrains.com/air.
Autor des ursprünglichen Blogposts
