Claude Code d'Anthropic comparé à un développeur junior : 5 règles pour la production

Claude Code peut donner à un développeur isolé le rythme d'une petite équipe, mais en production il ne fonctionne que sous un contrôle strict. C'est la conclusion de l'auteur d'un retour d'expérience qui a monté en un mois un système d'analyse régulière des prix et des offres produits de concurrents. D'après lui, le modèle se comporte comme un junior plein d'initiative : il écrit beaucoup de code vite, propose des solutions non triviales et ne discute pas, mais perd facilement le contexte d'une session à l'autre et, sans discipline extérieure, se met à réinventer l'architecture, à briser les frontières entre modules et à introduire des changements incohérents.

Le projet ne ressemble pas à une démo, mais à un système complet en fonctionnement. Il compte déjà environ 25 sources sur différents moteurs, des sites statiques aux applications SPA, et l'auteur prévoit d'en atteindre environ 60 d'ici la fin de l'année. Le jeu de données actuel contient environ 6000 fiches produit, et l'échantillon complet devrait en compter environ 15 000.

Le développement s'est appuyé sur SQLite et PostgreSQL. Le parsing combine requests, BeautifulSoup, lxml et Playwright, avec une approche API-first là où les données peuvent être récupérées directement. Par-dessus, une couche analytique assure le benchmark de prix, le gap analysis et la comparaison des caractéristiques produits, et le matching se déroule en plusieurs étapes : pré-filtre, embeddings et LLM-as-judge pour les cas limites.

L'auteur souligne qu'un tel volume exige non seulement de la vitesse d'écriture, mais aussi de la discipline d'ingénierie. C'est pourquoi le texte s'articule autour de cinq règles de contrôle.

Première règle : du TDD avant la première ligne d'implémentation. Sans tests écrits à l'avance, le modèle risque de produire non pas ce qui est demandé, mais seulement ce qui paraît plausible.

Deuxième règle : la documentation comme mémoire externe, car un nouveau chat revient en pratique à un nouvel employé qui ignore les décisions passées. Le projet a utilisé des documents d'architecture distincts, un journal de décisions de plusieurs milliers d'entrées, des descriptions de pipelines et des plans de sprint.

Troisième règle : des contrôles de régression obligatoires sur des golden data, afin de comparer après chaque modification la qualité du matching sur des paires de référence et de ne pas laisser passer une dégradation silencieuse.

Quatrième règle : une revue de code manuelle sans indulgence au motif que le code a été généré vite. Si l'humain ne comprend pas pourquoi la solution est conçue ainsi, elle ne doit pas être fusionnée.

Cinquième règle : des limites fermes à l'initiative dans les prompts, pour que le modèle ne se mette pas à refactoriser des modules voisins, à changer des interfaces ou à ajouter de la logique superflue sous couvert d'amélioration.

Le texte relate aussi un épisode technique révélateur. En optimisant le matching, Claude Code a parallélisé le travail avec `sqlite3.Connection` via `ThreadPoolExecutor`, ce qui a accéléré le traitement mais provoqué des plantages sous charge sur macOS. Le problème n'a été repéré que grâce à une relecture attentive et à des tests de charge, et il a été corrigé en passant à une connexion distincte par thread via `threading.local()`. Le système est ensuite resté stable, avec un gain de performance de plusieurs fois. L'exemple compte moins pour lui-même que comme illustration de l'idée centrale : le modèle peut proposer une solution qui semble fonctionner mais qui porte en réalité un risque caché pour la production.

L'auteur trace également les limites de l'approche. Selon lui, un ingénieur expérimenté qui maîtrise bien l'architecture peut effectivement, avec Claude Code, travailler comme deux ou trois personnes, surtout sur le parsing, les automatisations et les systèmes internes appliqués. Mais une personne sans solide bagage obtiendra probablement seulement un MVP qui se fait passer pour de la production : les tests seront écrits pour le code actuel, la documentation deviendra vite obsolète et le coût de maintenance commencera à grimper en quelques semaines.

La conclusion principale pour le marché est simple : les outils d'IA n'abolissent pas le développement senior, ils en relèvent les exigences. Claude Code accélère l'implémentation, mais il ne prend pas en charge la responsabilité de l'architecture, de la qualité et de la longévité du système. Plus un produit doit durer, plus la mémoire externe, les garde-fous de régression et le contrôle d'ingénierie manuel comptent. Sans eux, on n'obtient pas un système de production mature, mais seulement l'impression convaincante qu'il est prêt pour une exploitation de longue durée.