Première tentative : 95 % de déchets — le parcours d’un Staff Engineer avec Claude Code

 (sanity.io)
24 points par GN⁺ 2025-09-03 | 5 commentaires | Partager sur WhatsApp
  • Un Staff Engineer partage son expérience d’une expérimentation de 6 semaines d’un workflow de développement avec l’IA en utilisant Claude Code
  • Considérer l’IA comme un « développeur junior qui n’apprend pas » est la clé d’une intégration réussie
  • Les premières tentatives sont en grande partie des échecs à 95 %, mais des itérations successives permettent progressivement d’aboutir à un code utile
  • Le recours à des fichiers de contexte par projet (Claude.md) et à une intégration d’outils basée sur MCP permet de résoudre le manque de contexte de l’IA
  • Le rôle du développeur se déplace de l’écriture du code vers la résolution de problèmes et la conception d’architecture, un nouveau modèle de productivité à l’ère de l’IA

Contexte et approche

  • L’auteur écrivait autrefois tout son code lui-même, mais récemment 80 % du code est écrit par l’IA, tandis qu’il se concentre sur l’architecture, la revue et la gestion du développement multithread
  • Cet article n’adopte pas un ton naïvement enthousiaste sur le thème « l’IA mène la révolution », mais partage la confusion et les méthodes réalistes rencontrées lors de l’intégration de l’IA dans un véritable workflow de développement en production
  • Traiter l’IA comme un « développeur junior qui n’apprend pas » est au cœur d’un usage réussi

Évolution du paradigme de développement

  • Pendant les 5 premières années, l’auteur a conservé une manière de développer fondée sur les livres et la documentation des SDK
  • Puis, pendant 12 ans, il est passé à l’exploitation de la connaissance collective via la recherche (Google)
  • Au cours des 18 derniers mois, il a expérimenté le coding assisté par IA avec Cursor
  • Et durant les 6 semaines précédant cet article, il a vécu un changement brutal avec une délégation globale à l’IA via Claude Code
  • L’adaptation à Claude Code a produit un gain de productivité perceptible en seulement quelques heures

Workflow réel de production basé sur l’IA

  • Pour le code destiné à la production, l’IA est surtout utilisée pour « réfléchir »
  • Générer un code parfait en une seule fois est impossible. La mission de l’ingénieur est de trouver la meilleure solution à un problème
    • Première tentative (95 % d’échec) : l’IA accumule le contexte du système et le développeur clarifie le problème, mais le code est presque entièrement faux
    • Deuxième tentative (50 % d’échec) : la compréhension du contexte s’améliore et l’approche se précise, mais la moitié du résultat reste inutilisable
    • Troisième tentative (code exploitable) : grâce à l’itération et à la revue, une base de code réellement utilisable apparaît, puis peut être améliorée
  • Ce processus n’est pas un échec, mais une série volontaire d’expérimentations et d’optimisations itératives

Le problème du contexte et ses solutions

  • L’IA ne peut pas conserver de mémoire d’une session à l’autre, ce qui impose de répéter les mêmes explications à chaque fois
  • Comme solution, l’auteur utilise un fichier Claude.md pour consigner les décisions d’architecture, les patterns et les liens vers la documentation
  • Grâce à l’intégration MCP, l’IA peut être reliée à Linear, Notion, GitHub, la codebase et la base de données afin de recevoir automatiquement le contexte
    • Linear fournit le contexte des tickets
    • Notion ou Canvas donnent accès à la documentation
    • Une base de données hors production permet de vérifier la structure des données
    • GitHub fournit le contexte historique via les PR passées

Utilisation parallèle d’instances Claude et stratégies clés

  • En faisant tourner plusieurs instances de Claude en parallèle, l’auteur a l’impression de gérer « une petite équipe de développeurs qui perd la mémoire tous les jours »
  • Il met en place des stratégies comme interdire la parallélisation sur une même zone de problème, consigner tout le travail dans des outils de gestion de projet comme Linear, et indiquer clairement le code modifié directement par un humain
  • L’IA est activement utilisée non seulement pour écrire du code, mais aussi pour la code review : détection rapide des tests manquants, des bugs évidents et des points d’amélioration, ce qui réduit le travail répétitif
  • Selon la politique de son entreprise (Sanity), la responsabilité finale de la qualité revient à l’ingénieur, même pour du code généré par l’IA
  • Dans un environnement où le code généré par l’IA et celui des humains deviennent indiscernables, il est possible de faire des revues de code plus critiques et plus objectives, avec moins d’attachement émotionnel

Processus de revue de code en 3 étapes

  • Écrire du code n’est qu’une partie du travail, et la revue de code en est une autre
  • 1re revue : revue initiale par Claude
    • Détection des manques de couverture de tests et des bugs évidents
    • Les suggestions d’amélioration font gagner du temps lors des revues par les collègues
  • 2e revue : ma revue
    • Vérification de la maintenabilité, de l’architecture, de la logique métier et de l’intégration
    • Même pour du code généré par l’IA, la responsabilité finale incombe à l’ingénieur
  • 3e revue : revue habituelle de l’équipe
    • L’équipe ne sait pas quelles parties ont été générées par l’IA. Les mêmes standards de qualité s’appliquent
    • Une revue objective est possible sans attachement émotionnel
  • Le moindre attachement émotionnel au code écrit par l’IA permet des revues plus objectives

Agent déclenché par Slack et expérimentations d’automatisation du travail

  • Un agent relié à Slack avec Cursor a été testé en pilote : succès sur de simples modifications de logique métier, échec sur des mises en page CSS complexes
  • À ce stade, il existe encore des limites : absence de prise en charge des packages NPM privés, commits non signés, contournement du suivi officiel, etc.
  • Malgré cela, l’idée qu’un agent puisse traiter la nuit des tickets simples et répétitifs reste prometteuse

Coûts et ROI

  • Le coût d’utilisation de Claude Code représente une somme non négligeable versée par l’entreprise pour ses ingénieurs
  • Mais cet investissement apporte des gains de productivité
    • Vitesse de livraison des fonctionnalités multipliée par 2 à 3
    • Gestion simultanée de plusieurs fils de développement
    • Fin de l’écriture manuelle du code répétitif ou boilerplate
  • Au début de l’adoption de l’IA, il faut prévoir un budget mensuel de 1 000 à 1 500 $ pour un ingénieur senior, avec l’espoir d’une meilleure efficacité économique à mesure que l’expertise progresse

Problèmes persistants et limites du développement assisté par IA

  • Problème d’apprentissage : l’IA n’apprend pas de ses erreurs et répète les mêmes malentendus ; la solution consiste à enrichir la documentation et à renforcer les consignes explicites
  • Problème de confiance : l’IA peut proposer du code erroné avec assurance, d’où la nécessité absolue de le vérifier, surtout dans les zones complexes de gestion d’état, de performance ou de sécurité
  • Limite de contexte : les grandes codebases dépassent la fenêtre de contexte de l’IA ; il est donc indispensable de découper les problèmes en petites unités et de fournir un contexte clair

Du code vers le problème : un changement émotionnel

  • Il faut abandonner l’attachement au code et adopter une pensée centrée sur la résolution de problèmes
  • Supprimer rapidement le mauvais code, faire des revues plus objectives et ressentir moins de charge face au refactoring : autant de changements positifs
  • L’auteur se dit prêt à remplacer immédiatement ses outils si de meilleurs outils d’IA apparaissent
  • L’essentiel n’est pas le code en soi, mais la valeur du problème à résoudre

Conseils sur l’adoption de l’IA du point de vue de l’ingénieur

  • 1. Autoriser l’expérimentation de plusieurs solutions d’IA : l’équipe doit tester directement divers outils pour renforcer ses compétences pratiques
  • 2. Commencer par des tâches répétitives et simples : les résultats rapides sont plus probables
  • 3. Prévoir un budget pour le tâtonnement : il faut accepter une certaine confusion le premier mois
  • 4. Repenser le processus de revue : renforcer les contrôles adaptés aux spécificités du code généré par l’IA
  • 5. Documenter rigoureusement : un bon contexte démultiplie la productivité
  • Les ingénieurs qui s’adaptent à ce nouveau workflow IA découvriront qu’un nouveau couteau bien aiguisé a rejoint leur boîte à outils
  • Les ingénieurs qui adoptent ces workflows avec l’IA évolueront vers un nouveau rôle consistant à orchestrer plusieurs agents IA tout en se concentrant sur l’architecture, la revue et la résolution de problèmes complexes

Votre prochaine étape

  • Choisissez une petite fonctionnalité bien définie,
  • donnez à l’IA trois occasions de l’implémenter,
  • puis examinez le résultat comme si vous mentoriez un développeur débutant
  • C’est tout. Pas besoin de bouleversement majeur ni de refonte des processus
  • Il suffit d’une fonctionnalité, de trois tentatives et d’une revue honnête
  • L’avenir n’est pas que l’IA remplace les développeurs
    • mais que les développeurs travaillent plus vite, conçoivent de meilleures solutions et utilisent les meilleurs outils

À lire aussi

5 commentaires

 
helio 2025-09-05

« Avec une procédure aussi sophistiquée, je pense qu'il vaut mieux écrire le code soi-même. »
 
skageektp 2025-09-05

L’attitude du chef d’équipe qui ne délègue rien aux membres de l’équipe et fait le boulot lui-même, mdr
 
greenbhj 2025-09-05

On pourrait le croire, mais ce n’est absolument pas le cas.
J’ai répété des expérimentations à petite et à grande échelle au cours des six derniers mois.
 
iolothebard 2025-09-05

Choisissez une petite fonctionnalité bien définie,
donnez à l’IA trois occasions d’implémenter cette fonctionnalité,
puis examinez le résultat comme si vous mentoriez un développeur débutant
Si elle peut faire ça sans moi, c’est un « gain »… mais si elle a besoin de moi… alors autant que ce soit moi qui le fasse, c’est ça le vrai « gain ».
 
GN⁺ 2025-09-03
Avis Hacker News

  • Cela souligne l’importance de formuler les consignes en tenant compte des limites cognitives de l’agent. Par exemple, il vaut mieux ne pas demander de gros changements d’un coup, mais établir un plan puis faire exécuter de petites étapes en les testant au fur et à mesure. Pour les étapes complexes, il est utile de lui faire écrire du code qui visualise le problème et la solution. Si une étape échoue, il est efficace d’ajouter du logging au code, de sauvegarder les logs, de tester, puis d’examiner les logs pour identifier la cause, de façon itérative. Si on s’appuie sur la manière dont le code existant est conçu pour aider le modèle à repérer ce qu’il doit modifier, on peut éviter que l’IA ne mette tout dans un seul fichier. J’ai vu plusieurs blogs où des gens partageaient ce type d’astuces ; ce n’est toujours pas parfait, mais au moins on n’obtient plus 95 % de résultats inutiles.

    • J’ai déjà tout essayé de ce genre, et pourtant la plupart du temps le code produit reste inutilisable ; même quand ça fonctionne à peu près, il faut quand même retoucher soi-même pour que ce soit exploitable. Il y a bien des cas où ça marche vraiment bien, et là c’est enthousiasmant, mais personnellement je ne ressens pas de gros gain d’efficacité.
    • Sur les tâches complexes à grande échelle, j’ai l’impression qu’il est efficace de dire : « N’écrivez pas le code tout de suite. Je vais détailler chaque étape. » Par exemple en donnant une vue d’ensemble séquentielle : lecture des entrées, génération des candidats, scoring des candidats, priorisation et tri, création de la structure de données de sortie, sauvegarde en base de données, etc. Claude organise ensuite ces étapes sous forme de liste TODO et de documentation, ce qui facilite la reprise plus tard. En pratique, il m’est arrivé de travailler une heure, puis d’arrêter et de dire : « Génère le code pour les stages terminés et laisse des commentaires pour reprendre ensuite », ce qui permettait de reprendre facilement le travail.
    • Même après avoir utilisé longtemps plusieurs LLM/agents, il reste difficile d’obtenir des résultats réellement utiles. Pour éviter les sorties inutiles, il faut dépenser plus d’énergie à rédiger le prompt que si on faisait le travail soi-même ; et à force de faire attention à la formulation, au ton, et aux associations indésirables, ça finit par devenir anxiogène. J’aimerais qu’il existe un outil, un peu comme un framework frontend dédié, qui gère les prompts pour les LLM : organiser une structure de prompt générale, appliquer par défaut les bonnes pratiques, et réduire la charge mentale quand on cherche quelque chose dans le code, qu’on conçoit une nouvelle fonctionnalité ou qu’on écrit des tests.
    • Avec une procédure aussi sophistiquée, je pense qu’il vaut mieux écrire le code soi-même.
    • En testant l’IA et le vibe coding sur un projet personnel, j’ai constaté que le développement piloté par les tests se mariait assez bien avec le vibe coding. Je recommande de décomposer le problème en petites unités testables, de faire d’abord écrire les tests unitaires par l’IA, puis d’implémenter ensuite le vrai code.

  • J’ai l’impression qu’on est arrivé au moment où ce type d’articles devrait inclure des exemples concrets de tâches où « des agents travaillent réellement en distribué », et pas seulement du simple refactoring ou du boilerplate React. Apparemment, il y a chez Sanity des fonctionnalités demandées depuis longtemps, et ils affirment que les agents en traitent une bonne partie en parallèle. En revanche, j’ai du mal à croire aux affirmations du type « 80 % du code a été écrit par un développeur junior qui n’apprend rien ».

    • À mon avis, l’expression « développeur junior qui n’apprend rien » est trompeuse. Claude ressemble plutôt à un senior très diplômé qui connaît les bonnes réponses issues de la littérature mais manque d’expérience terrain. Ses connaissances encyclopédiques sont remarquables, mais son sens pratique est limité. En ce moment, je construis une codebase commerciale avec Claude, et l’essentiel de mes inputs porte sur le « goût du code » et la définition de la réussite ; le code lui-même n’est qu’un artefact jetable.
    • C’est assez ironique : alors que le volume de code produit par l’IA augmente, les issues non résolues continuent de s’accumuler dans l’open source.
    • Si on montrait des exemples concrets de tâches réellement confiées à l’IA et leurs résultats, cela permettrait de remettre en question les attentes exagérées. Mais dans la réalité, on voit surtout passer des récits disant à quel point Claude Code est formidable, sans exemples de terrain.
    • Quand je vois un blog technique d’un ingénieur devenu vendeur employer des termes comme « learnings » au lieu de « lessons », j’ai l’impression d’être sur une trajectoire inverse : avec l’expérience, je dépends de moins en moins de Google et je me contente de lire la documentation.

  • L’auteur dit avoir gagné en productivité, mais il mentionne aussi toutes les limites habituelles ; au final, j’ai eu l’impression que ça n’apportait pas grand-chose. Je suis convaincu que personne ne délègue le développement des fonctionnalités centrales à Claude Code.

  • Éviter le boilerplate fait partie du travail du développeur, et c’est aussi une abstraction qui rend service à soi-même dans le futur. Si on génère le boilerplate avec l’IA, cela peut au contraire devenir plus pénible plus tard lorsqu’il faut modifier toutes les occurrences à la main ; et si ce code boilerplate disséminé à plusieurs endroits diverge, le problème devient encore plus grave.

    • La plupart des frameworks et outils incluent déjà des générateurs automatiques de boilerplate ; je me demande donc quelle valeur il y a vraiment à demander cela à une IA en y consacrant des tokens et un coût supplémentaire.

  • Ce qui est intéressant, c’est que cette personne essaie d’utiliser l’IA pour l’implémentation de base, alors que moi je fais exactement l’inverse : je construis toujours d’abord les fondations moi-même. Cela me permet de comprendre précisément la structure et le fonctionnement, puis je ne confie à l’IA que le boilerplate répétitif. L’IA sait bien imiter, mais elle est très faible en conception d’architecture.

    • Les LLM sont très mauvais pour planifier une architecture maintenable. Ils n’arrivent pas à refactorer la structure au fur et à mesure que le code évolue, probablement à cause de leurs limites de compréhension du contexte.

  • Les salaires de base sont déjà élevés, et on voudrait en plus investir 1 000 à 1 500 dollars par mois sur des problèmes mineurs pour un gain de productivité hypothétique ; j’ai des doutes. Au minimum, mon manager n’apprécierait pas.

    • Dans le matériel, les entreprises achètent chaque année des licences d’outils EDA de toutes sortes, parfois plus chères que le coût salarial d’un développeur. Si la productivité s’améliore vraiment de façon visible, 1 000 dollars ne représentent presque rien.
    • Si les salaires des développeurs sont si élevés, alors ne pas investir devient au contraire irrationnel. Si 1 à 1,5 k$ par mois peuvent faire monter la productivité de manière certaine, hésiter serait inefficace. Dans cette optique, se focaliser uniquement sur le coût de l’IA est une vision trop simplificatrice. Et si l’IA permet de réduire le nombre de développeurs nécessaires, cela constitue aussi une économie réelle.
    • Personnellement, je dépense à peine 20 dollars par mois pour IntelliJ Pro AI, donc je me suis demandé si Claude pouvait vraiment coûter aussi cher ; après vérification, c’est effectivement possible. Quoi qu’il en soit, dans la réalité, les abonnements IA viennent désormais s’ajouter à un budget quelque part, exactement comme l’entreprise paie déjà pour une connexion internet haut débit ; le coût de l’IA devient lui aussi un poste de base.
    • Et il faut aussi se rappeler que ce prix est en réalité subventionné.
    • Je regarde avec intérêt comment les entreprises vont évoluer. Ce qui est certain, c’est que la vraie question sera finalement de savoir selon quels critères les développeurs seront évalués : si l’usage de l’IA augmente le risque d’être pénalisé en évaluation RH ou lors de licenciements, et comment prouver que la performance vient bien de soi plutôt que du LLM.

  • Je comprends mal la manière dont le MCP (Multi-Channel Processor) est utilisé dans l’article. Avec Claude Code, on peut déjà appeler quasiment tous les services tiers depuis le shell via curl, gh, etc., et le MCP peut même parfois poser problème à la place (par exemple, le serveur MCP de Linear tronque les issues quand elles sont trop longues, alors qu’en appelant directement l’API cette limite n’existe pas). Je me demande si quelque chose m’échappe.

  • Anthropic a publié une interview de Boris Cherny, le créateur de Claude Code, qui partage aussi des idées sur l’avenir du coding par agents et sur la façon de l’utiliser : https://youtu.be/iF9iV4xponk

  • En voyant la mention d’un « budget de 1 000 à 1 500 $/mois », je me suis demandé si la personne n’utilisait que des clés API sans connaître les forfaits mensuels comme claude MAX. À 100 à 200 dollars par mois, j’ai l’impression que cela couvre largement les besoins, sauf à enchaîner les requêtes sans réfléchir.

    • 1 k$ à 1,5 k$ me semblent vraiment exagérés. Même le forfait Max x20 à 200 dollars par mois couvre déjà un volume d’usage important, avec une remise à zéro toutes les 5 heures. Et malgré cela, si quelqu’un dépasse encore la limite tous les jours, il est possible qu’une facturation au token revienne de toute façon encore plus cher.

  • Si vous comptez utiliser Claude ou d’autres agents, je recommande vivement d’avoir du logging. Si vous injectez l’intégralité du fichier de logs à l’IA, vous augmentez nettement les chances qu’elle parvienne à organiser le problème, à donner une réponse utile, ou à proposer l’étape suivante. Le logging, c’est vraiment la base de tout.