JetBrains hat Air Teams angekündigt, eine auf Teams ausgerichtete Ebene innerhalb des Air-Ökosystems zur Koordinierung der Arbeit von Programmieragenten und zum Teilen erfolgreicher Abläufe über den gesamten Softwareentwicklungszyklus hinweg. Der Dienst ist derzeit für Geschäftskunden von JetBrains verfügbar, während das Unternehmen plant, den Zugang später auch auf Einzelkunden auszuweiten.
Der Dienst zielt auf ein praktisches Problem beim Einsatz von KI-Agenten in Entwicklungsteams: Die Einstellungen, Anweisungen und Umgebungen jedes Entwicklers verbleiben meist auf dessen Computer, wodurch es schwierig wird, erfolgreiche Workflows an den übrigen Teil des Teams weiterzugeben. Air Teams verlagert diese Elemente daher in einen gemeinsamen Arbeitsbereich, den das Team verwalten und wiederverwenden kann.
Vier Komponenten für einen gemeinsamen Workflow
Air Teams besteht aus vier miteinander verbundenen Elementen:
- Automatisierte Abläufe: Wiederkehrende Aufgaben, die Agenten in der Cloud ausführen, etwa die Prüfung von Pull Requests, die Bearbeitung bestimmter Probleme oder die Aktualisierung von Abhängigkeiten; gestartet werden sie durch ein Ereignis oder nach einem Zeitplan.
- Gemeinsame Cloud-Umgebungen: Einstellungen, die die für Build und Tests benötigten Tools, Abhängigkeiten und Zugangsdaten umfassen, sodass das Team sie einmal einrichtet und wiederverwendet.
- Cloud-Aufgaben: Arbeiten, die parallel ausgeführt werden können, ohne den Computer des Entwicklers zu blockieren, und die sich aus der integrierten Entwicklungsumgebung oder dem Browser sowie später auch vom Telefon aus starten und verfolgen lassen.
- Teamprojekte: Ein Arbeitsbereich, der Mitglieder, Umgebungen, Konnektoren und automatisierte Abläufe mit gemeinsamen Rollen und Kontingenten bündelt.
Automatisierte Abläufe steuern wiederkehrende Arbeiten
Jeder automatisierte Ablauf besteht aus vier Komponenten: Anweisungen, die festlegen, was der Agent tun soll, einer Laufzeitumgebung, den von ihm verwendbaren Tools und einem Auslöser, der den Startzeitpunkt bestimmt. Zu den Auslösern gehören Ereignisse von GitHub oder Jira, Webhooks und Zeitpläne; künftig sollen weitere Typen unterstützt werden. Der Dienst unterstützt außerdem Konnektoren zu Tools wie Jira, Figma und Linear.
JetBrains nennt Beispiele wie die Prüfung jedes neuen Pull Requests, den Versuch, kleinere Probleme in YouTrack zu beheben und einen Pull Request zur Prüfung zu öffnen, sowie die zweimal wöchentliche Aktualisierung von Abhängigkeiten. Im letzten Beispiel erstellt der Agent das Projekt und führt die Tests aus; anschließend behebt er Fehler oder macht die Aktualisierung rückgängig, wenn eine Behebung nicht möglich ist. Dabei bleibt ein einziger aktualisierter Pull Request erhalten, anstatt das Team mit wiederholten Anfragen zu überfluten.
Was ändert sich praktisch?
Air Teams macht die Einrichtung eines Agenten zu einer gemeinsamen Ressource statt zu einem individuellen Experiment. Die Umgebung des Repositorys wird in der Datei .air/cloud/startup.sh innerhalb des Repositorys gespeichert und kann wie der übrige Code geprüft und versioniert werden. Ein Agent kann außerdem bei der Einrichtung helfen, indem er das Repository untersucht sowie Installation und Build ausführt und anschließend das Skript in einem separaten Branch zur Prüfung vorschlägt.
JetBrains zufolge bedeutet das Teilen der Umgebung nicht, dass auch die Zugangsdaten selbst geteilt werden; gemeinsame Geheimnisse können verwendet werden, ohne ihre Werte offenzulegen, während persönliche Geheimnisse und Repository-Berechtigungen an den jeweiligen Benutzer gebunden bleiben. Projekte erhalten eigene Dienstkonten und KI-Kontingente, sodass ihre Abläufe auch dann weiter ausgeführt werden können, wenn der Ersteller das Team verlässt, sofern die Verantwortlichen die Verwendung von Projektkontingenten auswählen.
Die Entscheidung bleibt beim Ingenieur
Die Plattform versucht, das Rauschen durch unnötige Kommentare und Pull Requests zu begrenzen, indem Änderungen in Form von Pull Requests erhalten bleiben, über deren Zusammenführung oder Ablehnung der Ingenieur entscheidet. Außerdem bewahrt jeder Ablauf ein Protokoll der Agentenkonversation und der Tool-Aufrufe auf, sodass das Team bei einem Fehler den Grund für das Ergebnis untersuchen kann. Die Quelle enthält jedoch keine Angaben zu Preisen, Nutzungsgrenzen oder umfassenderen Governance-Mechanismen. Diese Punkte müssen die Teams prüfen, bevor sie den Dienst im Produktionsmaßstab einsetzen.