JetBrains a annoncé Air Teams, une couche destinée aux équipes au sein de l’écosystème Air, qui coordonne le travail des agents de programmation et permet de partager ce qui fonctionne au cours du cycle de développement logiciel. Le service est actuellement disponible pour les clients professionnels de JetBrains, tandis que l’entreprise prévoit d’en élargir ultérieurement l’accès aux clients individuels.
Le service cible un problème pratique lié à l’utilisation d’agents d’intelligence artificielle au sein des équipes de développement : les paramètres, les instructions et l’environnement de chaque développeur restent généralement sur son ordinateur, ce qui rend difficile le transfert d’un flux de travail réussi au reste de l’équipe. Air Teams déplace donc ces éléments dans un espace partagé que l’équipe peut gérer et réutiliser.
Quatre composants pour un flux de travail partagé
Air Teams se compose de quatre éléments interconnectés :
- Exécutions automatisées : des tâches récurrentes exécutées par les agents dans le cloud, comme la révision des demandes de fusion, le traitement de problèmes spécifiques ou la mise à jour des dépendances, et lancées selon un événement ou un calendrier.
- Environnements cloud partagés : des configurations comprenant les outils, les dépendances et les données d’accès nécessaires à la compilation et aux tests, que l’équipe configure une seule fois et réutilise.
- Tâches cloud : des travaux pouvant être exécutés en parallèle sans monopoliser l’ordinateur du développeur, avec la possibilité de les démarrer et de les suivre depuis l’environnement de développement intégré ou le navigateur, puis depuis le téléphone ultérieurement.
- Projets d’équipe : un espace réunissant les membres, les environnements, les connecteurs et les exécutions automatisées, avec des rôles et des crédits partagés.
Les exécutions automatisées encadrent les tâches récurrentes
Chaque processus automatisé est composé de quatre éléments : des instructions qui définissent ce qui est demandé à l’agent, un environnement d’exécution, des outils qu’il peut utiliser et un déclencheur qui détermine l’heure de démarrage. Les déclencheurs comprennent les événements provenant de GitHub ou de Jira, les webhooks et les calendriers, avec la prise en charge d’autres types prévue ultérieurement. Le service prend également en charge des connecteurs vers des outils tels que Jira, Figma et Linear.
JetBrains propose notamment des exemples comprenant la révision de chaque nouvelle demande de fusion, la tentative de correction de petits problèmes dans YouTrack suivie de l’ouverture d’une demande de fusion pour révision, ainsi que la mise à jour des dépendances deux fois par semaine. Dans ce dernier exemple, l’agent compile le projet et exécute les tests, puis corrige les défaillances ou annule la mise à jour si la correction est impossible, tout en conservant une seule demande de fusion mise à jour au lieu d’inonder l’équipe de demandes répétées.
Qu’est-ce qui change concrètement ?
Air Teams transforme la configuration de l’agent en ressource partagée plutôt qu’en expérimentation individuelle. L’environnement du dépôt est conservé dans le fichier .air/cloud/startup.sh au sein du dépôt, et peut être révisé et versionné comme le reste du code. Un agent peut également aider à le configurer en inspectant le dépôt et en exécutant l’installation et la compilation, puis en proposant le script dans une branche distincte pour révision.
JetBrains affirme que le partage de l’environnement ne signifie pas le partage des identifiants eux-mêmes : les secrets partagés peuvent être utilisés sans révéler leurs valeurs, tandis que les secrets personnels et les autorisations du dépôt restent associés à chaque utilisateur. Les projets attribuent aux exécutions un compte de service et des crédits d’intelligence artificielle qui leur sont propres, ce qui permet de continuer à les exécuter même après le départ de leur créateur de l’équipe, si les administrateurs choisissent d’utiliser les crédits du projet.
Garder la décision entre les mains de l’ingénieur
La plateforme tente de réduire le bruit causé par les commentaires et les demandes de fusion inutiles en conservant les changements sous la forme de demandes de fusion dont l’ingénieur décide la fusion ou le rejet. Chaque processus conserve également un journal de la conversation de l’agent et des appels d’outils, ce qui permet à l’équipe d’examiner la raison du résultat lorsqu’une erreur survient. Cependant, la source ne fournit pas de détails sur la tarification, les limites d’utilisation ou les mécanismes de gouvernance plus larges, autant de points que les équipes devront vérifier avant d’adopter le service à l’échelle de la production.