No. 17 · Technical

Technique : Le harnais anti-dérive

Comment un ensemble d'aides automatisées garde toutes les parties d'une base de code en croissance en accord les unes avec les autres pendant qu'une IA la construit, expliqué pièce par pièce.

Les applications logicielles modulaires modernes se composent de fonctionnalités qui sont souvent constituées de dizaines de fichiers. Ces composants fonctionnent fréquemment comme des « chaînes » de pièces reliées, couvrant l'exigence écrite, la conception de la base de données, la logique du programme, les interfaces utilisateur, la documentation et les ressources de formation. Quand une IA modifie une pièce, ce composant peut facilement se désynchroniser du reste de la base de code. Même si chaque modification est correcte, l'intégrité de l'application commence à s'éroder à chaque changement subséquent. Pour résoudre ce problème, nous construisons un harnais qui contient plusieurs aides automatisées distinctes afin que les applications demeurent intactes au fil d'une variété de modifications.


## §01 Le problème de la dérive

Lorsqu'on demande à une IA d'implémenter un changement dans un secteur, comme l'ajout d'un nouveau champ à un formulaire, l'agent accomplira ce travail rapidement. Cependant, il pourrait ne pas vérifier le reste du code pour voir ce que ce changement a touché par ailleurs. Par exemple, si vous ajoutez un champ « Deuxième prénom » à un formulaire, cette information doit se refléter dans la base de données, la logique d'affaires, la validation du formulaire, la documentation, et même dans les captures d'écran utilisées pour la formation. Parce qu'il est focalisé au laser sur la tâche que vous lui confiez, l'agent d'IA omet souvent d'effectuer les vérifications nécessaires pour s'assurer que le code dans son ensemble est intact.

Un utilisateur d'IA expérimenté fera une pause toutes les quelques étapes et invitera l'agent à tout vérifier, ce que l'agent fera, constatant souvent que des incohérences ont été introduites. Ces incohérences sont connues sous le nom de « régressions » ou de « dérive » dans le domaine de l'IA. Bien que l'agent puisse détecter cette dérive lorsqu'on l'y invite, cela exige de la rigueur de la part de l'utilisateur, qui doit penser à le demander. Mais compter sur l'utilisateur pour s'en souvenir, ou sur l'IA pour faire les vérifications de la même manière chaque fois, est risqué. C'est pourquoi nous introduisons un ensemble commun de procédures pour détecter la dérive et la signaler à l'agent de façon proactive, que quelqu'un s'en souvienne ou non.

La dérive est facile à manquer. Souvent, le code modifié peut toujours fonctionner. Mais ce qui est invisible, c'est le bris dans la cohérence et la fidélité de l'application. Et de plus, cette dérive ouvre la porte à une incohérence qui s'aggrave avec le temps. Si cette même interface utilisateur comporte un champ « Deuxième prénom », mais que la base de données ne l'a pas, ce bogue pourrait ne pas être détecté immédiatement. Pire encore, l'agent d'IA réexaminera ce code plus tard et pourra trouver l'incohérence, mais il n'y aura aucune réponse faisant autorité quant au fichier qui est correct. Les problèmes commencent à s'accumuler, et l'IA pourrait même annuler un changement parce qu'elle trouve le bogue et fait la mauvaise attribution. Le code est son propre type de documentation, et lorsqu'il y a des désaccords, la dérive s'aggrave de façon invisible. 

"Le code produit par une IA est généralement correct du point de vue fonctionnel à 98 ou 100 pour cent, en ce sens qu'il se compile et s'exécute. Mais ses pratiques font croître la dérive de façon invisible avec le temps, et la base de code se fragmente à chaque révision."


## §02 Une fonctionnalité est une chaîne

Le code des applications modernes cherche à être « modulaire », c'est-à-dire que les composants sont construits une seule fois et réutilisés à plusieurs reprises au besoin, et « DRY », un acronyme anglais signifiant « Don't Repeat Yourself » (ne vous répétez pas). Ces pratiques font en sorte que vous créez le code une seule fois et que vos applications sont faciles à entretenir. Mais cela signifie aussi que les fonctionnalités sont souvent découpées en petites pièces interconnectées. Quand un fichier en requiert un autre, on parle d'une dépendance. Les fonctionnalités peuvent alors être constituées de « chaînes » de dépendances. Quand l'IA modifie un maillon de cette chaîne, elle met souvent à jour de façon fiable le maillon ou les deux maillons juste à côté, parce que les dépendances sont claires, puis elle s'arrête. Plus tard, lorsque le travail reprend ailleurs, l'IA peut lire une autre partie de la chaîne, désormais périmée, et bâtir par-dessus. La chaîne se brise un peu plus à chaque fois. Retirez un champ de la base de données, par exemple, et ce changement doit se répercuter jusqu'à l'écran, à la documentation et aux notes de formation. La plupart du temps, ce n'est pas le cas.

La dérive d'une application voyage fréquemment de deux façons. Elle voyage le long de la chaîne d'une fonctionnalité, maillon par maillon. Et elle voyage entre les fonctionnalités, quand quelque chose de partagé, un composant renommé ou une bibliothèque périmée, change à un endroit et brise discrètement un autre. Un bon harnais détecte les deux, et il les détecte pendant que le travail se fait, et non lors d'un nettoyage des mois plus tard. Les sept contrôles anti-dérive qui suivent offrent des stratégies pour repérer et maintenir l'intégrité. Chacun est bâti à partir de petites pièces réutilisables : de courts fichiers d'instructions que l'IA suit (appelés compétences, ou « skills »), des déclencheurs automatiques qui se déclenchent à des moments fixés (appelés crochets, ou « hooks »), et des vérifications automatiques rapides (appelées évals). Ces méthodes s'installent aux côtés de l'agent constructeur et appuient l'audit du processus de développement.


## §03 Contrôle 1 : Suivre le changement (l'arpenteur de chaîne)

Cette première fonctionnalité suit le changement vers l'extérieur le long de la chaîne des dépendances de la fonctionnalité. Dès que l'IA modifie un fichier, l'arpenteur part de ce fichier et passe à ses voisins dans les deux directions : les pièces qui l'alimentent et les pièces qui en dépendent. À chaque étape, il compare les deux extrémités. Les noms, les champs, les promesses concordent-ils toujours? Là où ce n'est pas le cas, il consigne exactement ce qui s'est désaligné. Il continue d'arpenter jusqu'à une distance fixée et produit un rapport bien rangé de ce qui a dérivé. Son avantage est la portée : il vérifie toute la chaîne plutôt que le maillon ou les deux maillons à côté du changement, et ses constats sont assez précis pour qu'un réviseur puisse voir exactement ce qui ne s'accorde plus.


## §04 Contrôle 2 : Cartographier l'activité (la carte de chaleur des empreintes)

Cette méthode tient un registre de l'endroit où le travail se fait. Chaque fois que l'IA touche un fichier, elle ajoute une marque. Une simple carte de chaleur montre alors le projet sous forme de grille de tuiles, où les fichiers les plus actifs brillent le plus fort et où le changement le plus récent est marqué. À elle seule, elle ne détecte aucune dérive. Ce qu'elle vous donne, c'est une empreinte de l'endroit où l'action s'est déroulée, pour que les autres vérifications, plus intelligentes, sachent où regarder en premier. Elle est peu coûteuse, ne nécessite aucune configuration et est utile dès le premier jour.


## §05 Contrôle 3 : Petits tests automatiques (les évals de chaîne)

Ce contrôle effectue un petit test automatique pour un type précis de discordance. La conception de la base de données correspond-elle au script qui la construit? L'interface publiée correspond-elle à sa documentation? Chaque test lit les deux extrémités et signale toute différence. Les tests résident juste à côté du code et grandissent avec le projet : quand un nouveau type de maillon apparaît, vous ajoutez un test pour lui. Chaque fois que l'IA modifie un fichier, seuls les tests qui touchent ce fichier s'exécutent. Ils sont rapides, donnent la même réponse chaque fois, et parce que l'équipe les écrit, ils détectent exactement les erreurs que ce projet a tendance à commettre.

"Le surveillant anti-dérive n'écrit jamais l'application lui-même. Il surveille le constructeur, lit les preuves que produisent les vérifications automatiques, les confirme par rapport au code, et décide si quelque chose mérite d'être signalé. Du contrôle de la circulation aérienne, pas un pilote." · Le harnais anti-dérive, note de conception


## §06 Contrôle 4 : Faire compter la note de sauvegarde (l'épine des commits)

Les développeurs enregistrent déjà leur travail par lots, chacun accompagné d'une courte note qui le décrit (un commit). Cette approche fait jouer un double rôle à cette note. La note suit un modèle fixé qui liste les pièces touchées par le changement et les pièces liées qui ont été vérifiées. Quand le développeur dépose le lot, une vérification automatique s'assure que la note est complète avant de la laisser passer, et l'IA rédige la note à partir de ce qu'elle a réellement changé. Parce que cela se produit au moment où le travail est classé, le registre est digne de confiance, et avec le temps l'historique du projet devient un compte rendu interrogeable de ce qui a changé et de ce qui a été tenu en phase.


## §07 Contrôle 5 : Une fiche par fichier (le manifeste des dépendances)

Cette méthode attribue à chaque fichier important une petite fiche listant ce qui l'alimente et ce qui en dépend. La fiche est reconstruite chaque fois que le fichier change, et une vérification rapide compare la fiche au contenu réel du fichier pour repérer toute incohérence. Un petit diagramme montre ensuite le fichier au centre, avec ce qui entre empilé au-dessus et ce qui sort en dessous, chaque élément marqué sain, périmé ou brisé. Parce que chaque relation est écrite clairement, les autres vérifications peuvent lire les fiches au lieu de relire tout le code.


## §08 Contrôle 6 : Une liste de contrôle de fin d'étape (le balayage de dérive)

Ceci exécute automatiquement la liste de contrôle de fin d'étape de la personne, à la fin de chaque étape. Il vérifie les choses évidentes : la documentation correspond-elle à l'interface en service, les champs de la base de données apparaissent-ils là où ils le devraient, les notes de formation décrivent-elles les écrans actuels? Il produit un court rapport par étape. Si trop de dérive est survenue, il peut arrêter l'IA et exiger que la dérive soit corrigée avant que le travail ne se poursuive. Il s'exécute une fois par étape plutôt qu'à chaque modification, de sorte que son coût est prévisible, et il peut tenir la ligne en refusant d'avancer tant que les choses ne sont pas revenues en accord.


## §09 Contrôle 7 : Le tableau de bord partagé (le tableau de tuiles)

Voici le tableau de bord pour l'humain et l'IA. Il dessine le projet sous forme de grille, les fonctionnalités d'un côté et les quatorze maillons en haut, et colore chaque case en fonction de ce que les autres vérifications ont trouvé. C'est une page unique que l'équipe peut ouvrir pour voir, d'un coup d'œil, où tout se situe, et il peut afficher les résultats de n'importe laquelle des autres approches sans les modifier. La figure 17.7 le montre en marche en direct : le constructeur travaille, le surveillant anti-dérive balaie l'ensemble, et les notes signalées s'accumulent.


## §10 Des surveillants en marge

Ces contrôles se greffent à l'agent constructeur. Un seul agent d'IA, surchargé de toutes les préoccupations à la fois, dérive, sécurité, tests, documentation, style d'écriture, devient débordé, et ses instructions enflent jusqu'à ce qu'elles cessent d'aider. Le harnais anti-dérive applique une approche de surveillant ou de superviseur. Le constructeur garde son attention sur la construction. Les surveillants s'exécutent séparément, à côté du projet, comme leurs propres agents parallèles. Chacun observe les fichiers du projet, lance ses propres vérifications quand quelque chose change, et laisse une note, un billet, dans un dossier partagé à l'intention du constructeur. L'agent constructeur lit ces billets au début de son étape suivante et les traite comme n'importe quelle autre tâche.

Chaque surveillant peut s'exécuter selon son propre horaire, et même sur une IA moins coûteuse pour les vérifications de routine, réservant le modèle le plus puissant pour les décisions difficiles. Ajouter une nouvelle préoccupation signifie ajouter un nouveau surveillant, et non en empiler davantage sur le constructeur. La figure 17.7 est cette idée en miniature : le surveillant anti-dérive qui observe, balaie et laisse des notes pendant que le constructeur travaille.


## §11 Comment les combiner, et ce qui reste à trancher

Ces méthodes sont additives, et vous pourriez ne pas avoir besoin des sept. Le jumelage utile le plus simple est la carte de chaleur plus le balayage de fin d'étape : l'une montre où le travail se fait, l'autre exécute la liste de contrôle à chaque étape. Ajoutez de meilleures évals pour appuyer votre développement, et expérimentez en élargissant la couverture avec une variété de contrôles de surveillance différents.

Tags: anti-drift, harness, agents, quality, observability, change-management

Open the interactive version