Apprendre à une IA à lire du code comme un développeur senior

• « Une expérience déroutante qui a changé ma façon de penser l’analyse de code par l’IA »
• L’auteur a constaté que les IA existantes échouaient souvent lorsqu’elles analysaient une base de code React
• Il a compris que la cause venait de leur manière d’analyser le code uniquement ligne par ligne, comme lorsqu’un développeur junior lit du code pour la première fois

La période bootcamp et la différence avec l’état d’esprit d’un senior

• Quand on est junior, on lit souvent les fichiers dans l’ordre, ligne par ligne, et on se perd rapidement
• Un développeur senior, lorsqu’il examine une grosse PR, procède plutôt ainsi
  • Il commence par vérifier les fichiers clés
  • Il regroupe les changements par fonctionnalité
  • Il comprend d’abord l’architecture globale, puis regarde les détails d’implémentation
• Il a décidé d’appliquer cette approche à l’IA

L’expérience

• Il a essayé une méthode consistant à regrouper les fichiers par fonctionnalité et à fournir d’abord à l’IA le contexte de chaque groupe
• Dans l’exemple de code, il définit l’interface FileGroup et traite les fichiers en les regroupant selon les fonctionnalités associées et la taille des fichiers
• Il construit des prompts par groupe pour indiquer à l’IA « de quel domaine fonctionnel il s’agit et ce qu’il faut examiner en priorité »

Le moment du changement spectaculaire

• Alors qu’auparavant l’IA répondait simplement « une logique d’authentification par jeton JWT est incluse »
• Elle s’est mise à formuler des observations de niveau développeur senior, comme « l’impact possible sur les connexions WebSocket » ou « un risque potentiel de race condition avec une PR fusionnée récemment »
• L’IA a commencé à signaler des points en prenant en compte le contexte de l’ensemble du système

Ce qui a réellement changé

• Le point essentiel n’était pas l’utilisation d’un modèle de machine learning plus complexe, mais le fait d’imposer à l’IA un ordre de raisonnement comparable à celui d’un développeur senior
  1. Le contexte d’abord : commencer par comprendre l’ensemble du système
  2. La reconnaissance de motifs : regrouper les fichiers similaires pour repérer une logique répétée
  3. L’analyse d’impact : percevoir l’effet des changements sur l’ensemble du système
  4. La compréhension de l’historique : remonter jusqu’aux raisons et au contexte des changements passés dans le code

Des effets secondaires inattendus

• Au lieu de simplement corriger les points visés, l’IA a aussi repéré des insights comme
  • l’identification de blocs de code dupliqués à cause du copier-coller
  • des alertes sur des schémas de gestion d’erreurs incohérents
  • la détection de possibles goulots d’étranglement en matière de performances
  • des suggestions d’amélioration de l’architecture en fonction des schémas d’usage

Pourquoi c’est important

• Les IDE récents fondés sur l’IA se concentrent sur la génération automatique de code
• Mais se limiter à de simples suggestions sans le contexte du système dans son ensemble peut être aussi risqué qu’« un développeur junior qui vient d’arriver »
• Ce qui compte vraiment, c’est une « compréhension approfondie du code »

Les questions qui restent

• Le problème consistant à décider quand mettre à jour le contexte (les informations historiques) et quand le conserver
• La manière de réagir lorsqu’on découvre des motifs contradictoires
• La façon de présenter à l’utilisateur des résultats d’analyse à forte incertitude

La direction à suivre

• L’auteur réfléchit désormais à la possibilité d’enseigner aussi à l’IA, comme à un développeur senior, des aptitudes telles que
  • la capacité à détecter la dette technique en amont
  • l’aptitude à proposer de manière proactive des améliorations d’architecture
  • la capacité à détecter des problèmes de sécurité à partir des schémas d’usage
  • le flair pour comprendre les règles informelles au sein d’une équipe
• L’objectif ultime n’est pas simplement de générer « plus de code », mais d’enseigner « comment comprendre en profondeur l’ensemble d’un codebase comme un développeur senior »

[savvykang]

Les questions à poser pour analyser et améliorer une base de code ne sont-elles pas déjà assez standardisées ? On dirait que l’auteur s’emballe un peu.

[yangeok]

On dirait que c’est dans la même logique que le fait d’expliquer l’ensemble du projet dans cursor ou notepad.

[GN⁺]

Avis Hacker News

• Les gens se montrent critiques dans les commentaires. L’article présente des résultats brefs et positifs sur le potentiel d’un nouvel outil, tout en incluant des réflexions honnêtes et raisonnables

  • Le récit « Senior vs Junior Developer » est peut-être un peu exagéré, mais le fond de l’article est excellent
  • Certains se demandent si les gens se mettent en colère parce qu’ils se sentent menacés

• Encore un exemple de choses étonnantes que les LLM peuvent accomplir. Cependant, construire un système qui fonctionne de manière cohérente et précise sur toutes les entrées est très difficile

  • Il y a un exemple d’analyse d’un fichier de système d’authentification
  • Cette chaîne codée en dur joue un rôle important, mais ce n’est pas vraiment remarquable tant que cela n’est pas généré avec précision et constance pour toutes les PR
  • Il faut mettre en place une évaluation sur différents codebases et des PR réelles

• Il y a probablement des leçons à en tirer pour de meilleurs systèmes d’agents dédiés à l’écriture de code

  • On demande à Claude/chatGPT, etc., de ne pas générer le code immédiatement, puis de l’écrire après avoir produit une structure initiale

• En lisant la première ligne de l’article, je me suis senti comme un extraterrestre. Il faudrait lire l’ensemble, mais l’idée de lire le code existant de manière séquentielle paraît étrange

  • Il existe beaucoup d’idées fausses sur ce qu’est un « développeur junior »

• Cela souligne l’importance du facteur humain. Sans compréhension contextuelle du codebase, on ne peut pas savoir ce que signifient les alertes de l’IA

  • Il est difficile de comprendre ce que sont les « patterns partagés » et pourquoi ils provoquent des conditions de concurrence
  • Le lien entre les modifications d’authentification et la PR de « logique de retry » n’est pas clair

• Il est difficile d’empêcher l’IA d’inventer des API qui n’existent pas. Quand ça marche bien, c’est très bien, mais la plupart du temps, ça ne marche pas bien

  • L’IA fonctionne bien surtout quand beaucoup de gens écrivent déjà le même type de code

• Le contexte et la compréhension du code sont essentiels pour améliorer la qualité du code généré par les LLM

  • Le produit de Bismuth découpe le projet en zones logiques selon la demande de l’utilisateur et explore le codebase en recherchant les informations sur les symboles
  • Seuls certains produits concurrents offrent un niveau de recherche comparable

• Comme dans la plainte de John McCarthy, il s’agit d’un récit, pas d’une expérience ni d’une preuve

  • Certains espèrent que la communauté fera preuve d’esprit critique et de rigueur

• Les résultats sont impressionnants. Il y a des critiques sur le style et l’uniformité, mais le résultat semble utile

  • En voyant le titre, je pensais qu’il serait question d’une IA ignorant le travail des autres pour ne mettre en avant que le sien

• Il semble manquer dans l’article une partie importante de la technique. L’implémentation de getFileContext() et shouldStartNewGroup() n’est pas montrée