(Ce document correspond à une présentation donnée le 17 décembre lors du meetup Claude Code à Séoul. Vous pouvez consulter l’ensemble des slides via ce lien.)
L’objectif de « conseil interne » de l’équipe AX de KORCA
- Faire adopter chez KORCA de bonnes pratiques d’agentic engineering et créer un terreau permettant de les faire progresser ensemble dans la durée.
- Chez KORCA, les « pratiques d’agentic engineering » sont définies comme « des méthodes pratiques pour utiliser des agents IA de manière à améliorer à la fois la qualité et la productivité logicielle ».
- Faire des capacités d’ingénierie un autre avantage concurrentiel clé de KORCA.
- Dans cette optique, nous avons commencé à aider l’équipe Moonlight.
La situation de Moonlight
- Moonlight, le produit phare de KORCA, se présente comme « un collègue IA avec qui lire des articles scientifiques ».
- « Discuter avec un PDF » existe depuis les tout débuts de ChatGPT. Parmi les très nombreux produits concurrents sur ce créneau, Moonlight a réussi à survivre et se trouve aujourd’hui au début de sa courbe en J (avec une récente explosion des inscriptions en Chine).
- Il y a eu d’innombrables essais et erreurs pour en arriver là, mais l’avantage compétitif principal a été de maintenir, coûte que coûte, la vitesse et le rythme de développement des fonctionnalités.
- Quelques décisions initiales prises en faveur de la vitesse
- typescript strict: false
- automatisation des tests minimale
- doublons et hardcoding tolérés
- aucune séparation stricte des rôles : presque tous les membres de l’équipe (6 sur 7) implémentent avec des agents de code et soumettent des PR
- Une fois le produit lancé sur son orbite, la dette a commencé à peser progressivement
- le produit est devenu plus complexe, l’équipe a accueilli de nombreux nouveaux membres, et beaucoup d’expériences ont commencé à tourner en parallèle
- la vitesse d’amélioration du produit a lentement ralenti, tandis que l’anxiété augmentait peu à peu
- la charge des revues de code s’est concentrée sur quelques personnes, et de petites comme de grandes erreurs sont apparues
Les défis immédiats pour l’équipe AX
- [Produit] Faire en sorte que la qualité de Moonlight s’améliore tout en accélérant l’ajout et l’amélioration de fonctionnalités.
- [Équipe] Faire en sorte que n’importe qui puisse plus facilement modifier le code de Moonlight, et réduire le stress après les déploiements.
- [Culture] Pour atteindre 1 et 2, faire collaborer l’équipe Moonlight et l’équipe AX afin de découvrir, appliquer, affiner et diffuser progressivement en interne de bonnes pratiques d’agentic engineering.
→ Nous avons estimé que la plupart de ces problèmes seraient résolus si les agents de code donnaient de meilleures réponses.
Comment amener les agents à donner de meilleures réponses ?
[1] Les faire partir d’emblée dans la bonne direction
- Une base de code de meilleure qualité apporte des avantages sur trois plans.
- Elle réduit la quantité de contexte inutile à fournir (Less is More).
- Elle pousse l’agent à suivre de bons patterns déjà présents.
- Elle permet de biaiser les réponses pour augmenter la probabilité d’un échantillonnage dans une zone du pré-entraînement où se concentrent du code de haute qualité.
- De nombreuses recherches montrent qu’un contexte de qualité produit de meilleures réponses.
- (Hypothèse personnelle) Si l’on envoie une demande à un agent dans une base de code où l’ordre des imports est trié, n’y a-t-il pas de fortes chances que, parmi le code vu au pré-entraînement, celui dont les imports sont bien ordonnés soit globalement de meilleure qualité ?
- Extrait du blog Anthropic : « le simple fait d’utiliser une police intéressante améliore aussi les autres éléments du design ».
[2] Les empêcher d’emprunter la mauvaise direction
- On peut bloquer les mauvaises trajectoires avec divers outils d’analyse statique : vérification des erreurs de type, erreurs du linter, tests automatisés, détection de code mort, contrôle de la longueur des fichiers, analyse de complexité, contraintes sur les dépendances, règles imposant un certain ratio entre code de test et code de production, etc. (et faire retravailler tant que les critères ne sont pas remplis).
[3] Leur demander surtout ce qu’ils savent bien faire
- Les humains, les LLM et les algorithmes n’excellent pas dans les mêmes tâches. Choisir intelligemment quoi utiliser et quand permet d’économiser temps et coûts.
- ex) lui dire de ne pas oublier les clés i18n vs lui demander de lancer un script qui trouve les clés i18n manquantes
- Qui fait bien quoi, quand, évolue avec le temps et dépend aussi du domaine du problème. Il est donc utile de prendre l’habitude de garder ce « ressenti » à jour dans son propre domaine.
- ex) à la sortie d’un nouveau modèle, le tester avec son propre benchmark, ou reproduire des exemples célèbres vus sur les réseaux sociaux
[4] Les aider sur ce qu’ils ne savent pas faire
- Il faut toutefois toujours vérifier qu’ils sont réellement incapables de le faire. Sauf si la délégation est trop risquée ou excessivement inefficace, il vaut mieux que l’IA ou les algorithmes prennent en charge un maximum de travail plutôt que les humains. (Le coût des tokens finira de toute façon par devenir négligeable, comparable à une facture d’électricité.)
- Et s’ils n’y arrivent vraiment pas ? Faire relire par un autre LLM.
- ex) au plus simple : « ça a été codé par un développeur débutant… »
- Si l’on veut que l’IA travaille mieux, il faut lui fournir un environnement dans lequel elle peut mieux travailler. Autrement dit, ce que les agents (actuels) ont du mal à bien faire (ici) doit être complété par des humains, des algorithmes et d’autres agents.
Les points auxquels nous avons fait attention
- Moonlight est une fusée qui commence à peine à décoller, et l’équipe AX est une invitée venue de l’extérieur.
- Nous avons absolument évité le scénario où des externes arrivent, bricolent quelque chose « pour vous », puis repartent.
- Les efforts d’amélioration de la qualité ne devaient pas (autant que possible) freiner le développement de fonctionnalités.
- Nous avons décidé de mélanger, dans des proportions raisonnables, des actions qui ne changent pas beaucoup la manière habituelle de travailler et des actions plus ambitieuses mais très efficaces.
→ Nous imaginions une démarche où l’équipe AX et l’équipe Moonlight découvrent « ensemble » des pratiques adaptées à l’équipe et au produit, les appliquent, et où la qualité du code, la qualité du produit et les compétences de l’équipe progressent en même temps.
Les principaux résultats obtenus durant les 4 dernières semaines
[1] De bonnes habitudes s’installent, et de bons patterns émergent
- Soumettre chaque jour de tout petits commits de refactoring (tidying) sans revue de PR
- Des prompts qui imitent d’anciens commits exemplaires (par exemple pour l’ajout de prise en charge de nouveaux modèles), ainsi que des prompts pour découvrir et collecter ce type de patterns
- Une SKILL de revue de code incarnant un développeur senior
[2] Début de la mesure et de la visualisation des indicateurs de qualité du code. Le nombre d’erreurs/avertissements rapporté au volume de code baisse rapidement
- Les indicateurs de qualité du code diminuent parfois progressivement, parfois de manière spectaculaire.
- Le tidying, en améliorant la base de code un peu chaque jour, a beaucoup aidé à rendre envisageables, à un moment donné, de gros refactorings et de gros chantiers.
- En appliquant knip package par package, nous avons aussi supprimé du code ancien et inutilisé.
- Les indicateurs doivent toujours être complémentaires. Il vaut bien mieux avoir 5 000 erreurs dans 100 000 lignes de code que 1 000 erreurs dans 1 000 lignes. C’est pourquoi, au lieu de regarder uniquement les nombres bruts, nous suivons le taux d’erreurs rapporté au nombre de lignes afin d’avoir des métriques de pilotage plus saines.
- Le nombre de lignes significatives, hors commentaires et espaces vides, est mesuré avec tokei.
[3] Correction d’une fuite mémoire qui persistait depuis plus d’un an
- En mobilisant tous les outils possibles, dont repomix, ainsi que diverses techniques de prompting, nous avons fini par résoudre après plusieurs tentatives une fuite mémoire qui durait depuis plus d’un an.
- Nous nous réjouissons à l’idée de pouvoir peut-être réduire le tier des instances serveur.
[4] Mise en place d’une structure d’abstraction, de prompts et de scripts permettant d’ajouter/supprimer plus facilement et plus sûrement des expérimentations menées en parallèle chaque semaine
Au final, les trois dimensions s’alignent bien : la qualité du code augmente régulièrement, le développement de fonctionnalités devient à la fois plus sûr et plus rapide, et les compétences d’ingénierie (agentique) de l’équipe progressent de façon continue.
Essais et erreurs
- Bien sûr, tout n’a pas fonctionné dès le départ. À l’origine, nous voulions mener deux choses en parallèle
- introduire d’un coup des changements à forte valeur mais un peu anxiogènes : activer l’option strict, imposer des règles eslint sévères, supprimer tout le code mort d’un seul coup, etc.
- avancer d’un pas à la fois en toute sécurité, même si la valeur immédiate est moindre : laisser chaque jour un commit de tidying, etc.
- Mais la première approche inquiétait tellement qu’on ne la faisait pas, et la seconde paraissait tellement peu stimulante qu’on ne la faisait pas non plus.
- Nous avons donc changé d’approche
- rendre les choses ambitieuses plus sûres (activer
tsc strictfichier par fichier, corriger puis désactiver, appliquer eslint avec un minimum de règles, utiliser knip package par package, etc.) - rendre les choses sûres plus utiles (par exemple en créant un prompt qui propose du tidying sur les changements récents)
- rendre les choses ambitieuses plus sûres (activer
- Il reste encore beaucoup de défis
- activer
typescript: strict - introduire zod pour aligner les contrats serveur-client
- adopter des règles eslint plus strictes
- augmenter davantage la couverture des tests automatisés
- bloquer plus fermement les mauvaises directions grâce à des outils d’analyse statique plus variés
- activer
- Mais nous avançons ensemble, régulièrement, et sans jamais vraiment ralentir.
One More Thing : mes habitudes d’apprentissage + de débogage
Dans ce type de situation, on apprend énormément en interrogeant l’IA puis des experts, et en faisant une validation croisée. Ce processus est lui aussi documenté et partagé dans l’organisation via les PR et issues GitHub, ainsi que sur Slack.
- Quelqu’un d’autre sait ce que je ne sais pas
- Comment cette personne a-t-elle acquis ce savoir / cette expérience ? À quels signaux a-t-elle identifié ce problème ?
- Découvrir mes erreurs, des bugs, ou des anti-patterns dans la base de code
- Quelles causes rendaient l’apparition de ce problème inévitable ? Comment améliorer la structure pour faire moins d’erreurs la prochaine fois et les détecter plus tôt ?
Conclusion
- Si l’on permet à l’IA de produire de meilleures réponses, une grande partie des problèmes d’une équipe produit peut être résolue
- en améliorant la qualité de la base de code (partir dans la bonne direction dès le début) et en introduisant divers outils (bloquer les mauvaises directions)
- en aidant les membres de l’équipe à développer leurs compétences en agentic engineering (demander ce qu’ils font bien, aider sur ce qu’ils font mal)
- En collaborant intelligemment avec l’IA, si les compétences de l’équipe progressent et qu’un bon environnement est mis en place, alors « amélioration de la qualité » et « accélération de l’ajout/de l’amélioration de fonctionnalités » peuvent tout à fait avancer simultanément.
- Au lieu d’apporter de l’extérieur de « bonnes idées » pour aider, mieux vaut les découvrir et les tester ensemble de l’intérieur. Mesurons, rendons visible, célébrons, et apprenons les uns des autres.
Aucun commentaire pour le moment.