L’article critique l’idée selon laquelle l’ère de l’IA rendrait la technique obsolète au profit d’une approche strictement "product-first". L’auteur souligne que, malgré les gains de productivité permis par l’IA, la qualité technique reste essentielle pour éviter des problèmes comme des performances médiocres, une architecture chaotique ou des solutions ingérables. Il met en garde contre l’usage abusif de l’argument "product-first" comme prétexte pour négliger la rigueur technique, même si des compromis sont parfois nécessaires pour livrer rapidement.
L’auteur, qui utilise massivement l’IA pour coder, rappelle que savoir quoi construire ne suffit pas : le comment compte toujours, surtout pour des projets complexes. Il cite Rich Hickey pour rappeler que la simplicité et la clarté technique restent des piliers, même avec des outils avancés. L’IA accélère le développement, mais ne dispense pas d’une réflexion sur l’architecture et la maintenabilité.
L’article oppose deux approches du développement logiciel : le vibe coder, qui privilégie la rapidité de prototypage via des outils comme l’IA, et l’ingénieur logiciel, axé sur la qualité, la maintenabilité et la sécurité du code dans un environnement réel. L’auteur souligne que l’IA excelle pour générer des prototypes, mais que son utilisation dans un codebase partagé nécessite une évaluation rigoureuse, notamment en termes de revues, de tests et de maintenance.
L’idée centrale réside dans la mesure de la productivité : un vibe coder se concentre sur le temps nécessaire pour obtenir une première version fonctionnelle, tandis qu’un ingénieur évalue le temps jusqu’à une fusion sûre, incluant les coûts de revue, de déploiement et de maintenance. L’auteur met en garde contre l’illusion de gains de productivité si l’IA génère du code non maîtrisé, transférant la charge en aval.
Enfin, l’article insiste sur la nécessité de contraindre la production de code par l’IA pour éviter une accumulation de dette technique. Le code généré doit être minimaliste, justifié et aligné sur les standards existants, sous peine de complexifier inutilement le travail des équipes en aval.
L’article aborde les conséquences du départ d’un développeur "rockstar", souvent charismatique et innovant, dont les choix techniques complexes laissent une codebase incompréhensible et ingérable pour ses successeurs. Ces profils, obsédés par la performance et les nouvelles technologies, privilégient la rapidité et l’originalité au détriment de la lisibilité et de la maintenabilité, rendant le code difficile à maintenir après leur départ.
Avec l’essor de l’IA générative, le phénomène s’amplifie : les outils comme les LLM produisent massivement du code sans se soucier de son intégration ou de sa cohérence globale, complexifiant encore les systèmes existants. Les développeurs se retrouvent submergés par une dette technique exponentielle, où la dépendance à l’IA pour comprendre ou corriger le code devient problématique, risquant d’enfermer les équipes dans un cycle de complexité auto-entretenue.
L’auteur explique comment il a modernisé un projet legacy reposant sur Alice, Nelmio, Hautelook et Faker pour le rendre plus maintenable avec Doctrine. Après avoir réduit la dépendance à Faker et converti les fixtures Alice de YAML à PHP, il a évité un piège courant : migrer Alice vers Foundry sans résoudre les problèmes sous-jacents, ce qui aurait prolongé la dette technique. En créant une commande personnalisée pour charger toutes les fixtures en une seule fois, il a simplifié le processus et supprimé plusieurs dépendances, dont doctrine/doctrine-fixtures-bundle. Cette approche a permis une migration rapide et une meilleure maintenabilité, illustrant l’importance de privilégier des solutions simples et intuitives plutôt que des refontes coûteuses et peu efficaces.
L’article explique pourquoi les architectures CRUD (Create, Read, Update, Delete) compliquent les tests unitaires et augmentent la charge cognitive des développeurs. L’auteur souligne que la logique métier, dispersée dans des contrôleurs, services, FormType ou événements Doctrine, devient difficile à identifier et à tester, favorisant la duplication de code et les erreurs. Les modifications nécessitent de comprendre des interactions complexes, ralentissant le développement et augmentant le risque de régressions.
L’auteur illustre ce problème avec des exemples concrets en Symfony, où des règles métiers se cachent dans des couches techniques variées (validations dans les formulaires, effets de bord dans les écouteurs Doctrine). Cette dispersion empêche une couverture de test efficace, car les tests doivent souvent simuler des dépendances externes (bases de données, envoi d’emails) plutôt que de se concentrer sur la logique pure.
Enfin, l’article critique l’illusion des services génériques, qui masquent la complexité sans résoudre le problème de fond. La solution proposée est de distinguer clairement les contrats d’entrée (validation des données) des invariants métiers (règles de transition), afin de structurer le code de manière plus testable et maintenable.
Dans un monde où l’IA transforme radicalement le développement logiciel, l’auteur propose les 4C (Concevoir, Contextualiser, Contraindre, Comprendre) comme cadre pour maintenir la qualité et la maintenabilité du code. Face à l’évolution rapide des outils (comme les LLMs), ces principes servent de boussole pour structurer les interactions avec l’IA, en insistant sur la rigueur en amont (conception détaillée, explicitation des besoins) et la compréhension des invariants. Une approche essentielle pour éviter les pièges du Vibe Coding et préserver la stabilité des projets.
Tout est dans le titre