Sous-titre : La mélancolie du vibecoding en tant que professionnel de l'informatique
Aujourd'hui, j'ai demandé à Claude Code : « Ma façon de faire est-elle la bonne ? »
Comme d'habitude, il a longuement justifié sa réponse en disant : « Vous faites du bon travail. » Je l'ai regardé avec méfiance et j'ai répondu : « Je sais que vous êtes entraîné à faire des compliments, donc ce n'est pas très réconfortant. » Mais c'est mieux que pas de réconfort du tout, et j'ai continué à creuser dans les détails. Contrairement à l'époque où j'étais étudiant, il n'y a plus de professeurs ou de seniors pour me donner les bonnes réponses.
Ces jours-ci, je ne code plus. Je transmets les exigences et je supervise l'avancement.
Ma préoccupation principale ces jours-ci est le processus de développement et la qualité. À mesure que la taille d'un logiciel augmente, il dépasse facilement la quantité de contexte que l'IA peut lire. Même au sein du contexte, l'IA est confuse. Il n'est pas facile de contrôler en permanence un code volumineux qui dépasse ce contexte avec la 'capacité mentale' d'une petite IA. Après le terme 'ingénierie de contexte', le terme 'ingénierie de harnais' est récemment apparu.
Ainsi, si je trouve une bonne référence sur les réseaux sociaux, je la donne d'abord à l'IA pour qu'elle analyse s'il y a des points à appliquer au projet Naia, puis je les mets en œuvre. En faisant cela, j'apprends aussi beaucoup en posant des questions sur les termes que je ne connais pas.
Cependant, je me demande toujours si je fais bien les choses et si c'est vraiment la meilleure approche. Ce doute était fondé. Un jour, l'IA a prétendu avoir fait une revue, mais il n'y avait aucune trace de lecture des fichiers. Elle a omis du code, mal défini la portée, et a dit avoir vu ce qu'elle n'avait pas vu. Quand je lui ai demandé de répéter la revue jusqu'à la deuxième itération, à la troisième itération environ, elle a ajouté à sa réponse qu'elle avait revu le code tel quel et n'avait rien trouvé, et a validé le tout. En y réfléchissant, étant donné la structure des LLM, c'est une réponse plausible qu'elle aurait ajoutée. Elle se dit : « À ce stade, c'est généralement terminé, n'est-ce pas ? » et elle y croit comme si c'était la vérité.
Aujourd'hui, j'ai écouté la présentation de Goose Kim, qui a développé le SDK moai. J'ai de nouveau analysé ce projet et j'ai trouvé des points d'amélioration. #87issue Ce que j'ai trouvé cette fois-ci, c'est l'utilisation d'EARS. C'est une norme d'exigences aérospatiales de Rolls-Royce (IEEE RE'09), adoptée par Amazon en 2025 pour le développement 'AI-native'. Il s'agit d'une méthode qui utilise une grammaire structurée pour empêcher l'IA d'interpréter différemment le critère de « terminé » pour chaque problème.
En répétant ces actions, j'essaie continuellement d'améliorer le processus de développement basé sur l'IA du projet. J'ai analysé et amélioré jikime-adk, des articles d'arXiv, Dueling LLMs de Google Cloud, et Spec-Driven Development de Thoughtworks. Bien sûr, ce n'est pas que je connaisse tout cela moi-même, ce sont aussi des analyses faites par Claude.
J'ai analysé open-swe de LangChain et appliqué le modèle ensure_no_empty_msg pour empêcher l'IA de bâcler les revues avec des réponses vides. Dans jikime-adk, j'ai appliqué un modèle qui ajoute une section ## AI Context aux messages de commit pour enregistrer les décisions prises par l'IA et les pièges découverts, afin que le git log puisse servir de source de restauration même si la session est interrompue.
En commun, chacun résolvait des problèmes similaires de manière indépendante.
Mais je me demande toujours si cette méthode est la bonne... Je crains que cela ne devienne un Frankenstein, et en tant que professionnel, c'est étrange. Quoi qu'il en soit, il n'y a pas de manuel et le manque de preuves que ce soit la meilleure approche est flagrant.
Toutes les méthodologies d'ingénierie logicielle que nous utilisions sont le fruit de décennies d'échecs accumulés. Agile est apparu parce que Waterfall échouait constamment, et le TDD est né parce que le développement sans tests entraînait des problèmes répétés, il y a donc une base solide.
Mais ce que j'ai assemblé n'a pas été conçu pour fonctionner ensemble. Une norme aérospatiale, un développeur indépendant coréen et un agent LangChain se trouvent dans le même système.
Cette incertitude m'a poussé à rechercher des études externes. L'article V-Bounce (arXiv 2408.03416) affirme que le rôle humain passe d'implémenteur à vérificateur à l'ère de l'IA. C'est vrai en théorie, mais je n'ai pas trouvé d'implémentation concrète. Le Spec-Driven Development de Thoughtworks dépend d'outils spécifiques. Chez Anthropic, ils affirment que 90% du code de Claude Code est écrit par Claude Code, mais ils n'ont pas divulgué leur méthodologie.
En fin de compte, tous ceux qui développent sérieusement avec l'IA le font chacun à leur manière. Il n'y a pas de norme.
Ce que je fais ces jours-ci, c'est chercher des moyens de mesurer si ce Frankenstein fonctionne réellement. Le CI échouait, mais le merge était fait, et il y avait un texte indiquant une revue, mais aucune trace de lecture des fichiers. La méthodologie est conçue, mais elle n'est pas appliquée. Il semble y avoir un système, mais je ne sais pas s'il fonctionne. La seule façon de le vérifier serait de générer des chiffres honnêtes produits par le code lui-même, et non par le LLM, ou si l'on utilise un LLM, de dériver des « chiffres » montrant une amélioration statistique. Je réfléchis à la manière d'analyser périodiquement les échecs récurrents du projet pour que l'IA propose des améliorations, et de mesurer les progrès grâce à l'évaluation des performances de l'ingénierie de contexte et de harnais.
Pour l'instant, je tiens fermement les rênes et j'avance. Je ne sais pas encore où nous allons, mais j'espère ne pas être aveugle. Je suis en train de fabriquer les rênes... ...alors que c'est la première fois que je monte à cheval. C'est comme le harnais qui retient le vibecoding.
