Le développement agentique évolue à une vitesse sans précédent, même à l'aune des standards du monde tech. Les tutoriels et ressources disponibles en ligne couvrent principalement des fonctionnalités individuelles sur des scénarios simples greenfield.

En construisant Bob et en échangeant avec d'innombrables praticiens sur le terrain, issus d'industries très variées, un ensemble de concepts a émergé pour améliorer l'efficacité et l'expérience d'utilisation de Bob.

Ces concepts s'appliquent également aux projets complexes utilisant des technologies moins répandues.

Concept 1 : Le cycle — explorer, planifier, implémenter, vérifier

Le cycle explorer, planifier, implémenter, vérifier, avec une boucle externe pour l'amélioration continue des guides et des capteurs

Le mode d'échec le plus courant en ingénierie logicielle agentique est l'absence de structure. La cohérence conversationnelle imite la structure et on est tenté de regrouper toutes les étapes d'une implémentation dans une seule conversation. Les sessions semblent productives, mais le coût ne devient visible qu'à la revue.

Écrire du code à la main imposait une structure naturelle. L'implémentation était coûteuse, donc planifier avant d'implémenter semblait intuitivement raisonnable. La compréhension s'accumulait au fil de la frappe, et les mauvaises hypothèses avaient tendance à émerger pendant ce processus. Les agents IA suppriment cette friction. Le code est désormais bon marché, ce qui a aussi effacé notre intuition de la structure. Une structure qui était autrefois un sous-produit de la lenteur doit maintenant être délibérée.

Utiliser ce cycle délibérément peut fournir cette structure :

Explorer produit de la compréhension
Planifier produit des décisions
Implémenter produit du code
Vérifier produit des preuves.

Suivre ce cycle t'aide à rester concentré, structuré, et à atteindre tes objectifs plus rapidement et plus régulièrement.

Un seul passage dans le cycle peut prendre vingt minutes ou trois jours. Un passage peut contenir des sous-cycles, et la répartition du temps entre les phases varie beaucoup selon la tâche.

Une description détaillée du cycle est disponible ci-dessous dans Approfondissement : Exécuter le cycle.

Concept 2 : La fenêtre de contexte est la ressource rare

Être attentif à la fenêtre de contexte est l'habitude au meilleur retour sur investissement.

Qu'est-ce que la fenêtre de contexte ?

Les modèles sont sans état. Un chat n'est pas une session persistante avec une mémoire : chaque tour renvoie tous les messages précédents et ajoute la nouvelle réponse à la fin. La fenêtre de contexte est la quantité maximale d'entrées qu'un modèle peut accepter lors d'un de ces tours. Dans Bob V2, c'est 270k tokens (gestion de la fenêtre de contexte).

La fenêtre se remplit avant même le premier message :

Chargé dès le départ : le prompt système de Bob, la description du mode actif, le fichier agents.md du dépôt, et une description de chaque outil Model Context Protocol (MCP) connecté (MCP dans Bob).
Ajouté pendant la session, invisiblement : lectures de fichiers, résultats d'outils, fichiers de skills chargés par Bob, sorties de sous-agents.

La fenêtre de contexte se remplit et est compactée en un résumé

Quand la fenêtre se remplit, Bob compacte la conversation. Bob remplace la conversation par un résumé et le travail continue. Cela maintient la session en vie, mais c'est volontairement avec perte. Bob décide automatiquement quels détails survivent, et rien ne signale ceux qui n'ont pas survécu. Une session compactée deux fois tourne sur le résumé d'un résumé.

Un seul appel MCP peut retourner des dizaines de milliers de tokens, et une série de lectures de fichiers dilue ce qui a été discuté plus tôt dans la session. Les descriptions de modes, les fichiers de règles et les serveurs MCP le font plus lentement et moins visiblement. Bob décompose la fenêtre par source, et il vaut la peine d'examiner ce détail à mesure que la configuration évolue.

L'indicateur de fenêtre de contexte de Bob, déplié pour afficher la session en cours par source

Les Bobcoins sont principalement calculés sur la base du nombre de tokens. Donc le coût d'une conversation croît de façon quadratique par rapport à sa longueur. Les conversations longues coûtent bien plus de Bobcoins que les courtes ! (Documentation Bobcoins)

Travailler avec la fenêtre de contexte, pas contre elle

Répartis le travail sur des conversations séparées. Une tâche, une session. C'est le même raisonnement que la responsabilité unique en code. Une conversation doit avoir une seule raison d'exister, par exemple « dessine un diagramme d'architecture du composant X » ou « crée un plan d'implémentation pour la fonctionnalité Y ». Tout ce qui se trouve dans la fenêtre de contexte influence ce qui vient ensuite, y compris les approches qui n'ont pas fonctionné. Une session bloquée tend à rester bloquée, car les tentatives échouées sont toujours là, et le modèle les lit comme des indices sur la nature de cette tâche (context poisoning).
Reviens en arrière plutôt que d'argumenter avec Bob. Quand une conversation dérive vers un comportement indésirable, reviens au dernier bon message, modifie-le et continue à partir de là. Cela annule aussi tous les changements que Bob a effectués localement, ce qui garde la fenêtre de contexte petite et propre (rollback).
Garde tout ce qui vaut la peine d'être conservé dans un fichier, pas dans le chat. Les plans, les conclusions et les décisions appartiennent à un fichier. Un collègue peut relire un document markdown et le transmettre à une nouvelle session ; un historique de chat ne permet ni l'un ni l'autre.
Les sous-agents gardent le gros du travail hors de la fenêtre de contexte. Bob décide quand en lancer un, et seuls les résultats reviennent. En demander un directement fonctionne aussi, quand une tâche va produire une sortie que personne n'a besoin de lire (subagents).
Sois attentif à ce qui entre dans la fenêtre de contexte et à sa valeur ajoutée. Vérifie régulièrement tes guides et capteurs, comme abordé dans la section suivante, et prends le temps de les améliorer.

Concept 3 : Deux types d'éléments fondamentaux — guides et capteurs

Sur un long projet, que la base de code s'améliore ou se dégrade dépend moins de Bob que de ce qui oriente son travail et contrôle ses sorties. Il existe de nombreux éléments disponibles : règles, skills, modes, hooks, sous-agents, linters externes et agents de revue. Presque tous remplissent l'un de ces deux rôles.

Les guides orientent Bob avant ou pendant son travail (Feedforward). Les règles, les skills et les modes sont tous des guides.
Les capteurs rendent compte après que Bob a agi (Feedback). Les tests, les linters, les vérificateurs de types, les sessions de navigateur interactives et les agents de revue sont tous des capteurs.

Un humain devant un ordinateur portable pointe une flèche vers Bob, et Bob pointe une flèche vers le code. Une flèche étiquetée « guides » arrive sur Bob depuis le haut, annotée avec règles, skills et modes. Une flèche étiquetée « capteurs » repart du code vers Bob, annotée avec tests, linters et agents de revue.

1. Guides

Tout ce qui est fourni à Bob pour orienter le travail est un guide. Il existe trois principaux éléments qui t'aident dans ce sens, et ils fonctionnent en ajoutant du texte dans la fenêtre de contexte en plus du prompt que tu as saisi. Ils diffèrent dans le moment où ce texte arrive et ce qui le déclenche.

Les règles sont toujours actives, les modes sont activés par l'utilisateur, les skills sont activés par Bob

Les règles sont toujours actives. agents.md à la racine du dépôt est le principal, et le principal conseil à son sujet est de le garder court. Chaque ligne est en compétition pour l'attention à chaque tour, donc un long fichier de règles dégrade la capacité de Bob à suivre n'importe quelle règle individuelle (rules).
Les modes sont activés par l'utilisateur. Les modes intégrés sont : Ask est en lecture seule. Plan élabore un processus de planification et transmet le résultat à Agent, qui passe à l'action. Des modes personnalisés peuvent être ajoutés facilement (modes, ajouter un mode personnalisé).
Les skills sont activés par Bob quand il les juge pertinents. Seule une courte description de skill est toujours active. Le corps principal du skill n'est chargé dans le contexte qu'à la demande. Cela rend les skills très économes en tokens (skills).

Tout ce qui se trouve dans le fichier de règles utilise des tokens à chaque tour, que ce tour en ait eu besoin ou non, donc garde-le minimal et laisse le reste attendre jusqu'à ce qu'il s'applique.

2. Capteurs

Tout ce qui donne à Bob un retour sur le travail produit est un capteur. Les signaux utiles dépendent de la base de code et de la stack, donc l'ensemble à constituer diffère d'un projet à l'autre et demande un vrai travail de mise en place. Les capteurs les plus précieux sont exécutables par machine et lancés par Bob durant la phase d'implémentation. Les capteurs se divisent en deux catégories.

Les capteurs computationnels sont déterministes : tests, linters, vérificateurs de types, compilateurs. Les verdicts sont exacts et reproductibles, suffisamment économiques pour que Bob les exécute fréquemment. La couverture est limitée par les systèmes qu'une équipe a construits et maintient.
Les capteurs basés sur l'IA sont flexibles et non déterministes. Un agent de revue lit pour l'intention, et pour les choses pour lesquelles un linter n'a pas de règle. La sortie est un jugement, pas une mesure. Elle varie entre les exécutions et les coûts et la durée limitent la fréquence d'utilisation (code reviews).

Les brancher offre plusieurs options, dans un ordre approximatif de friction croissante :

Les hooks sont l'option déterministe à moindre friction. Une vérification s'exécute à un point fixe, à chaque fois, que Bob l'ait jugée pertinente ou non. Voir la documentation des hooks.
Les skills sont souvent utilisés comme guides, mais un skill qui exécute une revue est un capteur, et c'est la façon la moins contraignante d'ajouter une vérification non déterministe. Voir la documentation des skills.
L'intégration continue (CI) place un agent de revue dans le pipeline, sur chaque pull request, pour toute l'équipe plutôt qu'un seul développeur. Voir l'agent de revue PR en action.

Approfondissement : Exécuter le cycle

Les limites de phase sont aussi des limites de contexte, ce qui est la raison pratique de les maintenir distinctes : les bavardages d'exploration n'ont rien à faire dans la conversation où le code est écrit.

1. Explorer

L'exploration varie beaucoup selon ton rôle et la tâche à accomplir. Elle peut signifier une prise en main d'une nouvelle base de code ou estimer l'impact d'un refactoring majeur. Quelques exemples :

Demande à Bob de produire un diagramme d'architecture du système existant avant d'y apporter la moindre modification. Voir le tutoriel de génération de diagrammes d'architecture, ou la même chose en vidéo.
Demande une présentation de démarrage personnalisée sous deux angles, une fois en tant qu'utilisateur naviguant dans le produit et une fois en tant que développeur parcourant le code. Fournir des informations sur ton expertise et ta tâche aide à personnaliser le document (inspecting a codebase).
Sur IBM Z et IBM i, utilise les options spécifiques à la plateforme. Le problème d'exploration sur ces systèmes est différent et bénéficie grandement des outils spécialisés fournis dans les packages premium. Voir le Package Premium pour Z (docs) et le Package Premium pour IBM i (docs).

L'exploration peut aussi inclure la construction de choses que tu as l'intention de supprimer. L'implémentation est bon marché maintenant, donc un prototype ciblé est le moyen le plus rapide de savoir si une approche résiste au contact de la base de code. Kent Beck appelait cela une implémentation en spike il y a vingt-cinq ans, et la discipline est la même : construis-le pour apprendre quelque chose, garde l'apprentissage, jette le code.

L'implémentation bon marché augmente la valeur de l'architecture et de la qualité du code plutôt que de la diminuer. Il est maintenant facile de produire une grande quantité de code qui fonctionne et qui est erroné.

2. Planifier

La phase de planification est celle où le levier est le plus grand. Tout ce que le plan réussit paye deux fois : une fois dans l'implémentation, et à nouveau quand le changement quitte les mains de l'auteur et qu'un collègue doit le relire.

Ce dont un bon plan a besoin :

Court et précis, les deux. Les plans doivent être lus.
Explicite sur le résultat attendu, y compris les parties incertaines. Savoir ce qui est inconnu représente la majeure partie du travail, et le découvrir en est le reste.
Dans un fichier. Les plans ne doivent pas vivre dans une session de chat.

Il existe de nombreuses façons de créer un plan, mais le mode Plan intégré est le point de départ le plus simple (comme dans ce tutoriel). Le mode Plan est conçu pour être accommodant et tend à combler les lacunes. Bien que cela permette des itérations rapides dans de nombreux cas, plus de rigueur est parfois nécessaire. Il peut construire un plan compétent autour d'une mauvaise hypothèse sans la remettre en question. Un skill dédié qui remet le plan en question — grill-me de Matt Pocock par exemple — est le moyen le moins coûteux d'obtenir un regard critique avant que l'hypothèse ne devienne du code.

Sur le développement piloté par les spécifications (SDD). Le terme couvre beaucoup de terrain et est encore en évolution. Les gens le traitent comme une décision binaire, mais c'est plus proche d'un spectre :

Spec-first : le plan précède l'implémentation. C'est presque incontournable.
Spec-anchored : la spec reste après l'implémentation, comme documentation et comme standard que les implémentations doivent respecter.
Spec-as-source : la spec est le fichier source. L'humain édite la spec ; l'humain n'édite pas le code.

Le niveau qui convient dépend de l'équipe, de la criticité/maturité de la base de code et du secteur. La surcharge des niveaux supérieurs de SDD peut être douloureuse pour une itération rapide. Dans l'automobile, où le développement piloté par les spécifications précède l'IA de plusieurs décennies, le SDD s'adapte très bien aux pratiques existantes.

3. Implémenter

L'implémentation est la phase la plus directe, et Bob en gère la quasi-totalité.

Observer Bob travailler et l'interrompre pour clarifier est optionnel et souvent utile. Traite la fréquence comme un signal : des interruptions constantes signifient que le problème est dans le plan, et la solution est de revenir en arrière plutôt que de continuer à corriger.

N'hésite pas à jeter une implémentation entière et à revenir au mode Plan. Le code est la partie bon marché.

4. Vérifier

La vérification se divise en deux catégories distinctes : la vérification automatisée et la vérification manuelle.

La vérification automatisée est pilotée par les capteurs disponibles pour Bob ou imposés via des hooks. Ils sont exécutés fréquemment pendant la phase d'implémentation sans intervention humaine. Les principales catégories avec quelques exemples courants sont :

Validité : Est-ce que ça compile, typecheck, parse ?
- Mesuré : pass/fail, couverture de types
- Outils : tsc, mypy, cargo check, javac
Comportement : Est-ce que ça fait la bonne chose ?
- Mesuré : taux de réussite, couverture de branches
- Tests unitaires, tests d'intégration, tests end-to-end
- Outils : pytest, Jest, Playwright, Stryker
Maintenabilité : Ce code vaut-il la peine d'être conservé ?
- Mesuré : complexité, duplication, violations de frontières
- Outils : ESLint, Ruff, Lizard, ArchUnit
Sécurité : Ce code est-il sûr ?
- Mesuré : findings par sévérité, CVEs
- Outils : Semgrep, CodeQL, gitleaks, npm audit

Ils permettent à Bob de détecter ses propres erreurs et d'améliorer la qualité pendant la phase d'implémentation. Une bonne couverture de tests est une protection essentielle contre les régressions : elle garantit que Bob n'a rien cassé.

Dans ce cycle, la vérification est listée comme une phase séparée à la fin de la boucle, ce qui fait principalement référence à la vérification manuelle. La vérification manuelle commence par exécuter le changement et comparer le comportement observé au comportement spécifié dans le plan. Un écart se réduit généralement à l'une de ces deux causes :

L'implémentation a dévié du plan. La correction est dans le code.
Le plan ne reflète pas ce que tu avais l'intention de construire. Le plan doit être affiné. C'est de loin le cas le plus fréquent.

L'inspection manuelle teste donc le plan et l'implémentation en même temps.

Une vérification supplémentaire devrait avoir lieu dans les pipelines CI/CD. C'est une pratique bien établie en ingénierie logicielle, mais elle peut être améliorée en utilisant des agents de codage headless. Un exemple : une revue automatisée sur chaque pull request, exécutée via Bob Shell, complète les relecteurs humains sans les remplacer. Voir la vidéo de l'agent de revue PR en action et la documentation pour exécuter Bob Shell de façon non interactive.

Travailler en équipe

Tout ce qui précède décrit la boucle interne d'un seul développeur. La boucle externe commence quand les changements entrent dans la file de revue. Chaque diff arrive maintenant plus vite et avec moins de son raisonnement attaché, tandis que le relecteur a plus à lire et moins de contexte dans lequel le lire.

Les preuves doivent voyager avec le travail. Le pourquoi compte davantage qu'avant, relativement au comment, parce que le comment n'est plus la partie coûteuse à produire.

En pratique, cela signifie que le plan voyage avec le changement : les équipes l'attachent à la pull request ou le rajoutent au ticket original en parallèle de la revue. Le mécanisme dépend de l'outillage.

Ce que la boucle externe fait au processus d'une équipe est un sujet en soi, qui fera l'objet d'un prochain article.

Quelques réflexions sur le prompting

Ces dernières années, une grande importance a été accordée à la rédaction correcte de prompts pour les LLMs, avec toute une catégorie de métier appelée « prompt engineer » qui en a émergé. À ce stade, une grande partie du prompting est gérée à l'intérieur du harness. L'importance des techniques de prompting spécialisées a diminué au profit d'une approche méthodologique. Voici quelques lignes directrices :

Itérer bat le prompting. Quand Bob fait autre chose que ce que tu as demandé, reviens en arrière et réécris le message qui en est la cause. Corriger en avançant laisse la mauvaise réponse, la plainte à son sujet et la nouvelle tentative toutes dans la fenêtre.
La méthodologie bat le prompting. Un prompt est limité à une session. Un fichier de règles, ou une vérification que Bob peut exécuter lui-même, continue à fonctionner dans chaque session après celle qui l'a produit, ce qui est le seul type d'investissement qui s'accumule ici.
Donne à Bob le brief qu'un ingénieur senior recevrait. Un collègue compétent à qui on confie une tâche vague demandera ce qui compte comme terminé et ce qu'il a le droit de toucher ; Bob ne demandera pas, donc mets les deux dans le message.
Dis ce qu'il faut faire, pas ce qu'il ne faut pas faire. « N'utilise pas de class components » exclut une option et laisse le reste de l'espace ouvert, donc Bob choisit parmi ce qui reste, ce qui est une autre approximation. Nommer la cible à la place — function components avec hooks — ferme la question en un seul tour.
Toute instruction donnée plus de deux fois appartient à un fichier. C'est à ça que servent agents.md et les skills.
Des instructions de prompting plus détaillées se trouvent dans le tutoriel écrire des prompts efficaces.

Points clés à retenir

L'absence de structure est le plus grand problème. Suivre le cycle Explorer → Planifier → Implémenter → Vérifier t'aide à rester concentré et à atteindre tes objectifs plus rapidement et plus régulièrement.
Le contexte est la ressource rare, et les phases sont des limites de contexte. Ne transporte pas les bavardages d'exploration dans l'implémentation.
Le plan est l'artefact de revue. Relire un plan est plus efficace que relire un diff, pour l'auteur comme pour le relecteur.
Tout ce qui vaut la peine d'être conservé quitte le chat. Plans, décisions et conclusions appartiennent à un fichier. Tu peux diff, relire, versionner et transmettre un fichier à un autre agent.
La vérification devrait être exécutable par machine, ce qui signifie que tu dois la concevoir pendant la planification, pas la découvrir après.

Sources et lectures complémentaires

Simon Willison, Agentic engineering patterns
Birgitta Böckeler, Harness engineering

Documentation et tutoriels IBM Bob :