Contexte et problème soulevé
L’article signale que, dès 2025, des développeurs déclarent ne plus écrire de code, que les revues de code sont « mortes » et que la lecture du code s’érode. Cette évolution culturelle s’accompagne d’une dégradation observable : les projets « vibe‑coded » deviennent rapidement des systèmes inmaintenables. L’auteur explique que la cause principale réside dans l’absence de métriques fiables pour mesurer la maintenabilité ou la qualité d’architecture, car les effets négatifs n’apparaissent qu’après plusieurs mois, voire années.
Limites techniques des LLMs pour la maintenabilité
Les modèles de génération de code actuels, même les plus avancés (SOTA), sont entraînés sur des bases de code publiques où la majorité du code est de mauvaise qualité. Le texte indique que ces modèles ne possèdent aucun fitness function capable d’évaluer la maintenabilité à long terme. En apprentissage par renforcement, le signal de récompense doit être immédiat ; or la maintenabilité se mesure sur des horizons temporels que les algorithmes ne peuvent pas intégrer. Cette inadéquation conduit les LLMs à proposer des refactorisations superficielles, comme la création de petites fonctions qui ne sont pas réellement réutilisables, augmentant ainsi la charge cognitive du lecteur.
De plus, l’auteur souligne que les LLMs peinent à « simplifier » le code : ils extraient des fonctions sans garantir que la compréhension du comportement global reste aisée. Cette pratique viole le principe d’encapsulation, car le développeur doit désormais consulter plusieurs implémentations dispersées pour saisir le flux logique. Le texte cite le modèle de Dreyfus, précisant que la plupart des développeurs se situent au niveau « débutant avancé » et ne maîtrisent pas l’art de définir des fonctions claires et réutilisables, ce qui rend l’assistance de l’IA encore moins efficace.
Enjeux d’évaluation et perspectives
Sans métriques de maintenabilité, les équipes ne peuvent pas automatiser la détection de « code smells » à grande échelle. L’article propose que les entreprises adoptent des politiques « NO‑AI » comme avantage concurrentiel, arguant que la dépendance à l’IA empêche l’apprentissage des bonnes pratiques. Cette position repose sur le constat que les LLMs, en tant qu’outils, ne corrigent pas leurs propres erreurs : ils reproduisent les défauts du corpus d’entraînement et ne bénéficient d’aucun retour d’expérience à long terme.
Pour rendre l’IA réellement utile dans le cycle de vie logiciel, il faudrait concevoir des boucles de rétroaction qui intègrent des mesures de stabilité sur plusieurs itérations de déploiement, voire des métriques de couverture de tests et de cohérence d’invariants. En l’état, les modèles restent des assistants de productivité à court terme, capables d’automatiser les tâches répétitives mais incapables de garantir la robustesse du code sur le long terme.
