Que se passe-t-il lorsqu'on applique des modèles de développement d'IA à une base de code que personne ne comprend vraiment ?

Thoughtworks a récemment publié une série d'articles utiles sur le développement assisté par l'IA sur le site de Martin Fowler. Amorçage des connaissances, Ancrage du contexte, Collaboration axée sur la conception. À lire absolument. Ces articles sont également conçus pour un code source bien défini.

La plupart des entreprises australiennes ne disposent pas d'un tel code source.

Une organisation avec laquelle nous collaborons possède plus de mille systèmes en production. Âge moyen : cinq à sept ans. Ancienneté moyenne des ingénieurs : encore plus courte. Le logiciel est maintenu par des personnes qui ne l'ont pas écrit. Dans certains cas, par des ingénieurs qui étaient encore au lycée lorsque les décisions architecturales initiales ont été prises. Personne n'en a honte. C'est tout simplement la conséquence d'une longue expérience dans le secteur.

Ainsi, lorsqu'on tente d'appliquer ces modèles à un système de ce type, des problèmes surviennent de manière spécifique et prévisible. Voici ce que nous avons appris.

L'amorçage des connaissances se heurte immédiatement à un obstacle

Le principe de l'amorçage des connaissances est de créer des fichiers de contexte versionnés (vue d'ensemble de l'architecture, conventions de nommage, anti-modèles) et de les charger avant chaque session. Le problème ? Personne n'a documenté ces informations. Ou alors, la documentation existante décrit un système obsolète. Ou encore, elle décrit les intentions de l'architecte, et non la réalité du développement.

La première fois qu'une équipe essaie de créer un document d'amorçage sur un système existant, elle découvre le chantier d'archéologie auquel elle participe. C'est précieux, certes, mais ce n'était pas prévu lors du sprint.

La solution : élaborer le document d'amorçage à partir des tests, et non de la documentation. Si le code source bénéficie d'une couverture de test raisonnable, les tests décrivent le comportement actuel. Injectez la suite de tests dans le modèle et demandez-lui de générer le document d'amorçage. Le résultat est basé sur le fonctionnement réel du système, et non sur les attentes initiales.

L'ancrage contextuel : d'outil de productivité à mécanisme de survie

Dans un code source bien maîtrisé, conserver un ancrage contextuel est une bonne pratique. Dans un système existant, c'est essentiel. Sans ancrage, chaque nouvelle session commence avec le modèle utilisant par défaut des schémas génériques issus de ses données d'entraînement, et vous passez la première demi-heure à corriger des décisions qui contredisent les accords de l'équipe de la semaine précédente.

Plus important encore : dans un système existant, le raisonnement derrière les décisions architecturales n'existe souvent que dans l'esprit d'un ou deux ingénieurs seniors. Lorsque ces ingénieurs partent, ce raisonnement disparaît avec eux. Le code source devient progressivement plus fragile à mesure que les décisions suivantes sont prises sans ce contexte.

Un ancrage contextuel qui capture le « pourquoi » des décisions existantes, même déduit rétrospectivement du code, constitue une forme de mémoire institutionnelle inédite pour l'organisation. Il est donc crucial de le prendre au sérieux.

La discussion axée sur la conception devient un diagnostic

Le modèle initial consiste à s'aligner sur la conception avant d'aborder l'implémentation. Dans un contexte de systèmes existants, la discussion sur la conception a tendance à faire émerger un problème délicat : personne dans la salle ne possède une représentation mentale cohérente du système qu'il s'apprête à modifier.

C'est en réalité le principal atout de ce modèle dans un contexte de systèmes existants. La représentation mentale permettra de déceler des incohérences que l'équipe a ignorées pendant des années. La discipline consiste à poursuivre cette discussion plutôt que de se précipiter sur l'implémentation une fois que la situation devient délicate.

Les équipes qui ont réussi cette approche s'attendaient à une phase d'investissement plus longue. Elles ont privilégié la compréhension à la productivité. Les équipes qui ont rencontré des difficultés s'attendaient à des résultats dès le premier sprint et ont été frustrées lorsque les premières sessions ont soulevé plus de questions que de code.

Cette frustration est une information précieuse. Elle vous révèle une vérité fondamentale du système, une vérité que vous n'étiez pas en mesure de percevoir auparavant.

L'article d'InfoQ sur le « moment décisif de l'architecture de l'IA » (https://www.infoq.com/articles/oil-water-moment-ai-architecture/) illustre bien ce phénomène : les systèmes hérités déterministes et le comportement non déterministe de l'IA créent une véritable inadéquation architecturale qu'il est impossible de masquer. Les solutions efficaces sont celles qui reconnaissent cette inadéquation et la contournent, plutôt que de prétendre que le code source est autre chose qu'il n'est.