Nouveautés dans Bob : ton éditeur, tes politiques, ta piste d'audit
Applique la configuration de Bob de façon centralisée, transfère les événements d'audit vers ta plateforme de sécurité, exécute Bob comme agent de première classe dans IntelliJ, Neovim ou Zed, et plus encore.
Nouveautés dans Bob : ton éditeur, tes politiques, ta piste d'audit
Les admins peuvent désormais appliquer la configuration de Bob de façon centralisée et transférer ses événements d'audit vers la plateforme de sécurité qu'ils utilisent déjà. Les développeurs bénéficient de Bob comme agent de première classe dans l'éditeur ou l'orchestrateur qu'ils utilisent déjà, de lifecycle hooks pouvant être imposés plutôt que simplement mémorisés, et de réponses ancrées dans la documentation produit d'IBM.
Politiques de groupe : gouvernance d'entreprise pour Bob
Les admins IT et sécurité peuvent désormais définir et verrouiller la configuration de Bob sur les machines développeur gérées, afin que les standards de l'entreprise soient respectés sans que chaque développeur ait à les configurer manuellement. Ton infrastructure de gestion des appareils existante distribue les politiques : templates ADMX/ADML pour Windows Group Policy, gestion des appareils mobiles sur macOS, un fichier de politique sur Linux. Les paramètres verrouillés apparaissent en lecture seule, de la même façon que VS Code signale les paramètres gérés par politique.
Les politiques de lancement couvrent les paramètres qui arrivent en premier lors d'une revue de sécurité. Désactiver les groupes d'auto-approbation empêche l'agent de valider ses propres appels d'outils. Désactiver les mises à jour automatiques maintient la version déployée sous contrôle des changements. Imposer les hooks de façon centralisée signifie qu'une vérification obligatoire ne peut pas être désactivée. IBM publie des templates de configuration et de la documentation pour démarrer.
Support natif de l'Agent Client Protocol
Bob Shell parle désormais nativement l'Agent Client Protocol (ACP), de sorte que n'importe quel client compatible ACP peut exécuter Bob comme agent de première classe — IntelliJ, Neovim et Zed aux côtés de l'extension Bob IDE. La gestion de session, les modes, le streaming, le Model Context Protocol (MCP) et les guardrails passent tous par le protocole lui-même, sans adaptateur intermédiaire.
La portée va au-delà des éditeurs. Les clients ACP incluent aussi les orchestrateurs d'agents que les entreprises construisent déjà pour elles-mêmes, ce qui change la question d'adoption. Bob n'a pas à remplacer un workflow existant. Il peut fonctionner comme un agent à l'intérieur de celui-ci.
La vidéo suivante montre Bob fonctionnant comme agent dans IntelliJ via ACP.
MCP Elicitation
Les outils MCP peuvent désormais demander les informations dont ils ont besoin pour accomplir une tâche, directement dans la session. Lorsqu'un appel d'outil manque d'une valeur requise — un nom d'utilisateur, une préférence, un paramètre de configuration — l'outil affiche un bref formulaire inline plutôt que d'échouer ou de continuer sur une supposition. Le développeur vérifie, modifie, et accepte ou refuse avant que l'outil ne continue.
L'effet concret est que les outils MCP peuvent gérer les entrées incomplètes sans exiger que le développeur anticipe chaque paramètre à l'avance ou relance après un appel échoué.
Hooks
Une boucle d'agent est non déterministe par nature. Les hooks sont la façon dont tu mets des rails déterministes autour d'elle. Les équipes peuvent désormais déclencher des actions automatisées à des points définis de la boucle — SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop — pour qu'un linter s'exécute avant qu'une tâche commence, que les tests s'exécutent après qu'un changement est appliqué, et qu'un script de nettoyage s'exécute en cas d'erreur.
Un hook PreToolUse peut bloquer complètement un appel d'outil, faisant d'un standard de code une contrainte stricte que l'agent ne peut pas contourner. Les politiques de groupe imposent les hooks de façon centralisée, de sorte qu'un projet ne peut pas silencieusement en désactiver un. Les violations apparaissent au moment de l'écriture plutôt que dans une revue trois sprints plus tard.
Tu définis les hooks par projet et tu peux les activer ou les désactiver indépendamment. Les commandes de hook s'exécutent sous la confiance du workspace, et un hook en échec n'arrêtera pas Bob sauf s'il est configuré pour bloquer. Le journal des hooks enregistre ce qui s'est déclenché et si c'est passé. Un nouvel onglet Hooks dans les paramètres de Bob liste tous les hooks globaux et de workspace en un seul endroit : recherche, filtre, active ou désactive-les, et accède directement au fichier de paramètres où un hook est défini. La documentation des hooks couvre la liste complète des événements.
La vidéo suivante montre un hook se déclenchant lors d'une session Bob.
Intégration SIEM (Security Information and Event Management)
Bob transfère désormais les événements d'audit vers les plateformes de sécurité et d'observabilité existantes, de sorte que l'activité IA s'intègre dans les mêmes outils qu'une équipe utilise déjà pour l'investigation, les alertes et la rétention. Bob supporte Splunk au lancement. L'équipe Bob configure chaque intégration avec toi et vérifie le sink, les régions et la livraison des événements de bout en bout avant la mise en production.
Pour en démarrer une, soumets une demande via le support IBM, qui la route vers l'équipe Bob.
IBM Docs en contexte : génération augmentée par récupération (RAG) sur la documentation IBM
Bob peut désormais répondre à des questions ancrées dans la documentation technique propre à IBM. Plutôt que de s'appuyer sur ce qu'un modèle a éventuellement absorbé sur les produits IBM, Bob récupère depuis la documentation produit indexée et répond à partir de celle-ci. Le même index couvre la documentation de Bob lui-même, et Bob IDE atteint le service de récupération via un serveur MCP.
Parce que Bob récupère depuis un corpus indexé de la documentation publiée par IBM plutôt que de chercher sur le web ouvert, les réponses proviennent de sources IBM à une version connue, sans passer par une recherche web généraliste. IBM maintient cet index et le met à jour lorsque la documentation sous-jacente change, de sorte que le corpus suit le produit actuel plutôt qu'un snapshot dont quelqu'un se serait souvenu de re-crawler. Cela signifie aussi que Bob fonctionne de la même façon dans des environnements à accès réseau restreint où la recherche externe n'est pas une option.
Lecture et édition de fichiers Office
Bob peut désormais lire, modifier et créer des documents, des présentations et des tableurs sans quitter l'agent. Une tâche qui touche une spec, un fichier de données ou une présentation en plus du code ne nécessite plus de changer de contexte pour ouvrir le fichier séparément.
Premium Package for Java : Spring Boot vers Quarkus
Le Premium Package for Java de Bob inclut désormais une migration guidée de Spring Boot vers Quarkus. Bob analyse l'environnement Java et les dépendances de ton application, puis recommande soit une stratégie de migration Spring Compatibility soit une migration Full Quarkus. Il effectue les tâches de migration sur les points de conversion courants, notamment les endpoints Spring MVC vers Quarkus REST, l'injection de dépendances, et la persistance Spring Data vers Hibernate Panache ou l'API Java Persistence (JPA). Il valide le build tout au long du processus. Plutôt que de te laisser avec un build à moitié converti, Bob parcourt six modules à validation pour aider à compléter la migration. Il cible les services où le temps de démarrage des conteneurs et l'empreinte mémoire sont le problème, et non une réécriture complète. Active la fonctionnalité depuis la page d'accueil du Premium Package for Java, ou via une commande slash.