Je suis tout à fait d'accord, et je pense que les outils LLM pourraient être un moteur pour adopter certaines des pratiques des meilleures équipes/organisations au sein d'équipes plus petites qui n'auraient peut-être pas pu les justifier auparavant.

Je pense que vous seriez fou d'avoir plusieurs centaines d'ingénieurs sans linter. Si vous n'en avez que deux ou quatre, cependant, peut-être que vous n'atteindrez jamais l'énergie d'activation pour cela, et que vous aurez principalement des disputes non productives sur le style de codage. Mais ajoutez Claude Code et a) vous voulez ce linter.

b) mettre en place ce linter nécessite maintenant cinq minutes d'effort marginal par rapport à "Une personne descend dans une tâche classique de tarpit pour l'intégrer avec tous les IDE/etc."

Pour la partie de mon audience qui ne le sait pas : un linter est un outil automatisé qui peut faire respecter des normes de convention de codage qui sont plus strictes que celles qu'un langage pourrait permettre. Par exemple, vous pouvez adopter une règle interne selon laquelle certaines constructions légales ne sont pas autorisées.

Par exemple, il existe une expression juridique très concise dans de nombreuses langues appelée opérateur ternaire. Les opérateurs ternaires sont notoirement susceptibles de provoquer des bogues, et une équipe d'ingénierie pourrait décider que, bien que concis, sur une base ajustée au risque, ils ne sont pas une fonctionnalité acceptable à utiliser.

Comme exemple d'une chose que vous pouvez réglementer de manière sensée via un linter et pour laquelle vous ne voulez pas avoir à avoir des arguments répétés avec Claude Code : dans Rails, something_id signifie une clé étrangère pour la table something. Claude oublie cela occasionnellement, appelant beaucoup d'autres choses des ids.

Vous pouvez, si vous le souhaitez, écrire une règle de linter qui s'exécutera chaque fois que le code est modifié et signalera à Claude et au reste du monde : « Vous avez nommé une variable box_id, mais les _ids ne doivent être utilisés que pour faire référence aux clés de la base de données. Envisagez box_code ou un autre nom. »

Une chose agréable à propos des règles de linter, c'est qu'elles peuvent avoir des connaissances spécifiques au projet intégrées. Un argument répété qu'un salaryman japonais a été contraint d'avoir il y a longtemps, avec des (camarades) non-natifs réalisant une application web universitaire : vous NE DEVEZ PAS utiliser "sujet."

Pourquoi pas ? Parce que les universités japonaises divisent les matières académiques en 教科 (kyouka ; une matière comme "mathématiques") et 科目 (kamoku ; une matière comme "algèbre linéaire"), et comme le terme sous-matière est épouvantable à lire dans le code, ceux-ci étaient désignés par des termes romanisés japonais pour être toujours sans ambiguïté.