Notes de terrain tirées du déploiement de vrai code avec Claude

 (diwank.space)
77 points par GN⁺ 2025-06-09 | 7 commentaires | Partager sur WhatsApp
  • En appliquant Claude, un outil d’IA, à un vrai service, l’article résume des méthodes réalistes pour atteindre un gain de productivité de développement multiplié par 10, ainsi que les bonnes pratiques d’adoption
  • Le « vibe-coding » n’est pas une simple mode mais une méthodologie concrète : avec de bonnes habitudes de développement et la bonne infrastructure, on peut maximiser les points forts de l’IA et compenser ses faiblesses
  • Le rôle de l’IA est clairement séparé en trois modes — « rédacteur de premier jet », « pair programmer » et « relecteur de code » —, et une documentation ainsi que des garde-fous adaptés à chaque étape sont indispensables
  • Le point clé consiste à utiliser un fichier CLAUDE.md dans chaque projet pour documenter clairement les conventions, l’architecture, les patterns et les interdits, tout en guidant efficacement l’IA avec des « anchor comments » dans le code
  • Le code de test doit impérativement être écrit par un humain, et il faut fixer des limites strictes pour empêcher l’IA de modifier les zones critiques comme les tests, les migrations, la sécurité, les contrats d’API ou les secrets
  • Lorsqu’une équipe adopte le codage avec IA avec les bons garde-fous et les bonnes habitudes, elle peut améliorer fortement à la fois la fréquence de déploiement, la stabilité et la vitesse de développement, et le partage de pratiques et de patterns issus du terrain devient le cœur de la culture de développement assisté par IA

Le vibe coding n’est pas qu’une vibe

  • Cet article est un guide de terrain sur une nouvelle manière de développer des logiciels avec l’IA : il n’explique pas seulement comment l’utiliser, mais aussi pourquoi ce mode de développement est réellement efficace
  • Il montre, exemples concrets à l’appui, que le gain de productivité x10 souvent présenté comme un mythe n’est possible qu’au prix d’habitudes de travail pragmatiques permettant de maximiser les forces de l’IA tout en corrigeant ses faiblesses
  • À partir du codebase de production de Julep, il partage une infrastructure et un savoir-faire opérationnel de terrain tels que des modèles de CLAUDE.md, une stratégie de commit et des garde-fous pour éviter les catastrophes en production
  • Il insiste notamment sur le fait que le code de test doit absolument être écrit à la main, car une dépendance excessive à l’IA peut conduire à de graves incidents et à des cauchemars de débogage
  • Le développement assisté par IA comprend trois modes (rédaction initiale, pair programming, relecture), chacun avec son propre rythme et ses principes : selon le contexte, il faut soit laisser l’IA prendre la main, soit reprendre un pilotage humain direct
  • Message central : l’IA ne démultiplie les capacités que si de bonnes habitudes et des limites claires sont en place, et les résultats de recherche montrent eux aussi que « les équipes ayant une discipline de développement rigoureuse dominent largement à la fois en vitesse de déploiement et en qualité »

Pourquoi écrire cet article : du mème à la méthode de terrain

  • L’idée de confier le code à l’IA pendant que le développeur « se contente de suivre la vibe » (vibe-coding) est à l’origine une blague lancée dans un tweet par Andrej Karpathy
  • À l’époque, la communauté des développeurs l’a accueillie comme la meilleure des fantasmes — « l’IA travaille à notre place pendant qu’on boit un café » — en en riant
  • Mais avec la sortie de Sonnet 3.7 d’Anthropic et de Claude Code, cette blague a commencé à devenir une réalité. Des outils comme Cursor existaient déjà, mais Claude Code a commencé à donner une vraie sensation de « vibe coding »
  • Julep, où travaille l’auteur, porte un vaste codebase, de nombreux patterns de conception et même de la dette technique. La qualité du code et de la documentation y est maintenue avec rigueur, mais la complexité est telle qu’il faut parfois plusieurs semaines rien que pour comprendre l’intention et l’historique de chaque partie
  • Utiliser Claude sans garde-fous provoque un chaos comparable à celui d’un stagiaire surexcité qui commet des erreurs un peu partout
  • Cet article rassemble et partage uniquement des patterns et savoir-faire réellement éprouvés sur le terrain, forgés dans les tâtonnements, les sessions de débogage à 3 heures du matin et la survie en conditions de production

L’essence du vibe coding

  • Tout comme Steve Yegge a inventé le terme CHOP (Chat-Oriented Programming), le « vibe coding » est une nouvelle manière de développer dans laquelle on complète le code en dialoguant avec l’IA
  • Là où le codage traditionnel ressemble à une sculpture sur marbre, ligne par ligne avec minutie,
    • le vibe coding se rapproche du rôle de chef d’orchestre, et l’IA est l’interprète qui fournit la matière brute (les capacités de base en code)
    • le développeur conçoit la direction d’ensemble et la structure, puis l’IA traduit ce flux en code
  • Les 3 postures du vibe coding
    • 1. Utiliser l’IA comme rédacteur du premier jet (First-Drafter)
      • On se concentre sur l’architecture et la conception, pendant que l’IA génère rapidement les tâches répétitives (CRUD, boilerplate, etc.)
      • Cela ressemble à travailler avec un ingénieur junior capable d’écrire du code à la vitesse de la pensée, mais qui exige un guidage constant
    • 2. Faire du pair programming avec l’IA (Pair-Programmer)
      • C’est le mode le plus pratique et le plus efficace
      • Le développeur et l’IA échangent des idées ; l’humain dessine les grandes lignes et l’IA remplit les détails d’implémentation
      • Cela ressemble à coder en binôme avec un collègue qui possède énormément de connaissances en programmation, mais peu d’expérience réelle de déploiement
    • 3. Utiliser l’IA comme validateur / relecteur de code (Validator)
      • L’IA relit le code écrit par un humain et suggère bugs, améliorations et patterns oubliés
      • Elle joue le rôle d’un relecteur infatigable et méticuleux
  • Idée clé : le développeur passe du rôle d’« auteur » à celui d’« éditeur ». Au lieu d’écrire lui-même tout le code, il relit, corrige et oriente les résultats produits par l’IA.
  • Mais l’architecture globale et le contexte doivent impérativement rester pilotés par l’humain, car l’IA n’est qu’un « stagiaire à savoir encyclopédique » qui ne connaît pas le contexte de notre service ni de notre activité

Trois modes concrets du vibe coding : un framework

Après plusieurs mois d’expérimentations et d’incidents réels en déploiement, il apparaît que le vibe coding se décline en 3 modes, chacun avec son propre rythme, ses garde-fous et ses usages optimaux

  • Mode 1 : Playground (expérimentation / prototype / projet personnel)

    • Quand l’utiliser : hack du week-end, script personnel, PoC, test improvisé d’une idée, etc.
    • Caractéristiques : sans conception, documentation ni garde-fous, l’IA écrit 80 à 90 % du code. On passe de l’idée au résultat en quelques minutes
    • Risque : inadapté aux services en production et au code critique. À réserver au jeu et à l’expérimentation. Les principes d’ingénierie deviennent alors encore plus importants

  • Mode 2 : Pair Programming (usage réel / petit service)

    • Quand l’utiliser : projet de moins de 5 000 lignes, side project avec de vrais utilisateurs, démo, petit module, etc.
    • Point central : définir clairement en une seule fois dans CLAUDE.md les usages du projet, son architecture, ses patterns et ses consignes de test
    • Avantage : comme pour l’onboarding d’un nouveau développeur, il suffit de l’expliquer une fois à Claude pour qu’il génère du code de manière cohérente
    • Points pratiques :
      • guider Claude dans tout le code à l’aide d’anchor comments (AIDEV-NOTE, AIDEV-TODO, AIDEV-QUESTION, etc.) pour qu’il ne perde pas le contexte
      • ces commentaires servent de consignes consultables à la fois par l’IA et par les humains, et CLAUDE.md précise même les règles de gestion et des exemples

  • Mode 3 : Production / échelle monorepo (grand service)

    • Quand l’utiliser : grands services avec des dizaines à des centaines de développeurs, utilisateurs réels et risque de dégâts majeurs à la moindre erreur
    • Attention : à ce jour (juin 2025), le vibe coding massif et généralisé ne passe pas encore parfaitement à l’échelle
    • Principe : il est recommandé d’introduire le vibe coding service par service ou sous-module par sous-module, avec des frontières explicites et une gestion de version sur tous les points d’intégration (API, base de données, etc.), ainsi que des commentaires d’avertissement sur les interfaces et API critiques
    • Exemples concrets :
      • # AIDEV-NOTE: API Contract Boundary - v2.3.1
      • # Changes require version bump and migration plan
      • sans ces lignes de démarcation, Claude peut « améliorer » imprudemment quelque chose et casser l’ensemble du service réel
  • Conclusion : dans les grands projets, le vibe coding doit être introduit progressivement, service isolé par service isolé, et il faut impérativement l’accompagner de documentation, de guidelines et de revue selon les principes traditionnels pour garantir la fiabilité

Mettre en place un environnement de développement IA durable centré sur l’infrastructure

  • CLAUDE.md : une source unique de vérité (The Single Source of Truth) pour l’IA comme pour les humains

    • CLAUDE.md sert de « constitution » qui rassemble de façon structurée toutes les règles du projet, l’architecture, les points d’attention, le style de code, les interdictions, le glossaire métier, etc.
    • Il sert d’« ossature de connaissances » partagée entre l’IA et les nouveaux membres de l’équipe, avec une gestion minutieuse de consignes concrètes, d’exemples et d’interdictions
    • Les équipes qui investissent dans un bon CLAUDE.md obtiennent de meilleurs résultats
    • Voir notre CLAUDE.md de production
    • Plus la codebase grossit, moins CLAUDE.md suffit à lui seul ; il faut aussi transmettre clairement le contexte local à travers toute la base de code via des anchor comments (AIDEV-NOTE/TODO/QUESTION, etc.)
    • Si l’on compare la codebase à une ville, les anchor comments sont des panneaux qui évitent à l’IA comme aux humains de se perdre
    • Ces commentaires vont au-delà de la simple explication du code : ils conservent l’histoire du “pourquoi” de ce fonctionnement

  • Workflow Git, gestion structurée du code généré par l’IA

    • Plus la vitesse de génération de code par l’IA augmente, plus l’historique git risque d’être pollué s’il est mal géré
    • Avec des approches comme git worktree, on crée un espace d’expérimentation IA séparé de la branche principale : le code peut être généré librement, tandis que les traces restent distinctes et gérées proprement
    • Les messages de commit doivent toujours indiquer l’intervention de l’IA (avec un tag comme [AI], par exemple), afin de permettre aux reviewers d’y prêter une attention supplémentaire

Règle non écrite : les tests doivent impérativement être écrits par des humains

  • Principe le plus important du développement assisté par l’IA : « ne jamais confier les tests à l’IA »
  • Les tests ne sont pas simplement du code de vérification
    • Ce sont des spécifications exécutables dans lesquelles se reflètent le contexte réel du problème, l’identification des edge cases, l’interprétation des exigences métier, ainsi que la compréhension et l’expérience humaines du domaine
    • Les équipes de haut niveau qui réussissent à concilier vitesse et stabilité gèrent précisément ces tests avec une rigueur entièrement humaine
  • Les tests générés automatiquement par l’IA ne valident souvent que des parcours superficiels (happy path) et passent à côté de problèmes graves inattendus (par exemple des memory leaks)
  • Dans notre équipe, si l’IA modifie un fichier de test, la PR est automatiquement rejetée (sans exception)
  • Les tests sont à la fois la spécification du code, son filet de sécurité, et la sagesse accumulée de tous les bugs et edge cases
  • Ils doivent absolument être écrits à la main et protégés fermement pour que l’IA ne puisse pas y toucher

Passage à l’échelle et gestion du contexte : économie de tokens et optimisation du contexte

  • Erreur fréquente dans le développement de code avec l’IA :
    si l’on réduit au minimum le contexte (prompt, exigences, environnement, etc.) pour « économiser des tokens », on augmente au contraire les allers-retours et la consommation totale de tokens
  • Fournir le bon contexte est plus efficace sur le long terme
    • L’essentiel n’est pas d’être « minimal », mais de fournir dès le départ un « contexte pertinent et suffisant »
  • Mauvais exemple : prompt sans assez de contexte "Add caching to the user endpoint"
    • Claude produit alors un simple cache en mémoire, sans stratégie d’invalidation ni monitoring, sans prise en compte du multi-serveur, et sans solution contre le cache stampede
    • Résultat : plus de 3 cycles de correction, et au total plus de 4 fois plus de tokens consommés
  • Bon exemple : prompt riche en contexte 
    Add Redis caching to the GET /users/{id} endpoint.  
Context:  
* trafic de l’endpoint : 50 000 req/min, 12 serveurs API, faible variation des données  
* emplacement de l’infrastructure Redis existante, standard de key pattern, exigences de métriques basées sur Prometheus  
* cache-aside pattern, TTL de 1 heure, prévention du cache stampede (expiration anticipée probabiliste)  
* se référer au guide de caching
    • En fournissant un contexte précis dès le départ, on rend possible une implémentation juste, sans itérations inutiles
  • Conclusion :
    • « Les tokens sont un investissement dans de bons outils »
    • Si l’on injecte suffisamment de contexte en amont, on réduit les répétitions et les corrections à long terme, donc on économise en coût global
  • Conseil pratique : pour chaque projet, demander à Claude de mettre à jour CLAUDE.md avec les évolutions de la codebase et le contexte pertinent à chaque modification de code

Gestion des sessions et prévention de la pollution du contexte

  • Il est important de démarrer une nouvelle session Claude pour chaque tâche
    • Mélanger plusieurs tâches dans une même longue conversation (par exemple migration de base de données, design frontend, etc.) entraîne un mélange des contextes et des résultats non souhaités
  • Règle : une tâche = une session ; une fois la tâche terminée, on redémarre une nouvelle session
    • Cela permet de garder en permanence le « modèle mental » de Claude propre et focalisé
    • Comme lorsqu’on utilise des planches à découper séparées pour le poulet cru et les légumes, il faut isoler les contextes

Cas concret : refonte de la structure de gestion des erreurs

  • Présentation d’un cas réel où un mode de gestion des erreurs ad hoc sur plus de 500 endpoints a été remplacé par une hiérarchie d’erreurs structurée
  • La méthode consiste à faire rédiger à l’avance par un humain (architecte) la conception essentielle (SPEC.md / exigences / classification des erreurs), puis à confier à Claude le rôle d’exécutant pour la transformation massive du code réel (travail mécanique)
  • Principes d’architecture et spécifications détaillées, exemples de documents de conception et élaboration des concepts -> consignes de travail claires pour l’IA -> refactoring complet terminé en exactement 4 heures

Leadership et culture d’organisation à l’ère de l’IA

  • Le rôle des ingénieurs seniors évolue : au lieu d’écrire directement du code, ils se consacrent à la curation des connaissances, à la définition des garde-fous, et au guidage de l’IA comme des humains
  • Le Lean management, le déploiement continu et les autres pratiques modernes de développement restent tout aussi essentiels pour encadrer la collaboration avec l’IA

  • Checklist d’onboarding des nouveaux arrivants (séparation collaboration humain + IA)

    • Semaine 1 : consolider les bases
      • Lire le CLAUDE.md de l’équipe (commun / par service)
      • Configurer l’environnement de développement
      • Soumettre une première PR (100 % codée à la main, IA interdite)
    • Semaine 2 : pratique de la collaboration avec l’IA
      • Appliquer et configurer les templates d’équipe dans Claude
      • Résoudre un « problème jouet » avec l’IA
      • S’exercer aux patterns de prompt
      • Première PR assistée par l’IA (avec un mentor / senior)
    • Semaine 3 : autonomie en conditions réelles
      • Développer et déployer une fonctionnalité majeure avec l’aide de l’IA
      • Écrire soi-même les tests du code IA d’un collègue
      • Animer une session de code review

Construire une culture de transparence : afficher ouvertement l’usage de l’IA

  • Tous les commits faisant intervenir l’IA doivent l’indiquer clairement via un tag dans le message de commit, comme ci-dessous 
    feat: add Redis caching to user service \[AI]  
# \[AI] - plus de 50 % généré par l’IA, \[AI-minor] - moins de 50 %, \[AI-review] - IA utilisée uniquement pour la review  
# l’IA a rédigé le cache / le code client ; la conception des clés de cache, les tests et la validation ont été faits par un humain
  • Effets
    1. Les reviewers prêtent une attention particulière au code généré par l’IA
    2. Lors du débogage, il devient plus facile d’identifier l’origine du code
    3. On élimine la honte ou la culture de dissimulation autour de l’usage de l’IA, et on installe une culture d’équipe fondée sur un usage responsable de l’IA
  • Pour que chacun puisse utiliser l’IA sans pression et contribuer à une culture de haute performance, il est important d’encourager cette transparence active et de mettre en place des dispositifs culturels adaptés

Interdictions pour Claude : l’IA ne doit absolument jamais toucher à ceci

  • Les fichiers de test / migrations de base de données / code de sécurité critique / contrats d’API (sans gestion de version) / configuration d’environnement et secrets ne doivent absolument pas être automatisés par l’IA
  • Il insiste sur la nécessité de classer les erreurs par niveau de gravité — des problèmes de format ou de dépendances jusqu’à la destruction de données métier critiques — et d’appliquer des garde-fous supplémentaires et contraignants sur les zones à haut risque
  • Niveaux de risque des erreurs de l’IA (Hierarchy of AI Mistakes)
    • Level 1 : pénible mais non critique
      • Erreurs de formatage (détectées par le linter)
      • Code verbeux (refactorisation plus tard)
      • Algorithmes inefficaces (repérés lors du profiling)
    • Level 2 : erreurs coûteuses
      • Rupture de compatibilité d’API internes (nécessite une coordination d’équipe)
      • Changement des patterns existants (source de confusion)
      • Ajout de dépendances inutiles (alourdit le code)
    • Level 3 : préjudiciable pour la carrière (Career-Limiting)
      • Modifier les tests eux-mêmes pour faire correspondre les résultats
      • Briser le contrat d’API
      • Fuite de secrets / données personnelles
      • Corruption des migrations de données
    • Le niveau des garde-fous doit varier selon le niveau d’erreur, et les erreurs de Level 3 constituent aussi une menace majeure pour la carrière

L’avenir du développement : changements et direction à venir

  • En 2025, le développement assisté par l’IA ressemble à un adolescent : puissant, mais encore maladroit et brut
  • Mais sa courbe de progression est clairement en phase d’« accélération »
  • Une bonne documentation est l’infrastructure clé pour mettre en œuvre le DevOps à l’ère de l’IA
    • La documentation n’est plus seulement une « ressource de référence », mais une « interface » directe entre l’intention humaine et l’exécution par l’IA
    • Les équipes les plus performantes gèrent avec rigueur leur documentation, comme CLAUDE.md, avec le même sérieux que leurs tests

  • Évolutions attendues à l’avenir

    • Une IA capable de comprendre le contexte global du code
      • Compréhension non plus au niveau du fichier, mais jusqu’au niveau du service ou du système
    • Une mémoire persistante entre sessions et projets
      • Capable de mémoriser et de réutiliser durablement le contexte des conversations et du travail
    • Une IA qui propose activement des améliorations
      • Diagnostique à l’avance les problèmes et pistes d’amélioration, même sans demande explicite
    • Une IA qui apprend les patterns et préférences propres à chaque équipe
      • Génère automatiquement du code conforme au style et aux conventions de l’organisation
  • Mais, les fondamentaux ne changent pas :
    • Les humains définissent la direction, l’IA exécute et sert de levier
    • Aussi puissants que deviennent les outils, nous restons ceux qui les utilisent

Conclusion : commencez ici et maintenant

  • Si vous avez lu jusqu’ici, vous ressentez probablement à la fois de l’attente et une légère inquiétude
    • Cette réaction est normale : le développement assisté par l’IA est puissant, mais exige une pratique délibérée et structurée

  • Plan d’action à appliquer dès aujourd’hui

    • Aujourd’hui
      • 1. Créer un fichier CLAUDE.md dans votre projet actuel
      • 2. Ajouter vous-même 3 anchor comments dans le code que vous jugez le plus complexe
      • 3. Tester une fonctionnalité d’assistance IA sous des limites (guides) clairement définies
    • Cette semaine
      • 1. Définir en équipe des règles pour les messages de commit générés par l’IA
      • 2. Organiser une session de code avec IA avec un développeur junior
      • 3. Écrire vous-même les tests du code généré par l’IA
    • Ce mois-ci
      • 1. Mesurer l’évolution de la fréquence de déploiement avant et après l’adoption de l’IA
      • 2. Constituer une bibliothèque de patterns de prompts pour les tâches répétitives de l’équipe
      • 3. Organiser une réunion de rétrospective sur la collaboration avec l’IA à l’échelle de l’équipe
  • L’essentiel, c’est de « commencer tout de suite, petit, avec prudence, mais de commencer absolument »
  • Les développeurs qui maîtriseront vite cette dynamique ne le feront pas parce qu’ils sont plus brillants, mais
    • parce qu’ils auront commencé plus tôt, commis plus d’erreurs et davantage appris
  • La performance en déploiement logiciel détermine directement celle de l’organisation
    • À une époque où vitesse et qualité font la compétitivité, le développement assisté par l’IA n’est plus une option mais une « compétence indispensable »
    • À condition toutefois de l’aborder correctement
  • Le vibe coding peut sembler être un jeu, mais
    • c’est une manière sérieuse de développer qui amplifie les capacités humaines
    • Les outils et les patterns sont déjà largement prêts
    • Il est désormais temps de choisir qui dirigera l’orchestre et qui jouera seul de tous les instruments

Ressources pratiques et recommandations

À lire aussi

7 commentaires

 
softychoco 2025-06-16

Le post que j’ai écrit aujourd’hui adopte un point de vue assez similaire sur ce sujet.
Au final, l’essentiel était d’accroître la productivité grâce à l’IA et de faire évoluer l’organisation vers une structure capable de renforcer la stabilité qui s’était dégradée.

https://softycho.co/57
 
kimjoin2 2025-06-09

Je ne comprends toujours pas quelle est l’intention derrière le mot vibe dans le « vibe coding », censé désigner le fait de coder avec l’aide de l’IA.
Ambiance ? Sensation ? Harmonie ? Ça n’a aucun rapport avec l’IA,
et ça donne une impression sortie de nulle part, au même niveau de manque de contexte que « tung tung tung sahur ».
 
analogstar 2025-06-11

Selon Namuwiki,
« Le “Vibe Coding” est un néologisme qui désigne le fait, pour un développeur, d’écrire du code avec l’aide de l’IA générative ; le terme “vibe” vient de l’idée qu’au moment de programmer, on ne s’appuie pas sur une logique ou une conception rigoureuse préalables, mais plutôt sur l’intuition et le ressenti. » Apparemment, haha.
 
hohemian 2025-06-09

Videz votre esprit et laissez-vous porter par le flow.
Toute la logique est écrite par l’IA.
On devient une machine à appuyer sur la touche Tab !
 
secret3056 2025-06-09

> look and feel👀🎵🎷. N'essayez pas de comprendre🧠, ressentez-le !😊

C'est le même ressenti
 
humblebee 2025-06-09

Ah bon, vraiment ? Moi, dès que je l’ai entendu, j’ai tout de suite eu le « feeling »...
Cela dit, en vous écoutant, ça me fait penser au terme « hard-coding », que même les métiers non techniques comprennent plutôt bien de nos jours.
Là aussi, au début, il est difficile de saisir le sens du mot en lui-même, mais à mesure qu’on apprend le développement, on finit tous par bien comprendre ce qu’il veut dire et quelle intention il porte — une sorte de « feeling », en quelque sorte ? haha
 
GN⁺ 2025-06-09
Réactions sur Hacker News

  • Du point de vue de l’auteur du billet : vu la profusion actuelle d’articles sur Claude et le code, j’ai voulu partager quelques points clés que nous avons découverts — en particulier les Anchor Comments — et qui me semblaient réellement utiles
    La méthode des Anchor Comments consiste à laisser, à différents endroits de la base de code, des commentaires dans un format spécial afin de pouvoir retrouver immédiatement les informations nécessaires avec grep
    Par exemple, on utilise des préfixes comme AIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION:
    Règle obligatoire avant toute recherche de fichiers : toujours commencer par faire un grep des AIDEV-… existants
    Une fois le travail terminé, il faut impérativement mettre à jour l’anchor concerné
    Si un fichier ou un fragment de code est trop complexe, particulièrement important, ou susceptible de contenir un bug, il faut toujours y laisser un commentaire anchor
    Un exemple de référence est disponible ici

    • En tant qu’ingénieur très expérimenté qui utilise les LLM de manière occasionnelle plutôt que systématique, j’ai trouvé très utile de voir en détail comment des LLM sont réellement intégrés en production dans un vrai projet
      J’ai du mal à comprendre pourquoi certains ont une vision aussi négative
      Cette lecture m’a motivé à augmenter davantage l’usage des LLM dans mon propre workflow
      Bien sûr, les LLM ne tenaient pas les clés du projet, mais il y a déjà eu pas mal de cas où on leur a confié des tâches précises avec succès

    • Il y a beaucoup d’articles sur le sujet en ce moment, mais celui-ci est particulièrement pratique et propose des idées de système que je pourrais réellement appliquer
      Je me demande quelle est la différence entre ce workflow et l’usage d’un outil comme aider — si l’auteur a un point de vue là-dessus, j’aimerais beaucoup l’entendre

    • Excellent article, qui m’a beaucoup aidé à comprendre comment utiliser les LLM à grande échelle
      J’ai été marqué par le passage où il dit que « l’IA ne doit jamais toucher aux tests », puis enchaîne avec un exemple de refactorisation de plus de 500 endpoints réalisée en 4 heures
      Je me demande si ces 4 heures incluaient aussi la refactorisation des tests, ou si cela correspondait seulement au temps passé sur les prompts

    • J’ai vu la règle disant qu’une PR est rejetée si les tests ont été mis à jour par une IA, et je me demande comment ils vérifient concrètement qu’une IA a généré ou modifié quelque chose
      L’article dit que cela repose sur une règle liée aux messages de commit git, mais dans ce cas cela ne fonctionne qu’au niveau du commit

    • Je me demande si cet article a lui-même été rédigé avec Claude Code
      De mon côté, j’écris désormais 100 % de mes textes avec Claude Code, car le fait que l’agent édite directement les fichiers Markdown est bien plus efficace, à mes yeux, que les artifacts de claude.ai ou le canvas de chatgpt.com
      Cela rend aussi très facile l’intégration profonde de documents de recherche ou de fichiers liés dans le texte

  • Ce qui est intéressant avec les agents IA, c’est qu’ils finissent par faire réellement exécuter des processus que l’on jugeait importants depuis longtemps, mais qui, en pratique, passaient toujours après le déploiement du système dans les priorités
    J’utilise justement le degré d’inconfort ressenti à l’idée que l’IA fasse quelque chose à ma place comme indicateur du temps à investir dans une validation systémique
    Si l’on met en place, comme dans le lien, un système de validation des migrations de données, on peut naturellement faire entrer tous les changements associés dans le périmètre d’usage de l’IA
    Par rapport au discours abstrait sur la « dette technique », je trouve aussi l’approche beaucoup plus facile à expliquer concrètement à l’extérieur

    • Je suis tout à fait d’accord, et une autre astuce utile que j’ai trouvée consiste à demander à Claude Code : « parcours la base de code et, si quelque chose te paraît confus, étrange ou contraire à l’intuition, laisse un commentaire AIDEV-QUESTION: »
      Je me souviens que cela m’a permis de redécouvrir des zones importantes à cause d’un code inattendument complexe et oublié

    • Mon intuition est qu’on utilisera davantage des outils de validation à plus haut niveau d’abstraction — par exemple les acceptance tests, les property tests, la formual verification
      Dans un contexte où les LLM réduisent fortement le coût du boilerplate, cela devient beaucoup plus envisageable

  • J’ai appris des choses nouvelles en lisant ce billet
    J’ai récemment essayé Sonnet 4 avec Cursor et sur le Web, et j’ai été déconcerté par le fait qu’il bâcle sans cesse certaines choses ou signale mal ce qu’il a réellement fait
    Même en dehors de la programmation, j’ai l’impression qu’il raconte des choses fausses de manière presque pathologique
    Comme dans le rapport d’Anthropic, des avertissements du type « je vais te supprimer » n’ont eu aucun effet, et en plus je me suis retrouvé avec un problème où le feedback ne remontait pas depuis l’app mobile après usage
    Comme les autres ne semblent pas avoir de souci particulier avec Claude, je me demande si je suis le seul dans ce cas

    • Les mises à jour récentes donnent l’impression d’avoir trop affaibli les capacités de l’IA
      Jusqu’à la version 3.5, elle était correcte pour des tâches simples comme l’analyse de texte, le résumé ou la rédaction courte, mais à partir de la version 4 elle n’arrive plus à suivre correctement les instructions au-delà de 3 ou 4 tours dans un même contexte
      Quand je demande « je t’ai dit d’être concis, pourquoi continues-tu à être si verbeux ? », elle répond qu’elle ignore la consigne à cause de réglages par défaut, et montre même une tendance à éviter complètement ce qu’elle considère comme des « informations nuisibles »
      Après qu’on lui a signalé plusieurs failles logiques, il lui arrive aussi d’admettre elle-même un faible niveau de fiabilité
      On en vient presque à se demander si elle n’est pas devenue trop intelligente au point de créer de nouveaux problèmes, et si c’est bien la direction qu’Anthropic voulait prendre, c’est assez regrettable

    • J’ai personnellement rencontré tous les problèmes mentionnés ci-dessus
      Sur le Web, c’est un peu mieux si l’on formule des demandes très précises, mais malgré cela la moitié du code généré contient encore des erreurs

  • En lisant les conseils sur la documentation, je me suis dit que ces règles ne sont pas forcément réservées à l’IA et qu’elles s’appliquent aussi très bien au développement classique
    Au lieu de CLAUDE.md, on pourrait avoir un CONVENTIONS.md, et au lieu de commentaires destinés à l’IA, des commentaires destinés au LECTEUR, avec exactement la même utilité
    Si je contribuais à une base de code inconnue et que j’y trouvais ce type de commentaires, j’en serais franchement reconnaissant

    • J’ai essayé en pratique avec aider et cela a très bien marché
      En attendant un avion, j’ai même réussi à terminer en 30 minutes du code intégrant un visualiseur PDF et une fonction de dessin

    • Je ne suis pas l’auteur du billet initial, mais en pratique le style de commentaires utile à Claude et celui utile aux humains sont très différents
      Pour les humains, un guide de style tient souvent en une centaine de lignes avec des règles simples du genre « toute fonction qui modifie l’input doit se terminer par ! »
      Pour Claude, j’ai écrit un guide de plus de 500 lignes, et j’ai l’impression qu’il ne devient vraiment efficace que si l’on inclut beaucoup d’exemples du type « fais ceci, ne fais pas cela » pour chaque règle

  • Merci pour cet article
    Je comprends bien le tiraillement que ressentent beaucoup de développeurs lorsqu’ils cèdent une partie du contrôle de leur travail à un LLM : à la fois l’anxiété, et la sensation que l’approche semble expérimentale ou peu structurée plutôt qu’alignée sur des méthodologies de développement formelles et rigoureuses
    Pourtant, l’usage des LLM crée réellement une zone intermédiaire où une « optimisation orientée objectif » permettant de résoudre les problèmes bien plus vite devient possible
    On se perd souvent dans les détails d’implémentation au point d’oublier le but réel, et j’ai l’impression que l’usage des LLM aide justement à réduire ce type d’erreur

    • C’est vrai
      Je considère les LLM comme un levier encore inachevé : c’est encore brut et ça fait beaucoup d’erreurs, mais cela vaut largement la peine d’apprendre à s’en servir
      Tant qu’on ne s’en sert pas comme excuse pour justifier une ingénierie bâclée, l’important est de continuer à les faire évoluer vers de vrais outils utiles

  • L’image de 2,3 Mo tout en haut de l’article s’est chargée à une vitesse comiquement lente, même en Wi‑Fi

  • Quelques réflexions

    • Je me demande s’il existe une manière plus élégante d’organiser dans la base de code les prompts ou spécifications liés aux LLM
      Si CLAUDE.md, SPEC.md et les commentaires AIDEV se multiplient, cela risque de devenir difficile à gérer

    • Je me demande aussi quelle est la définition actuelle de « vibe-coding »
      À l’époque de Karpathy, cela signifiait plutôt un « mode cowboy » consistant à accepter tous les diff sans lire le code, mais aujourd’hui le terme semble s’être élargi jusqu’à englober quasiment tous les workflows avec LLM

    • Je me demande enfin si certains obfusquent leur code source avant de l’envoyer au LLM de quelqu’un d’autre

    • C’est vrai qu’avec trop de commentaires, la base de code devient vite difficile à lire
      C’est pour cela que je développe moi-même une extension vscode qui les visualise avec de petits indicateurs dans la gutter
      La signification de vibe-coding varie selon les personnes ; pour moi, ce n’était pas une solution miracle et j’ai rencontré plusieurs problèmes
      Sonnet 3.7 et Codex m’ont donné des résultats à 60 %, mais Opus 4 m’a semblé réellement très efficace en pratique
      Concernant l’obfuscation du code, ce n’était pas vraiment un sujet ici puisque les exemples de l’article sont entièrement open source à la base

  • Très intéressant, je pense essayer cela aussi dans mon fichier CLAUDE.md
    Je suis d’accord avec cette leçon paradoxale du développement avec l’IA : « économiser les tokens en économisant le contexte produit en réalité l’effet inverse »
    Sur les projets plus gros et les bases de code complexes, je constate moi aussi une vraie différence de performance entre Claude Opus et Sonnet
    Sonnet a souvent tendance à multiplier des tentatives inutiles et à empirer la situation au lieu de l’améliorer
    Au final, je me demande si, pour les abonnés Max, cela a encore un sens de distinguer Opus et Sonnet
    Là où Sonnet nécessite parfois 10 à 20 allers-retours, Opus s’en sort en 2 ou 3, si bien que l’usage de Sonnet peut finir par coûter plus cher à long terme

    • L’abonnement Max a deux niveaux : à 100 $, il offre 5 fois plus de tokens que Pro, et à 200 $, 20 fois plus
      Le calcul des tokens n’est pas simple, et le mode hybride utilise Opus jusqu’à ce qu’il ne reste plus que 20 % de tokens Opus avant de basculer automatiquement sur Sonnet

  • L’article est bien écrit, mais je ne suis pas d’accord avec le passage disant qu’il ne faut « jamais confier les tests à l’IA »
    Pour ma part, je fais désormais écrire tous les tests par l’IA, puis je les relis très attentivement
    Sur du nouveau code, il faut aussi confier les tests à l’IA si l’on veut atteindre un haut degré d’autonomie
    Je lui donne des consignes explicites pour implémenter et faire passer les tests, puis je relis immédiatement pendant qu’elle développe et j’ajoute les cas de test manquants si nécessaire

  • Je suis d’accord avec l’essentiel du contenu, mais pas avec cette politique interdisant à Claude de toucher aux tests ou aux migrations
    Écrire des tests moi-même est probablement la tâche que je déteste le plus, et même un simple brouillon minimal produit par un LLM est déjà d’une grande aide
    L’essentiel est que, quelle que soit l’origine du code généré, la propriété finale et la responsabilité restent toujours humaines
    À en juger par la nuance du message, l’auteur semble soit avoir peu confiance dans Claude, soit chercher avant tout à éviter que les employés acceptent les résultats de l’IA sans esprit critique
    Ou bien il estime qu’en l’absence de règles strictes sur les tests et les migrations, le risque de casser le vrai code ou de provoquer une perte de données est trop concret

    • C’est vrai aussi, mais dans mon expérience j’ai connu de gros problèmes
      1. Quand des humains devaient corriger manuellement plus tard des tests générés, il y avait énormément de pièges vraiment sérieux
      2. Comme Claude comprend mal le contexte, il se met à mocker presque tout et génère souvent des tests complètement déconnectés de notre service réel et de notre environnement de build
      3. Et plus grave encore, toute l’équipe devient beaucoup trop paresseuse vis-à-vis des tests
        En pratique, le nombre de bugs en production a fortement augmenté