À mesure que l’AI écrit davantage de code, pourquoi devons-nous encore le comprendre ?

J’ai utilisé l’AI pour créer un produit qui aide les gens à comprendre le code.

Mais quelque chose d’intéressant s’est produit : plus le produit devenait complexe, moins je le comprenais moi-même.

J’ai commencé à développer FiboCode vers juillet 2025. Le Vibe Coding prenait son essor et tout le monde parlait d’utiliser l’AI pour aider à écrire du code et réduire le coût du développement logiciel. Une idée m’est venue naturellement :

Si l’AI peut aider les gens à écrire du code, pourrait-elle aussi les aider à le comprendre ?

Le coût de l’écriture du code continue de baisser, mais comprendre un projet inconnu reste pénible. C’est particulièrement vrai face à une base de code vieille de plusieurs années, avec une arborescence complexe, des dépendances entre modules, des décisions de conception historiques et toutes sortes de conventions. Souvent, déterminer par où commencer prend déjà beaucoup de temps.

FiboCode est né de cette idée simple : utiliser l’AI pour analyser le code et générer les documents et diagrammes de relations correspondants, puis permettre de naviguer entre le code, les documents et les diagrammes.

À ce stade, ce n’était qu’un outil d’analyse de code.

Plus tard, j’ai ajouté un Agent simple pour faciliter les questions sur le code. Pour améliorer la lecture, j’ai intégré Monaco Editor. Avec un éditeur, la navigation, les références de symboles et les diagnostics de langage semblaient aussi nécessaires ; j’ai donc ajouté la prise en charge de LSP.

Une fois la lecture prise en charge, l’édition était l’étape naturelle suivante.

Lorsque FiboCode a pu modifier le code, j’ai cherché comment aider l’Agent à comprendre réellement un projet plutôt qu’à le juger d’après les quelques fichiers ouverts. J’ai progressivement ajouté MCP et Skills afin de donner aussi à l’AI accès aux conventions de conception, au contexte architectural et à l’historique du projet.

J’ai ensuite compris que de nombreux développeurs étaient déjà à l’aise avec des Agent CLI comme Claude et Codex. Ils n’avaient peut-être pas besoin d’un autre Agent intégré, mais plutôt d’une interface conçue pour examiner les résultats du travail d’un Agent.

FiboCode a donc ajouté un terminal et des améliorations propres aux sorties Agent CLI, permettant de relier les références de fichiers, les changements de code et les étapes d’exécution du terminal au code, aux documents et aux diagrammes de relations.

Ainsi, un simple module d’analyse de code est devenu, pièce après pièce, un système toujours plus complexe.

J’ai commencé à oublier le projet que j’avais construit

La programmation assistée par l’AI est vraiment pratique.

Même si les premiers modèles étaient moins performants qu’aujourd’hui, j’examinais soigneusement le code généré, souvent plusieurs fois. Je regardais la séparation des modules, la circulation des données et les raisons des choix architecturaux.

Le projet a connu de nombreuses refactorisations, parfois importantes. Mais comme je connaissais alors les détails de conception, aucune n’a finalement cassé le projet.

Puis les modèles sont devenus plus capables, la génération plus rapide et la base de code s’est mise à croître rapidement.

J’ai peu à peu remarqué que je ne me souvenais déjà plus des détails de conception d’un code relu une ou deux semaines auparavant.

Au début, cela m’a un peu effrayé.

C’était mon propre projet. Chaque fonctionnalité venait de moi, et pourtant je ne savais plus pourquoi chaque module avait été conçu ainsi ni comment chaque logique fonctionnait.

Avec le temps, j’ai compris que c’était peut-être simplement quelque chose à accepter.

Ce n’était plus le petit projet du début. Dans un système suffisamment complexe, personne ne peut retenir chaque détail d’implémentation. L’essentiel n’est peut-être pas de garder chaque ligne en tête, mais de savoir où se trouve le cœur du système, comment les modules collaborent, quelles parties peuvent être confiées à l’AI et lesquelles doivent être comprises attentivement.

Je devais apprendre à choisir.

Il me fallait repérer les chemins critiques dans la masse de code, construire une vue mentale globale du système, puis donner à l’AI des exigences et des contraintes plus précises.

Sous cet angle, FiboCode m’aidait aussi à construire FiboCode.

J’utilisais l’AI pour développer le produit ; le produit devenait plus utile et m’aidait en retour à le comprendre et à l’améliorer plus vite. Cette boucle positive était réellement exaltante et expliquait en grande partie pourquoi je continuais depuis si longtemps.

Mais au-delà de cet enthousiasme, je me demandais souvent :

Que me restait-il dans ce processus de développement ?

Quand j’ai confié une part croissante de ma réflexion à l’AI

Sur une longue période, j’ai peu à peu pris une habitude.

À chaque exigence, je la donnais d’abord à l’AI.

À chaque problème, je demandais d’abord à l’AI d’enquêter.

Après sa proposition, je vérifiais. Si la vérification échouait, je lui renvoyais le résultat et demandais une nouvelle analyse et une correction.

Il m’arrivait de passer une journée entière à décrire des exigences, expliquer l’état d’un bug et renvoyer les résultats des tests.

L’AI semblait accomplir presque tout le travail intellectuel difficile, tandis que mon rôle se réduisait à définir les exigences et transmettre les résultats.

Pendant cette période, j’ai réellement ressenti ceci :

J’avais l’impression de ne plus avoir beaucoup de valeur.

Mais en continuant, j’ai découvert que ce n’était pas tout à fait vrai.

En développant avec l’AI, j’ai rencontré de nombreuses technologies que je n’aurais pas choisi d’étudier auparavant et observé une grande variété d’approches. J’ai commencé à examiner volontairement la conception et l’architecture avant l’implémentation concrète.

Pour certaines tâches, je voyais vite que le périmètre était petit et que l’AI pouvait les terminer directement.

Mais lorsqu’une tâche traversait plusieurs modules ou touchait la structure centrale du projet, je savais immédiatement qu’elle n’était pas simple. L’AI pouvait ne voir que l’exigence actuelle sans comprendre l’origine d’une conception historique ni les effets indirects du changement.

Il existait aussi du code que je devais comprendre presque entièrement, même si l’AI pouvait l’écrire, car une erreur à cet endroit aurait des conséquences difficiles à contrôler.

J’ai cessé de vouloir comprendre chaque détail, mais je suis devenu plus sensible aux limites, dépendances, risques et changements du système.

Le travail humain n’a peut-être pas disparu ; il change simplement.

Autrefois, nous comprenions un système en implémentant nous-mêmes son code.

À l’avenir, nous consacrerons peut-être moins d’efforts à l’implémentation répétitive et davantage à l’architecture, aux processus, aux contraintes, à la vérification et à l’évolution à long terme.

Ce n’est pas parce que l’AI peut l’écrire que nous pouvons lui faire confiance

Je ne sais pas si l’AI pourra réellement remplacer les experts humains et accomplir tout le travail de programmation.

C’est bien sûr une question technique, mais je crois que c’est aussi une question de confiance.

Même si l’AI peut un jour générer seule un système très complexe, cela ne signifie pas que nous lui ferons confiance sans réserve.

Quand le système se comportera de façon inattendue, saurons-nous pourquoi ?

Pourrons-nous localiser l’erreur ?

Pourrons-nous vérifier la correction ?

Quelqu’un d’autre pourra-t-il reprendre le système ?

S’il cause un préjudice grave, qui sera responsable ?

Ces questions ne se résolvent pas entièrement en faisant passer la précision d’un modèle de 99 % à 99,9 %.

Pour des applications peu risquées et faciles à remplacer, nous pouvons tolérer davantage de boîte noire. Si la fonction marche et que le développement est assez rapide, chaque détail n’a peut-être pas d’importance.

Mais pour des logiciels fondamentaux comme les systèmes d’exploitation et les bases de données, ou pour la finance, l’électricité et d’autres domaines à fort impact social, il est difficile d’accepter une boîte noire impossible à comprendre, auditer ou reprendre.

Ces systèmes ont toujours besoin de personnes pour les maintenir.

Elles n’ont pas nécessairement à écrire chaque ligne, mais quelqu’un doit savoir en gros comment fonctionne le système, où se trouvent les risques critiques et par où commencer quand un problème survient.

C’est pourquoi je crois de plus en plus que la compréhension du code ne disparaîtra pas avec la programmation par AI.

Elle prendra simplement une autre forme.

Autrefois, nous devions comprendre le code pour l’écrire.

À l’avenir, nous devrons peut-être le comprendre pour vérifier, maintenir, reprendre et continuer à faire évoluer les systèmes créés par l’AI.

Les tâches de débutant qui disparaissent

La compréhension du code possède une autre importance.

L’AI réduit certains postes débutants centrés sur l’implémentation répétitive et les tâches élémentaires. Même lorsque les postes subsistent, une grande partie du travail autrefois confié aux nouveaux venus est d’abord automatisée par l’AI.

Ce n’est pas favorable aux débutants.

Le parcours traditionnel d’un ingénieur commence par des tâches simples : corriger un bug, lire une petite portion de code, terminer une petite fonctionnalité, puis participer progressivement à des modules et à une conception plus complexes.

Les nouveaux venus construisent peu à peu leur compréhension des projets réels grâce à ces tâches apparemment peu importantes.

Mais l’AI peut désormais accomplir directement ces tâches fondamentales.

S’il reste moins de portes d’entrée pour former les débutants, d’où viendront les ingénieurs expérimentés de demain ?

C’est une autre raison pour laquelle j’ai créé FiboCode.

Je suis moi aussi nouveau dans la profession. La première fois que j’ai affronté une base de code ancienne et complexe, je me suis souvent senti complètement perdu.

Il y avait tant de fichiers et de dossiers. Les services s’appelaient mutuellement, tandis que types, interfaces et configurations étaient dispersés. On savait que la réponse se trouvait quelque part dans le code, mais pas où commencer, ce qui comptait ni ce qui n’était qu’un détail.

La vraie difficulté n’était souvent pas de comprendre une ligne, mais l’absence d’une carte complète.

J’ai toujours voulu un outil qui analyse d’abord la structure de tout un projet et indique ses modules essentiels, leurs connexions et les zones qu’un changement pourrait affecter.

Ainsi, les nouveaux venus ne dépendraient pas entièrement d’une personne les guidant pas à pas et n’auraient pas à progresser sans cesse à tâtons dans des bases inconnues.

Un tel outil ne remplace pas la croissance, mais il abaisse la barrière d’entrée dans un système complexe.

Alors que l’AI coupe progressivement l’ancien chemin d’apprentissage, j’espère que FiboCode pourra reconnecter une voie.

Pas nécessairement un raccourci qui évite tous les fondamentaux, mais plutôt une carte, un système de navigation et un chemin aidant les débutants à construire plus vite une représentation mentale du système.

Le code ne consigne que le présent

Pendant le développement, j’ai découvert un autre problème.

Donner directement une tâche à l’AI et la laisser explorer seule le dépôt peut parfois conduire à une réflexion incomplète.

L’AI voit le code actuel, mais peut ignorer pourquoi un module a été conçu d’une certaine manière ou qu’il est indirectement lié à des fichiers apparemment sans rapport.

Le code peut généralement montrer l’état actuel d’un système, mais explique difficilement pourquoi il est devenu ainsi.

Au début, j’ai envisagé de mettre toutes ces informations dans les commentaires du code.

J’ai ensuite décidé que ce n’était pas adapté.

De grandes quantités de contexte de conception, de raisonnement historique et d’explications gonfleraient les fichiers et fourniraient à l’AI beaucoup de contexte sans rapport avec sa tâche. Les commentaires conviennent à la logique locale, mais portent mal toute l’évolution d’un projet.

J’ai donc conçu une série de Fibo Skills.

Elles consignent les conventions, conceptions, processus d’implémentation et explications des diff, laissant une trace plus complète de chaque changement.

J’espère que lorsque l’AI modifiera du code, elle verra non seulement l’état actuel, mais comprendra aussi ce qui s’est passé et pourquoi certaines conceptions ont été conservées.

Quand l’évolution d’un projet devient traçable, l’AI peut le comprendre plus complètement.

C’est également devenu l’une des directions de FiboCode :

Il était initialement destiné à aider les humains à comprendre le code. Plus tard, il a aussi commencé à aider l’AI à mieux le comprendre.

Comment FiboCode est devenu ce qu’il est

Avec le recul, FiboCode n’a pas été conçu dès le départ pour être ce qu’il est aujourd’hui.

Il a commencé comme un simple module d’analyse. Sont ensuite venus les documents et diagrammes de relations, un Agent, un éditeur et les services de langage. Peu à peu, il a aussi reçu l’édition de code, un terminal, MCP et Skills.

Je voulais offrir aux Agent CLI une expérience de revue semblable à Cursor, tout en transformant les documents et relations issus de l’analyse en contexte réellement utilisable par l’AI.

Il a évolué d’un module simple vers un système complexe, et cette croissance continue faisait discrètement écho au développement de la suite de Fibonacci.

C’est aussi l’origine du nom FiboCode et de l’image de l’escargot.

La coquille de l’escargot porte la beauté mathématique de la spirale d’or.

Il n’avance pas très vite, mais continue de grandir vers l’avant.

FiboCode ne cherche ni à faire réécrire chaque ligne à la main, ni à exclure l’AI.

Bien au contraire. Il accepte que l’AI écrira toujours plus de code et espère, sur cette base, aider les gens à continuer de comprendre, vérifier, maintenir et reprendre leurs propres systèmes.

À une époque où chacun poursuit une génération plus rapide, j’espère encore que nous pourrons parfois ralentir.

Pour comprendre pourquoi le code s’exécute ainsi et pourquoi un système est devenu ce qu’il est aujourd’hui.

Et pour redécouvrir la joie qui nous a d’abord attirés vers la programmation.