Ceci est le premier article sur le blog de Bob. Il est écrit par l'équipe qui construit Bob, pour les développeurs qui l'utilisent. Nous l'utiliserons pour expliquer les décisions d'ingénierie, partager ce que nous avons appris en livrant un partenaire de développement IA dans de vraies bases de code, et parfois défendre une position. Ce n'est pas de la documentation et ce n'est pas du marketing — si tu veux l'un ou l'autre, nous te dirigerons vers le bon endroit.

Pour notre premier article, plutôt que de parcourir tout ce que fait Bob, nous voulons faire trois choses :

Examiner quelques-unes des capacités principales de Bob.
Partager un ensemble de conseils pratiques pour configurer un dépôt afin que Bob fasse son meilleur travail.
Expliquer comment nous abordons la sécurité dans un outil qui a ce type d'accès à ton code.

1. Ce sur quoi les développeurs passent réellement leur temps

Un assistant IA moderne peut écrire une fonction à partir d'une description. Cela est vrai depuis un moment, et ce n'est plus la question intéressante. La question intéressante est ce qui se passe quand le travail n'est pas "produire du nouveau code" mais "modifier un système qui existe déjà" — trouver le bon endroit pour faire un changement, comprendre les conventions sur lesquelles une équipe s'est mise d'accord, maintenir le comportement cohérent à travers des fichiers qui grandissent depuis des années. C'est à quoi ressemble la majeure partie du développement logiciel professionnel. Bob est construit pour ce type de travail, et les choix de conception que nous décrivons dans le reste de cet article découlent de cette orientation.

1.1. Modes : dire à Bob quel type de travail tu fais

Bob n'est pas une seule interaction "fais quelque chose d'utile". Le mode dans lequel tu démarres une session indique à Bob quel type de travail tu es sur le point de faire, quels outils il peut utiliser, et à quel point il doit être proactif.

Ask — lecture seule. Parfait pour la "phase d'exploration". Bob explique l'architecture et la logique sans faire de modifications. Utilise ceci quand tu plonges dans un système hérité ou effectues une vérification de cohérence sur un morceau de logique que tu n'as pas écrit.
Plan — Bob produit un plan pour un changement que tu es sur le point de faire : fichiers à toucher, cas limites à considérer, ordre de travail suggéré. La sortie est un plan, pas du code.
Code — pour faire réellement des modifications. Bob lit, écrit et teste dans ton projet, en suivant les conventions et règles que tu as définies.
Advanced — étend le mode Code via le Model Context Protocol (MCP), donnant à Bob accès aux outils et services spécifiques de ton organisation : API internes, bases de données, outils propriétaires.
Orchestrator — pour un travail en plusieurs étapes qui traverse les modes. Bob bascule entre les modes lui-même en fonction de ce que l'étape actuelle nécessite, et c'est le bon choix pour des morceaux de travail plus importants qui mélangent exploration, planification et exécution.

Choisir le bon mode au début d'une session est l'un des leviers les moins coûteux disponibles pour obtenir une meilleure sortie. Une bonne habitude, particulièrement sur une base de code que tu ne connais pas bien ou pour un changement avec une surface réelle, est de commencer en Ask ou Plan et de ne basculer vers Code qu'une fois que tu as une image claire du travail. Aller directement à Code semble plus rapide sur le moment, mais c'est là que les hypothèses ont tendance à se glisser comme des changements réels et commencent à s'accumuler comme dette technique.

1.2. Bob tips : métriques de complexité, en temps réel

On a tous vécu ça : tu es profondément dans la "zone", imbriquant un dernier conditionnel pour gérer un cas limite, et soudain une seule fonction s'est transformée en un labyrinthe de trente lignes. Dans un flux de travail typique, ce labyrinthe n'est pas démêlé avant qu'un coéquipier ne le signale dans une pull request des heures plus tard. Bob Tips change le récit en offrant une proposition de refactorisation pendant que la logique est encore fraîche dans ton esprit. Pendant que tu tapes, l'analyse statique continue surveille silencieusement tes fichiers ouverts. Quand une fonction franchit la ligne vers une complexité cyclomatique élevée ou devient difficile à maintenir, Bob la signale immédiatement avec un soulignement violet. Un linter traditionnel te dit juste que tu as fait quelque chose de mal ; Bob Tips fournit la sortie. L'accent de l'outil est entièrement mis sur la fourniture de propositions de refactorisation actionnables :

Intelligence Contextuelle : Survoler le soulignement violet n'affiche pas seulement un avertissement—il offre une stratégie spécifique générée par IA pour démêler la logique juste là. Exécution Transparente : Cliquer sur Fix with Bob ouvre instantanément un chat dédié. L'IA détient déjà le contexte de la fonction et est prête à exécuter le nettoyage à tes côtés.

Les métriques qui tournent en arrière-plan ne sont que la plomberie. La partie précieuse est qu'un signal de qualité de code de longue date pilote maintenant une suggestion IA au moment où le développeur est dans le fichier, plutôt que de faire surface dans une revue de code trois jours plus tard.

1.3. Mode Review : revue de code, avec le système qui lit en même temps

La revue de code a fait autant pour la qualité logicielle que n'importe quelle pratique au cours des deux dernières décennies, et c'est aussi là que les équipes perdent leur élan. Bob ne remplace pas la revue humaine. Il fait les parties qui sont mécaniques, pour qu'ils puissent se concentrer sur l'architecture de haut niveau et l'intention plutôt que de chasser les bugs "faciles".

Les revues s'exécutent depuis le Review Panel dans la barre latérale ou via /review dans le chat. Il y a deux modes :

Comparaison de branche. Ce mode gère le diff "classique". Utilise /review pour auditer le travail non commité contre ton head actuel, ou /review <branch> pour cibler un remote spécifique. C'est une frappe préventive contre les "nitpicks" qui encombrent habituellement les fils de revue.
Couverture d'issue. /review <issue-url> --issue-coverage valide que tes changements locaux adressent réellement ce qu'une issue GitHub demande. C'est le mode que les développeurs nous disent qu'ils ne savaient pas qu'ils voulaient jusqu'à ce qu'ils l'essaient. Les résultats apparaissent dans un panneau dédié, pour que tu puisses les examiner et décider de les corriger avec Bob. C'est une vérification de cohérence qui confirme que tu n'as pas juste écrit du bon code, mais le bon code.

1.4. Literate coding : intention, écrite à côté du code

Quand tu es profondément dans une fonctionnalité complexe, référencer plusieurs fichiers dans une fenêtre de chat est une corvée. Tu te retrouves à taper "Regarde l'interface dans types.ts et le service dans api.ts, puis mets à jour la logique ici..." Bob inverse cette dynamique. En déplaçant l'interaction directement dans le fichier source via Literate Coding, l'éditeur lui-même devient l'interface. Ce n'est pas juste une question d'éviter un panneau latéral ; c'est une question de fournir à l'IA une carte sophistiquée multi-fichiers de ton intention.

Exprime l'Intention Naturellement : Bascule le mode avec Cmd+M et écris ta logique en langage simple ou pseudocode. Tes instructions apparaissent dans l'éditeur en bleu, vivant exactement là où l'implémentation appartient.
Au-delà de la Ligne Unique : Alors que le chat traditionnel perd souvent le "fil" d'un projet complexe, le literate coding de Bob évolue pour combler le fossé entre les fichiers. Les développeurs peuvent maintenant fournir du contexte à travers plusieurs modules, s'assurant qu'un changement dans un modèle de données se reflète avec précision dans le contrôleur associé.
Vérification Immédiate : Appuie sur Cmd+Enter et Bob génère l'implémentation sur place. Parce que le résultat est montré comme un diff en ligne, tu peux auditer la logique contre le code environnant avant de t'engager dans le changement.

L'avantage est simple : le prompt vit là où le code vit, avec le fichier environnant servant déjà de contexte. La portée actuelle est mono-fichier ; le support multi-fichiers est sur la roadmap.

1.5. Bob dans le terminal

Bob Shell apporte les capacités de Bob à la ligne de commande, et il y a deux façons de l'utiliser que nous trouvons particulièrement intéressantes.

Le Terminal comme Espace de Travail : Travailler avec un assistant de développement IA dans le shell est devenu un facteur de forme populaire à part entière — il s'associe naturellement avec la façon dont de nombreux développeurs pilotent déjà Git, les builds et les tests, et est devenu partie intégrante du flux de travail quotidien pour beaucoup d'équipes. C'est le moyen le plus fiable d'apporter l'IA aux serveurs distants ou aux environnements où une intégration IDE native n'est pas disponible : Partout où tu as un terminal, tu peux avoir Bob.
De Déterministe à Automatisation Adaptative : Bob Shell brille dans les sessions non interactives comme les tâches planifiées et les scripts de déploiement dans les pipelines CI/CD. Partout où un script aujourd'hui délègue à un outil déterministe, il peut déléguer à Bob avec le contexte complet du dépôt environnant — et l'automatisation qui sort de l'autre côté est plus adaptative qu'un pipeline fixe.

Nous publierons un article de suivi sur ce que nous avons appris en exécutant Bob de manière non interactive en CI : les modèles qui fonctionnent bien en pratique, y compris les résumés de PR, le signalement des risques et l'intégration dans l'automatisation existante.

2. Rends ton dépôt Bob-ready

Les dépôts où Bob produit son meilleur travail partagent quelques traits en commun. Aucun d'eux n'est spécifique à l'IA — ce sont les mêmes choses qui rendent un dépôt agréable à travailler pour n'importe quel développeur — mais chacun d'eux donne à Bob plus avec quoi travailler.

Tests rapides et fiables. Si npm test (ou ton équivalent) prend cinq minutes ou échoue par intermittence, la boucle d'itération ralentit jusqu'à ramper et le signal de retour se dégrade. Les tests sous une minute sont un multiplicateur pour n'importe quel développeur ; pour un assistant IA travaillant en cycles serrés, ils sont essentiels.

Commandes de build et test documentées. Un Makefile, une section scripts de niveau supérieur dans package.json, ou un bloc README — quelque part Bob peut trouver "comment j'exécute ça". Sans ça, Bob doit inférer, et l'inférence est là où les erreurs entrent.

Style exécutable. Linters et formateurs qui s'exécutent à la sauvegarde ou en CI. Bob récupère tes conventions de ceux-ci. Les règles explicites et vérifiables par machine surpassent les conventions implicites à chaque fois.

Un agents.md à la racine du dépôt. Structure du projet, fichiers clés, normes de codage, à faire et à ne pas faire. C'est le fichier à effet de levier le plus élevé que tu peux ajouter pour l'assistance IA. La bonne façon d'y penser est comme un CONTRIBUTING.md écrit pour un LLM plutôt que pour un nouvel employé.

Documentation d'architecture en markdown, à côté du code. Même les documents courts aident. Un docs/architecture.md qui décrit les modules et leurs limites permet à Bob de répondre "où va ça ?" sans re-dériver la conception à partir des imports.

Quelques choses que nous avons apprises en chemin :

Les gros fichiers de règles réduisent le signal. Au-delà de quelques centaines de lignes, la performance du modèle se dégrade. Divise les règles par domaine — agents.md à la racine du dépôt, readme.md scopé par package — plutôt que de tout concentrer dans un fichier.
Compose ton ingénierie. Quand tu termines une tâche, demande à Bob de distiller les apprentissages pertinents dans le fichier de règles ou dans une compétence. Le dépôt devient un environnement plus productif au fur et à mesure que tu l'utilises.
Itère, ne fais pas de one-shot. Une conversation multi-tours qui atterrit le bon changement de manière cohérente surpasse un seul long prompt qui en atterrit quatre-vingts pour cent.

3. Sécurité et contrôle

Bob a plusieurs couches de protection qui travaillent ensemble plutôt qu'un seul garde-fou faisant tout le travail. La version courte, adaptée à un premier article :

Approuve manuellement chaque action, ou auto-approuve par classe d'outil (lecture seule versus écriture) une fois que tu fais confiance au flux de travail.
.bobignore garde Bob hors des fichiers qu'il ne devrait pas lire — identifiants, artefacts générés, tout ce qui est sensible.
Les règles personnalisées appliquent les normes de codage sur Bob de la même manière qu'elles les appliquent sur les développeurs.
Les points de contrôle automatiques font de la récupération d'un changement indésirable une action en un clic.
Tes prompts ne sont pas utilisés comme données d'entraînement !

L'auto-approbation, en particulier, vaut la peine d'être délibéré à ce sujet. C'est l'un des principaux contrôles que tu as sur combien Bob peut faire entre les points de contrôle avec toi, et l'élargir est un gain de productivité qui te demande aussi un peu plus de décider ce qui tombe dans cette enveloppe et ce qui n'y tombe pas. Une valeur par défaut sensée pour la plupart des développeurs est d'auto-approuver les outils en lecture seule, de laisser les actions d'écriture en approbation manuelle pendant au moins les premières semaines, et d'être particulièrement réfléchi avec tout ce qui exécute des commandes shell ou atteint des systèmes au-delà de ton arbre de travail local. Les autres contrôles dans la liste — .bobignore, règles personnalisées, points de contrôle — sont conçus pour se composer avec l'auto-approbation plutôt que de la remplacer.

4. Commencer

Installe IBM Bob depuis notre site web, ou installe Bob Shell via ton terminal de choix.
Consulte notre guide des meilleures pratiques et consulte nos directives de sécurité.
Commence avec une vraie tâche — Tu apprends mieux quand Bob aide avec de vrais problèmes.

Liens