Le jour où j'ai appris à l'IA à comprendre le code comme un développeur senior, par NamanyayEst-ce juste moi, ou les LLMs de génération de code que nous utilisons tous ne sont pas si bons que ça ?
Pendant des mois, j'ai regardé les développeurs faire l'éloge des LLM tout en nettoyant silencieusement leurs dégâts, effrayés d'admettre à quel point ils ont besoin d'un baby-sitting.
J'ai réalisé que les LLM ne comprenaient pas vraiment les bases de code - ce ne sont que des outils d'autocomplétion sophistiqués (avec un bon marketing).
Après deux ans de frustration à voir mes assistants IA constamment « oublier » où se trouvaient les fichiers, créer des doublons et utiliser des modèles complètement incorrects, j'ai finalement construit ce que les grandes entreprises d'IA ne pouvaient pas - ou ne voulaient pas - faire.
J'ai décidé d'en avoir le cœur net : Et si je pouvais faire en sorte que l'IA comprenne réellement le fonctionnement de ma base de code ?
L'illusion de la compréhension
En décembre dernier, j'ai atteint mon point de rupture. Mon IA prétendument « intelligente » continuait à générer des composants qui ne suivaient pas nos modèles établis. Lorsque je lui en ai fait la remarque, elle s'est excusée, puis a refait exactement la même erreur dix minutes plus tard.
Il ne s'agissait pas d'un cas isolé. C'était la norme.
Le problème est apparu clairement : ces outils d'IA n'ont aucune compréhension réelle des bases de code en tant que systèmes interconnectés. Ils fonctionnent sur de petites fenêtres contextuelles et échouent de manière spectaculaire à maintenir un modèle mental du projet.
Ce qui est particulièrement frustrant, c'est que le marketing des grandes entreprises d'IA laisse entendre que leurs outils « comprennent » votre code. Ce n'est pas le cas. Ils font des suppositions éclairées - et la différence devient douloureusement évidente sur n'importe quel projet modérément complexe.
L'état d'esprit des juniors et des seniors
En réfléchissant à ce problème, je suis revenu aux principes de base et j'ai essayé d'analyser la façon dont les développeurs seniors envisagent une base de code :
- Les développeurs juniors se concentrent sur le « quoi » et le « comment » - ils s'intéressent aux détails de l'implémentation pour résoudre des problèmes immédiats. Ils peuvent écrire un code qui fonctionne, mais ils passent souvent à côté de la situation dans son ensemble.
- Les développeurs seniors se concentrent sur le « pourquoi » et le « si » - ils maintiennent un modèle mental de l'ensemble du système, comprennent comment les composants interagissent et anticipent les effets d'entraînement des changements. Ils font la distinction entre le code accessoire et le code fondamental.
Je me suis rendu compte que les LLM fonctionnent souvent comme des développeurs juniors, et non comme des développeurs seniors :
- Ils se perdent dans de grandes bases de code parce qu'ils n'ont pas une compréhension de haut niveau.
- Ils écrivent des fonctionnalités en double plutôt que de reconnaître les possibilités de réutilisation.
- Ils fonctionnent par essais et erreurs, s'empressant d'écrire du code sans en comprendre tout le contexte.
- Ils suivent des modèles de manière incohérente, sans en saisir l'objectif sous-jacent.
Mon objectif est devenu clair : pouvais-je faire en sorte que l'IA pense davantage comme des développeurs seniors en l'aidant à améliorer son modèle de la base de code ?
Une percée
La solution m'est apparue lors d'une session de codage à 2 heures du matin, alors que je m'occupais d'un énième fichier généré de manière incorrecte : et si nous traitions la base de code comme un graphe de connaissances hiérarchique plutôt que comme des fichiers plats ?
Les développeurs humains ne mémorisent pas des bases de code entières. Nous construisons des modèles mentaux sur la manière dont les composants sont liés les uns aux autres. Nous comprenons qu'une partie du code est du réchauffé, tandis que d'autres sections constituent une logique d'entreprise essentielle. Nous voyons naturellement le code à travers différentes « lentilles » en fonction de ce que nous essayons d'accomplir.
J'ai développé ce que j'appelle la « Ranked Recursive Summarization » (RRS), un algorithme qui part des feuilles de l'arbre des répertoires d'un projet et construit de manière récursive une compréhension ascendante en utilisant des LLM :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | # pseudocode:
def ranked_recursive_summarization(folder):
if is_file(folder):
chunks = split_into_chunks(read_file(folder))
ranked_chunks = rank_by_importance(chunks)
return summarize(ranked_chunks)
summaries = []
for child in folder.children:
summary = RRS(child)
summaries.append(summary)
return summarize(summaries) |
Cela a fonctionné étonnamment bien, mais je me suis vite rendu compte que ce n'était pas suffisant. En fonction de ce sur quoi j'essayais de travailler, RRS manquait certains détails. S'il disposait d'informations sur l'architecture et les modèles de données, il omettait les composants frontaux. S'il était trop axé sur l'interface utilisateur, il ne décrivait pas le flux de données.
J'ai dû réfléchir plus en profondeur : qu'est-ce qui fait qu'une certaine partie du code est importante ?
Une compréhension plus fine
Ma deuxième intuition m'a permis de mettre au point une technique véritablement transformatrice : La « Prismatic Ranked Recursive Summarization » (PRRS).
Au lieu d'avoir une définition globale de l'« importance », la PRRS analyse le code à travers plusieurs lentilles conceptuelles :
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 | # pseudocode:
def prismatic_rrs(folder, lenses=['architecture', 'data_flow', 'security']):
summaries = {}
for lens in lenses:
context = f"Analyze importance from {lens} perspective"
summaries[lens] = RRS(folder, context=context)
return summaries |
Les résultats sont indéniables. L'IA a soudain compris :
- l'emplacement logique des fichiers
- les modèles à suivre
- comment étendre les abstractions existantes au lieu d'en créer de nouvelles
- quand réutiliser le code plutôt que de créer de nouvelles implémentations.
Honnêtement, l'approche n'est pas particulièrement complexe ou gourmande en ressources informatiques. Les grandes entreprises d'IA auraient pu mettre en œuvre quelque chose de ce type dès le début. Mais elles ne l'ont pas fait, parce que cela ne correspond pas à leurs motivations d'obtenir des résultats pour les coûts symboliques les plus bas.
En quoi cela est-il important ?
Les implications vont bien au-delà de la correction des erreurs de base. Lorsque l'IA comprend vraiment votre base de code :
- La dette technique devient visible à travers le prisme de l'« architecture ».
- Les vulnérabilités en matière de sécurité apparaissent naturellement à travers la lentille « sécurité ».
- Les développeurs débutants peuvent naviguer dans des projets complexes avec une vision de haut niveau.
- Le temps d'intégration des nouveaux membres de l'équipe diminue considérablement.
Il y a aussi un côté plus sombre. À mesure que l'IA s'améliore pour comprendre les bases de code, la valeur de certains types de connaissances en programmation diminue : le programmeur de niveau intermédiaire qui traduit principalement les exigences en code sans avoir de vision architecturale peut se retrouver de plus en plus à l'étroit.
Après avoir expérimenté ces techniques pendant plusieurs semaines, j'ai fini par les intégrer dans un outil appelé Giga AI. Je l'ai créé au départ pour résoudre mes propres frustrations, mais d'autres développeurs m'ont demandé de l'essayer après avoir vu comment il modifiait mon flux de travail. Les développeurs qui utilisent Giga déclarent passer moins de temps à corriger le code généré par l'IA, être en mesure de livrer plus rapidement et se sentir moins frustrés.
Mise en œuvre
Même sans mon outil spécifique, vous pouvez améliorer la compréhension du code de votre assistant IA :
- Créez des résumés manuels de vos répertoires et fichiers les plus importants.
- Demandez à l'IA d'améliorer votre documentation manuelle
- Créez et assurez plusieurs fichiers de documentation, chacun à partir d'une « lentille » différente, en fonction de votre projet.
- Inclure les fichiers pertinents dans le contexte de l'IA en fonction des besoins.
Ces approches ne seront pas aussi transparentes qu'une solution spécifique, mais elles amélioreront considérablement vos résultats par rapport à l'expérience par défaut.
Le contexte est l'avenir
Je pense que nous sommes au début d'un changement fondamental dans la façon dont l'IA comprend les systèmes complexes tels que les bases de code. La prochaine génération d'outils ne se contentera pas de créer des intégrations de votre code, elle construira des modèles mentaux riches à partir de perspectives multiples, tout comme le font les développeurs expérimentés.
Les entreprises qui adopteront cette approche devanceront celles qui se concentrent encore sur la seule prédiction des jetons. Et les développeurs qui apprendront à exploiter ces outils sophistiqués bénéficieront d'avantages durables que la simple « ingénierie de la demande » ne pourra pas égaler.
L'avenir appartient à ceux qui considèrent l'IA non pas comme un substitut aux développeurs humains, mais comme un multiplicateur de force pour l'ingéniosité humaine.
Et cet avenir commence maintenant.
Source : The day I taught AI to understand code like a Senior Developer
Et vous ?
Pensez-vous que cette affirmation est crédible ou pertinente ? Quel est votre avis sur le sujet ?Voir aussi :
Mon flux de travail avec Cursor AI qui fonctionne réellement, par Namanyay L'IA est en train de créer une génération de programmeurs illettrés, par Namanyay
Vous avez lu gratuitement 7 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.