En bref / Points clés
La promesse de la vitesse 10x se heurte à un mur
Le développeur Shiv Bhosale s'est lancé dans un projet ambitieux de sept mois, construisant K10s, un tableau de bord Kubernetes sensible aux GPU, entièrement avec Claude. Cet effort intensif de "vibe coding" a abouti à 50 fonctionnalités distinctes, chacune semblant s'intégrer proprement au cours d'une seule session de développement. La génération rapide de composants individuels a favorisé un sentiment enivrant de progrès, suggérant un avenir où des applications complexes pourraient se matérialiser à des vitesses sans précédent.
Cette approche a cultivé l'attrait séduisant de la vitesse 10x, où les développeurs se sentaient habilités à prototyper et à implémenter de nouvelles capacités avec une facilité remarquable. La sortie efficace et basée sur les sessions de Claude a renforcé la perception que chaque fonctionnalité était un succès autonome, nécessitant un effort d'intégration minimal. Cela a créé un faux sentiment de solidité architecturale, masquant les problèmes sous-jacents par la vitesse de génération.
Cependant, l'illusion s'est brisée de manière catastrophique lorsque Bhosale a finalement tenté de combiner les 50 fonctionnalités en une application cohérente. L'ensemble du système a implosé, révélant des incohérences architecturales fondamentales : le changement de vues affichait des données obsolètes, des tableaux autrefois remplis apparaissaient inexplicablement vides, et des fonctions clés critiques effectuaient trois actions différentes et imprévisibles selon l'écran actif. Cette panne complète, due à un manque de prévoyance architecturale de la part de l'IA, a forcé Bhosale à abandonner sept mois de travail, à archiver l'intégralité du code et à redémarrer le projet de zéro.
Erreur n°1 : Des fonctionnalités sans plan directeur
Le défaut fondamental de l'IA est rapidement apparu : elle excelle à générer des fonctionnalités isolées, et non des architectures cohérentes. Chaque invite fonctionne comme une directive cloisonnée, totalement inconsciente des 49 autres fonctionnalités partageant l'état au sein du projet K10s de Shiv Bhosale. Claude a livré des composants individuels, mais, de manière critique, il lui manquait toute compréhension de la manière dont ces pièces devaient interagir en tant que système unifié.
Cette approche fragmentée a inévitablement conduit à une base de code fragile et difficile à maintenir. Lorsque Bhosale a essayé d'utiliser tout ensemble, toute la structure a implosé. Le changement de vues affichait des données obsolètes, des tableaux autrefois remplis apparaissaient vides, et une seule touche effectuait trois actions différentes selon l'écran. Les fonctionnalités individuelles, propres en isolation, ne fonctionnaient tout simplement pas ensemble.
La solution de Bhosale était claire : le développeur doit reprendre le rôle d'architecte. Il a conçu manuellement l'architecture du système, la documentant minutieusement dans un fichier `Claude MD`. Ce n'est qu'alors qu'il a tiré parti de Claude pour les "tâches ennuyeuses" – l'implémentation de fonctionnalités spécifiques strictement dans le cadre du plan structurel prédéfini et écrit à la main. Ce changement a transformé l'IA d'un constructeur autonome en un outil d'implémentation puissant et guidé.
Erreur n°2 : L'« objet divin » est la valeur par défaut
L'approche par défaut de l'IA est l'anti-pattern de l'objet divin, qui consiste à entasser toute la logique dans une seule structure de données massive pour trouver le chemin le plus court vers une fonctionnalité opérationnelle. Le code de K10s de Shiv Bhosale en est un exemple frappant, avec une seule structure s'étendant sur un nombre étonnant de 1 690 lignes. Cet objet monolithique contenait une méthode `Update()` de 500 lignes et 110 cas de commutation, un témoignage clair de sa portée ingérable.
Une telle conception monolithique rend la maintenance impossible, favorisant un couplage étroit entre des fonctionnalités disparates. Un léger changement dans une zone risque d'entraîner des défaillances en cascade dans l'ensemble du système fragile. L'expérience de Bhosale avec des données obsolètes, des tables vides et des fonctions clés incohérentes entre les vues découlait directement de ce défaut architectural, rendant l'application intrinsèquement instable.
Rectifier cela exige des instructions explicites au LLM. Les développeurs doivent forcer Claude à séparer les préoccupations, en divisant la logique en vues, composants et structures de données distincts. Cette orientation architecturale empêche activement l'IA de se rabattre sur des structures monolithiques, favorisant une base de code plus modulaire et maintenable. Pour plus d'informations sur le projet de Bhosale et son évolution, explorez le dépôt GitHub K10s : shvbsle (Shiv Bhosale) / k10s - GitHub.
Erreur n°3 : La vélocité vous piège dans le **scope creep**
La "gratuité" perçue du code généré par l'IA s'avère dangereusement trompeuse, menant directement à un scope creep rampant. Lorsque Claude peut apparemment créer 50 fonctionnalités en autant de sessions isolées, l'impulsion d'en ajouter continuellement davantage devient irrésistible. Cette vélocité rapide, bien qu'exaltante au début, masque une dette technique croissante et attire les développeurs dans un projet en constante expansion.
Chaque nouvelle fonctionnalité, aussi triviale soit sa création, introduit des coûts cachés importants : - support à long terme - documentation complète - gestion des cas limites imprévus - augmentation de la charge cognitive de l'utilisateur Le K10s de Bhosale, avec ses 50 fonctionnalités repliées, illustre parfaitement cet écueil ; l'astuce de la vélocité masquait le véritable fardeau d'une prolifération non architecturée.
Pour combattre cette expansion insidieuse, les développeurs doivent établir des limites strictes. Shiv Bhosale a explicitement défini pour qui il *ne construisait pas*, en fixant des contraintes négatives. Il a ensuite codifié ces limites de portée explicites directement dans le fichier de contexte `Claude MD`, empêchant l'IA de reconstruire des fonctionnalités existantes ou d'étendre excessivement le mandat du projet. Cette contrainte proactive garantit que la vitesse de l'IA sert un objectif précisément défini, plutôt que de créer une prolifération de fonctionnalités ingérable.
Foire aux questions
Qu'est-ce que le 'vibe coding' avec l'IA ?
C'est un style de développement rapide où un programmeur utilise un LLM comme Claude pour générer des fonctionnalités basées sur des invites de haut niveau ou des 'vibes', souvent sans plan architectural strict et prédéfini.
Pourquoi l'IA crée-t-elle des 'god objects' ?
L'IA prend le chemin le plus court vers une solution fonctionnelle. Entasser tout l'état et la logique dans un seul objet est souvent le moyen le plus simple de répondre à une invite pour une nouvelle fonctionnalité, ignorant la maintenabilité à long terme.
Comment les développeurs peuvent-ils éviter les pièges du codage par l'IA ?
En définissant manuellement l'architecture de base, en fixant des limites de portée claires et en utilisant l'IA comme un outil pour implémenter des tâches plus petites et bien définies plutôt que comme un architecte autonome.
Qui est Shiv Bhosale et qu'est-ce que K10s ?
Shiv Bhosale est le développeur qui a partagé cette expérience. K10s est son projet, un tableau de bord Kubernetes sensible aux GPU, qu'il a réussi à reconstruire après que la version initiale générée par l'IA ait échoué en raison de problèmes architecturaux.