Après avoir codé pendant des mois avec des LLM, j’ai décidé de recommencer à utiliser mon cerveau
(albertofortin.com)- En s’appuyant sur des LLM très performants pour bâtir une infrastructure, de gros problèmes sont apparus en matière de qualité du code et de maintenabilité
- À cause de l’inefficacité de l’IA et de résultats incohérents, l’auteur a ressenti le besoin de mieux comprendre lui-même le code, d’enquêter et de renforcer ses compétences
- La volonté de terminer le projet rapidement a au contraire entraîné du désordre dans la structure du code, des doublons et des incohérences
- Désormais, l’IA n’est utilisée que de façon limitée comme outil d’appoint, par exemple pour des tâches répétitives ou de transformation de code
- Comme l’usage de l’IA peut entraîner une baisse des réflexes de programmation et des capacités de résolution de problèmes, l’auteur choisit de remettre l’usage actif de son propre cerveau au premier plan
Introduction : tentative de construction d’une infrastructure avec des LLM
- L’infrastructure existante en PHP+MySQL avait atteint ses limites, d’où la nécessité d’une nouvelle infrastructure
- Choix de Go et Clickhouse, puis conception et planification de l’infrastructure avec l’aide de l’IA
- Des questions ont été posées à des LLM comme Claude sur les best practices et l’architecture, afin d’établir un plan détaillé
- Le développement du code a été mené en privilégiant la vitesse, avec pour objectif de terminer les fonctionnalités et de publier rapidement
Déroulement du développement et apparition des problèmes
- À l’aide d’outils comme Cursor, l’IA écrivait le code tandis que l’auteur se concentrait surtout sur les builds et les tests
- Même si la base de code restait peu structurée, la priorité allait d’abord à la fourniture des données demandées
- Malgré la rapidité du développement, de nouveaux problèmes continuaient d’apparaître avec le temps
- Le manque d’expérience en Go et en Clickhouse a compliqué la tâche, et les correctifs proposés par l’IA ont provoqué des problèmes en chaîne
Problèmes de qualité du code et prise de conscience des limites
- Du temps a été consacré à une code review approfondie de l’ensemble du code produit
- Des fichiers remplissant la même fonction présentaient de nombreuses incohérences et redondances dans les noms, les paramètres, la structure, etc.
- Exemple :
WebAPIprovideretwebApidésignent les mêmes paramètres, mais existent séparément - Le même procédé était redéfini dans plusieurs fichiers
- L’accès aux fichiers de configuration manquait de cohérence
- Exemple :
- Au final, le résultat donnait l’impression que plusieurs développeurs juniors avaient travaillé en parallèle sans communiquer
Limites du feedback contextuel des LLM et changement de stratégie
- Même en fournissant suffisamment d’informations de contexte et en utilisant des LLM à grande fenêtre contextuelle comme Gemini, les améliorations restaient insuffisamment cohérentes
- L’auteur a pris conscience de la nécessité d’un apprentissage autonome de l’infrastructure et du langage, ainsi que d’un travail complémentaire sur la documentation et les vidéos
- Pour écrire un code propre et mieux organisé, il a abandonné le développement piloté par l’IA au profit d’une conception du code plus autonome
Évolution de la manière d’utiliser l’IA comme assistant
- En se concentrant sur le refactoring répétitif et la remise en ordre du code, l’auteur a recentré son travail sur la compréhension et la gestion directes du code
- Le rôle de l’IA a été limité à des tâches répétitives simples, comme les modifications automatiques de code, les changements massifs de paramètres ou la transformation de code
- Pour la conception de nouvelles fonctionnalités ou la rédaction d’une première ébauche de code, l’auteur réfléchit d’abord lui-même, puis utilise le LLM pour validation ou assistance
- L’IA est reléguée au rôle d’« assistant », tandis que les décisions de planification et de structure restent du ressort du développeur
Inquiétudes sur la baisse des capacités de réflexion et changement d’attitude
- Avec l’IA à disposition, l’auteur a constaté une diminution de la fréquence d’utilisation de son cerveau, ainsi qu’une tendance à déléguer à l’IA la planification et le raisonnement
- Il cherche à retrouver ses compétences de développeur et sa capacité de résolution de problèmes à travers le papier et le stylo, la conception directe et le codage manuel
- Il alerte sur le risque d’une dégradation des réflexes de programmation causée par l’IA
Inquiétudes pour les non-développeurs et le « Vibe Coding »
- Lorsque des non-développeurs développent uniquement avec des LLM, les phénomènes de code complexe, confus et de répétition d’erreurs deviennent encore plus graves
- Par rapport aux outils no-code, le développement fondé sur l’IA peut rendre la compréhension de la structure encore plus difficile
- Il est question d’un mur de code impossible à appréhender, ainsi que d’un cycle continu erreur-correction-récidive, révélant une difficulté fondamentale et des risques réels
Réflexions sur la réalité de l’usage de l’IA et l’ambiance dans la communauté
- L’auteur exprime sa confusion face à la commercialisation de l’IA, aux benchmarks, aux influenceurs, au battage médiatique des entreprises d’IA et au décalage avec les performances réelles
- Il souligne le manque de cohérence qui fait qu’un même modèle avec le même prompt peut produire des résultats totalement différents
- Même les LLM récents les plus performants ne parviennent pas encore à gérer parfaitement des tâches complexes du monde réel, comme des requêtes Clickhouse sur des centaines de millions de lignes
- Lorsqu’ils imposent des configurations complexes et des workflows inefficaces, cela peut en soi devenir une perte de temps
- L’IA peut sembler impressionnante, mais pour l’instant elle reste, selon lui, un bon outil sans être un outil exceptionnel, d’où une approche prudente
Conclusion
- L’auteur conserve de fortes attentes et un grand intérêt pour les nouvelles technologies et l’IA
- Mais à ce stade, la stratégie la plus avisée consiste à bien comprendre le rôle approprié et les limites de l’IA, et à l’utiliser de manière limitée comme outil d’assistance ou d’apprentissage
- Il revient à une démarche centrée sur sa propre réflexion et sa propre planification, tout en avertissant contre la dégradation des compétences des développeurs liée à l’usage de l’IA
- Un développement reposant entièrement sur l’IA sans comprendre le fonctionnement et la structure du code a de fortes chances d’aboutir à un échec
2 commentaires
Avis Hacker News
Je ne comprends pas vraiment l’état d’esprit du « tout miser » sur les LLM. Je travaille comme développeur iOS et, globalement, je bosse comme d’habitude. Maintenant, j’utilise les LLM surtout pour créer rapidement des vues temporaires basées sur un design. Pas le cœur de l’app, mais des écrans annexes comme une nouvelle fonctionnalité ou un guide d’installation de widget. Avant, ça me prenait 30 à 60 minutes selon la complexité ; maintenant, c’est réglé en 5 minutes. Je n’aime pas le développement web, et les LLM sont assez utiles sur ce point. Pour les gros changements aussi, j’utilise un LLM puis je vérifie moi-même avant de commit sur git. Mais si on fait confiance au LLM sans garder la main sur le flux, on peut se retrouver à perdre des heures puis à tout recommencer depuis zéro. Je pense qu’une approche équilibrée est essentielle
L’utilité d’un outil dépend de la personne et du problème. Par exemple, si un développeur Python avec 10 ans d’expérience travaille sur un énorme legacy code avec un IDE parfaitement adapté, sur des tâches axées stabilité, des outils comme les LLM ou Cursor peuvent au contraire être une gêne. En revanche, pour un développeur JS en première année d’expérience, qui prototype souvent de nouvelles idées, n’a pas de préférence forte pour son IDE et reste ouvert à l’expérimentation, les LLM et Cursor peuvent améliorer ses capacités de façon immédiate et importante
Je travaille aussi dans plusieurs domaines, comme iOS et le développement web, et les résultats des LLM diffèrent énormément entre les deux. Il arrive souvent que le code généré par le LLM ne compile même pas correctement. Il m’a même déjà indiqué des API qui n’existent pas. En revanche, il construit des apps Nextjs du premier coup. Au final, c’est une conséquence des différences dans les données d’entraînement des LLM
Il est naturel de surestimer les capacités des LLM. Moi aussi, je les ai longtemps utilisés surtout pour remplacer Stack Overflow et obtenir de petits snippets de code. Puis on leur confie progressivement plus de responsabilités, on rencontre des problèmes, on découvre leurs limites, et on recommence à les utiliser surtout pour les idées et les conseils. Je pense que beaucoup de gens passent par ce même cheminement
Je ressens la même chose. Je n’adhère pas du tout à l’idée de s’en remettre entièrement aux LLM, et je les utilise seulement pour les tâches répétitives et ennuyeuses, comme de petites fonctions, l’implémentation d’interfaces ou l’automatisation de la documentation. Ça m’a fait gagner beaucoup de temps et a amélioré mon efficacité au travail
En développement iOS, les performances des LLM sont très irrégulières. Swift et SwiftUI évoluent trop vite, et la documentation officielle y est aussi pour quelque chose. C’est utile pour générer des vues simples, mais dès qu’on touche à l’asynchrone ou à une logique métier complexe, ça s’effondre vite. Ça peut quand même aider à orienter, mais le risque de partir dans de mauvaises réponses est élevé
Les défenseurs des LLM négligent souvent le fait que la plupart des goulots d’étranglement ne se situent pas dans la génération de code. Faire du code rapidement ne suffit pas : il faut investir deux fois plus de temps dans la review, les tests et la compréhension de la codebase. À long terme, on ne peut pas maintenir le logiciel — corrections de bugs, refactoring, etc. — sans passer par là
Lire du code est bien plus difficile qu’en écrire, donc en pratique je passe beaucoup plus de temps à le comprendre. Pourtant, un CEO que j’ai rencontré soutenait qu’en fournissant le contexte à l’outil, les développeurs n’auraient plus besoin de lire le code. Selon lui, l’IA changerait la nature même de l’ingénierie. Honnêtement, ça me laisse perplexe
Quand un LLM me réexplique mon propre code, je trouve ça plutôt utile
C’est exactement ce que je me dis chaque fois que j’entends quelqu’un encenser les éditeurs de code automatisés
En pratique, la plupart des développeurs ne se préoccupent pas tant que ça de l’implémentation interne des bibliothèques de dépendances. Ce qui compte, c’est que l’interface fonctionne. Il existe certes une grande différence entre du code produit par un LLM et l’ajout d’un package npm ou d’une rust crate, mais si cette pratique est si répandue, ce n’est pas sans raison
Je pense à peu près pareil. En ce moment, j’utilise surtout les LLM pour apprendre de nouvelles technos ou générer du code client pour des API standard, en particulier boto3. J’ai aussi essayé Windsurf pour m’aider à modifier des fichiers docker compose, mais j’ai été déçu car ça ne fonctionnait pas correctement. On peut peut-être faire un prototype avec, mais ça ne fait pas tout. Je pense que les LLM ont vraiment changé la donne côté devops, dans le sens où les détails des API comptent moins qu’avant. En revanche, les décisions importantes doivent toujours être prises par moi. Je définis moi-même les interfaces, et je laisse seulement le LLM implémenter. Pour moi, ce n’est pas du « vibe coding »
En review de code, j’ai vu surgir d’énormes bugs, et l’efficacité gagnée avec Cursor a disparu instantanément. Je suis revenu à VSCode, et je n’utilise Copilot que de façon limitée, quand j’ai une demande précise. La complétion par tabulation de Cursor paraît magique au début, mais l’effet s’estompe vite
Le plus amusant, c’est de voir Cursor essayer, via la complétion par tabulation, de retaper du code qu’un collègue venait tout juste de supprimer
Je me demande quelles contraintes ont été données aux agents de génération de code — par exemple les principes SOLID, le lint, une couverture à 100 %, une documentation de conception claire, etc.
Cet avis me parle aussi. J’utilise énormément les LLM, mais avec deux règles. D’abord, je ne leur confie jamais les problèmes qui demandent une réflexion approfondie — pour une conception complexe, je résous forcément ça moi-même. Ensuite, je relis et corrige toujours minutieusement, ligne par ligne, le code produit par le LLM. En général, ce code est verbeux ou trop défensif. Même si on améliore ça avec des prompts, au final c’est toujours moi qui porterai la responsabilité de la maintenance future. Si je reste passif face au résultat généré, ça m’inquiète. Avec ma manière de faire, je continue d’utiliser beaucoup les LLM et je développe quand même plus vite
Moi, je délègue justement l’analyse approfondie à l’IA, dans le but d’obtenir un plan d’exécution concret — étapes détaillées d’implémentation, critères de validation, etc. — ainsi que des rapports reproductibles. La planification et la validation demandent certes des itérations, mais avec l’aide de l’IA j’arrive à finir bien plus vite. Parfois, avec un bon plan, tout se règle en une seule fois. Quand la cohérence est assurée par une planification détaillée et une documentation solide, c’est très satisfaisant
Si le code produit par un LLM doit être relu minutieusement ligne par ligne, on peut quand même se demander si cela fait réellement gagner du temps
Certaines entreprises imposent aux ingénieurs logiciel d’utiliser des LLM, en mesurant leur usage de Copilot/Cursor. Il y a de fortes chances que ces statistiques servent ensuite d’indicateur pour les licenciements. Après un mois d’usage forcé des LLM, j’ai eu l’impression que mes compétences se dégradaient rapidement. C’est utile pour les tâches simples, mais dès qu’on commence à trop leur déléguer la réflexion, on tombe facilement dans des boucles. Ma productivité n’a pas augmenté ; à la place, la charge de travail du sprint a simplement grossi. Il règne dans l’entreprise une sorte de foi religieuse autour des LLM. Les questions de sécurité sont aussi très sérieuses. Beaucoup de signes montrent qu’on est probablement au sommet du hype cycle. À moins que les entreprises d’IA ne construisent carrément des centrales nucléaires, maintenir les grands modèles actuels coûtera tellement cher qu’ils finiront par disparaître. À terme, je pense qu’il ne restera guère que des fonctions d’autocomplétion turbo. Les modèles transformers ont eux aussi des limites claires ; comme les réseaux de neurones des années 80, ils ne survivront que pour des usages spécifiques avant de retomber dans l’oubli. Puis ils reviendront peut-être sur le devant de la scène dans 30 ans, après quelques hauts et bas. Et c’est là qu’on verra qui nageait nu
Pour éviter ça, on applique notre propre règle interne : au moins une fois par semaine, on coupe complètement Copilot et on travaille en « no Copilot Fridays »
Moi aussi, je n’utilise Cursor que pour l’autocomplétion et de petits snippets, mais malgré ça, je sens déjà une baisse de niveau. Au fond, ça rappelle juste le fonctionnement du cerveau : « ce qu’on n’utilise pas, on l’oublie »
J’ai observé des problèmes similaires. Sur mes projets jouets, j’utilise les LLM à 90 %. C’est 10 fois plus rapide que coder à la main, mais la qualité de la conception est plus faible et l’ensemble paraît étrange. Je crois que le code piloté par LLM représente l’avenir, mais si on ne le gère pas bien, on bascule vite dans le chaos. J’essaie aussi de modifier mes prompts pour pousser des améliorations d’architecture de façon répétée, mais les résultats restent irréguliers. La solution passera peut-être par un meilleur prompt engineering, ou par une documentation plus claire de la conception et des consignes. Si les outils devenaient 10 fois plus rapides et avec moins de latence, l’expérience perçue changerait complètement
J’aimerais que cette période « 10 fois meilleure » arrive vite. Mais le problème aujourd’hui, c’est qu’on nous la vend déjà comme si on y était. Beaucoup de gens se demandent alors : « est-ce que c’est moi qui l’utilise mal ? » Pourtant, à mon avis, les outils n’en sont pas encore là
Ça marche bien si on définit soi-même les classes et les méthodes, puis qu’on laisse le LLM faire seulement l’implémentation. Pour les parties complexes, je laisse des notes dans le corps des méthodes pour indiquer la direction à suivre. De cette façon, c’est moi qui garde la vision d’ensemble, et le LLM ne s’occupe que de générer du code ciblé. Un LLM me fait penser à un développeur junior rapide, un peu trop volontaire. Comme le coût de génération du code est devenu si faible, on peut jeter et recommencer sans hésiter. Dans mon cas, j’ai réécrit plusieurs fois de zéro du code de traitement de dataset avec l’aide d’un LLM, et j’ai fini par obtenir le résultat et les performances que je voulais. Si quelqu’un d’autre l’avait écrit pour moi, j’aurais probablement abandonné ce travail
Ces outils brillent au stade du prototype sur un projet greenfield. Mais plus on s’approche d’un vrai déploiement, plus l’effet x10 disparaît. Si on ne gère pas soigneusement l’architecture, on finit surtout par se rajouter du travail
Sur une codebase complexe, pour l’instant, ça vaut surtout comme une saisie avancée voix-vers-texte — sauf que si ce n’est pas de la voix, coder à la main est parfois plus rapide
Je suis d’accord sur le fait qu’il faut consigner explicitement l’architecture et les guidelines. Plus on définit clairement les contraintes et les comportements, plus c’est efficace
L’idée principale d’un vieux texte célèbre de Dijkstra, « The Foolishness of Natural Language Programming », correspond bien à la discussion actuelle. Il y défend l’idée que seuls les langages formels ont permis les immenses progrès de la programmation. Vu sous cet angle, les LLM et le vibe-coding risquent de transformer le développement en une sorte de magie réservée à une minorité capable de bien prompter
Pour moi, Copilot n’est vraiment bon que quand il propose moins de 500 caractères de code. En Go et en Python, j’y apprends aussi de nouveaux patterns et je tape moins. Pour moi, ce n’est qu’une meilleure autocomplétion. Dès que ça devient plus long ou plus complexe, le coût de correction et de remarques dépasse le bénéfice — sauf peut-être pour du code très répétitif
Aujourd’hui, il faut absolument comprendre les résultats générés par les LLM et les superviser de près. En revanche, comme de nouveaux modèles arrivent toutes les deux ou trois semaines et sont bien meilleurs que les précédents, je pense qu’il est encore trop tôt pour tirer des conclusions trop tranchées.
Je pense que c’est un article qui restitue très bien, de manière concrète, les difficultés et les inquiétudes vécues sur le terrain du développement avec les LLM. Je l’ai lu en partageant le constat sur les limites que beaucoup rencontrent actuellement. En particulier, j’ai trouvé essentiel de souligner l’incohérence des LLM, la difficulté à prédire leurs résultats, ainsi que les inquiétudes liées à la maintenance à long terme.
Cela dit, nous tentons pour notre part une collaboration avec l’IA sous un angle légèrement différent, et je me permets de partager prudemment notre point de vue. Notre IA, « Jane », ne se contente pas de produire du code : elle se concentre sur l’apprentissage et la compréhension des « bons patterns de code », fondés sur la profondeur d’analyse humaine (celle des développeurs), ainsi que sur la manière d’assurer une « cohérence de maintenance » du code en apprenant le pattern lui-même.
Comme l’IA ne peut pas être parfaite dès le départ, nous ne considérons pas les incohérences ou les « erreurs » qui en découlent comme de simples problèmes ; au contraire, nous les utilisons activement comme des « données de pattern » essentielles pour permettre à « Jane » d’apprendre par elle-même et de s’améliorer. De la même façon que l’être humain lit des patterns dans une nature complexe, nous choisissons de chercher des pistes d’amélioration dans l’imperfection même de l’IA.
Grâce à cette approche de « pattern learning/management » guidée par l’humain, nous visons à résoudre à la racine les problèmes mentionnés dans l’article — baisse de qualité du code, incohérences, etc. — et à produire des résultats avec une « cohérence de maintenance » très élevée. Nous entraînons l’IA à aller au-delà de la simple génération de code boilerplate, afin qu’elle devienne un partenaire de collaboration plus profond, capable par exemple d’analyser les patterns cachés d’incohérence dans une base de code existante et de proposer des pistes d’amélioration.
Il reste encore beaucoup de chemin et le processus est exigeant, mais nous pensons que cette forme de collaboration, dans laquelle notre « Jane » et les développeurs apprennent et évoluent ensemble en faisant de la « cohérence de maintenance » une valeur centrale, montre un potentiel de rupture pour dépasser les limites actuelles de l’usage des LLM. Au-delà d’utiliser l’IA comme un simple outil, nous espérons susciter de l’intérêt pour notre démarche, qui consiste à en faire un partenaire avec lequel grandir ensemble et construire une meilleure culture du code.
Merci encore pour ce très bon article et pour ces éclairages précieux !