Apprivoiser le génie : « comme Kent Beck »

• Une expérience a vérifié si l’ajout d’un prompt de persona « code comme Kent Beck » à un outil de coding IA (Genie) améliorait la qualité du code. Résultat : le style des tests et le nommage des variables se sont améliorés, mais la conception architecturale n’a pas changé
• Un projet d’implémentation de la structure de données Rope a servi à comparer et valider les effets d’un prompt de persona et de contraintes de conception
• La persona améliore les micro-comportements (méthode de test, nommage), tandis que les contraintes explicites déterminent la macro-architecture (hiérarchie de classes)
• Dans une expérience à 4 groupes, le prompt combinant persona et contraintes a produit les meilleurs résultats
• En citant « The Bitter Lesson » de Rich Sutton, l’article suggère qu’il est plus efficace d’exploiter les ressources de calcul que d’encoder l’expertise humaine

---

Le stade actuel des outils de coding IA

• Les outils de coding IA actuels (Genie) en sont au stade de la « calèche sans chevaux »
• Toute innovation technologique est d’abord comprise dans le cadre existant, avant que son changement fondamental ne soit reconnu
  • calèche sans chevaux → automobile
  • télégraphe sans fil → radio
  • courrier électronique → messagerie
• Pour comprendre les effets de second ordre d’une nouvelle technologie, ainsi que ses boucles de renforcement et d’inhibition, il faut l’utiliser assez longtemps

Expérience : la structure de données Rope

• La structure de données Rope sert à supprimer efficacement un caractère au milieu de très longues chaînes
• L’approche simple consiste à décaler tous les caractères à droite, ce qui prend O(n)
• La structure Rope utilise des objets substring et concatenation pour effectuer la suppression en temps constant
  • 3 objets sont alloués lors d’une suppression
  • La recherche est en O(nombre d’opérations), mais reste inférieure à la longueur de la chaîne et une compression périodique est possible

Déroulement de l’expérience

Phase 1 : persona (« Code like Kent Beck »)

• Vérification de l’effet du prompt « Code like Kent Beck » sur l’amélioration de la qualité du code
• Résultat : amélioration confirmée du style de code
  • amélioration des noms de variables
  • la stratégie de test est passée d’un script monolithique à des tests unitaires modulaires (approche TDD)
• Découverte inattendue : l’architecture n’a pas changé
  • Rope a été implémentée comme un arbre binaire standard
  • le pattern Composite utilisé par Kent Beck a été ignoré

Phase 2 : ajout d’un guide de conception

• Le code du groupe Control était si verbeux qu’il a provoqué une erreur de syntaxe à cause d’un dépassement de la limite de tokens
  • résolu en augmentant la limite de tokens
  • plus de calcul peut être une solution simple
• Ajout de contraintes explicites dans le prompt
  • « utiliser le pattern Composite »
  • « séparer les comportements en petites classes spécialisées »
• Résultat : la conception attendue a été implémentée
  • classes séparées pour Substring et Concatenation
  • structure plus simple qu’une classe unique
  • en pratique, une conception encore plus simple a émergé : traitement par Substring 0..size sans Null Object (EmptyString) ni wrapper de chaîne natif

Phase 3 : expérience séparée en 4 groupes

• Une expérience croisée a été conçue pour identifier l’effet précis de chaque intervention
  1. Control : assistant standard
  2. Kent Beck : persona uniquement
  3. Composite : contrainte architecturale uniquement
  4. Combined : persona + contraintes

Conclusions de l’expérience

• Confirmation d’un effet de matrice 2x2
  1. La persona détermine les micro-comportements : le prompt « Kent Beck » améliore de manière stable le style de test et le naming, mais n’influence pas les décisions structurelles
  2. Les contraintes déterminent la macro-architecture : le prompt « Composite Pattern » impose la hiérarchie de classes et produit une conception plus fine même sans persona
  3. La combinaison est la meilleure option : le groupe Combined a fourni à la fois la bonne architecture (Composite) et les bonnes habitudes de développement (TDD/tests unitaires)

Application de The Bitter Lesson

• Objectif caché : faire en sorte que Genie développe mieux tout en équilibrant le présent et l’avenir
• Méthodes essayées : prompting minutieux, relecture attentive des changements proposés par Genie, étapes plus petites ou plus grandes, etc.
• Citation de « The Bitter Lesson » de Rich Sutton
  • La leçon tirée de 70 ans de recherche en IA : mieux vaut exploiter les ressources de calcul que tenter d’encoder l’expertise humaine
  • Le fait d’avoir essayé d’encoder un style était la même erreur que tout le monde commet

Proposition d’un style de développement efficace fondé sur l’exploitation du calcul

• Il n’est pas nécessaire de rester prisonnier d’un génie du code maladroit qui copie le mauvais style de code d’innombrables dépôts
• Proposition d’une méthode fondée sur le calcul
  1. choisir un dépôt de grande taille
  2. faire implémenter la fonctionnalité suivante par un million de génies, chacun choisissant une méthode et un niveau de refactorisation différents
  3. sélectionner le génie qui réussit à ajouter la fonctionnalité au coût le plus bas (temps, tokens, électricité, coût, etc.)
  4. répéter sur de nombreux génies, de nombreuses fonctionnalités et de nombreux dépôts
• Cela peut sembler être du « gaspillage » de coding, mais ce n’est pas réellement le cas
• Jessica Kerr appelle cela un « Design Contest »