まったく同感ですし、LLM ツールは、以前は正当化できなかったかもしれない小規模なチームで、最高のチーム/組織の慣行の一部を採用するための強制的な機能になる可能性があると思います。

リンターなしで数百人のエンジニアがいるのはおかしいと思います。しかし、2つか4つしかない場合は、おそらくそのための活性化エネルギーを達成できず、コーディングスタイルについてほとんど非生産的な戦いをすることになります。 しかし、Claudeコードを追加し、a)そのリンターが必要です

b)そのリンターのセットアップは、"1人がすべてのIDEなどと統合するという古典的なターピットタスクに降りる"のに対し、5分間のわずかなリフトになります。

知らない私の聴衆の部分のために説明すると、リンターは、言語が許可するものよりも厳しいコーディング規則の標準を強制できる自動化されたツールです。たとえば、特定の法的構造は許可されないというハウスルールを採用できます

例として、多くの言語には三項演算子と呼ばれる非常に簡潔な法律表現があります。 三項演算子はバグを引き起こす可能性が高いことで有名であり、エンジニアリングチームは、簡潔ではありますが、リスク調整ベースでは、使用に許容される機能ではないと判断するかもしれません。

たとえば、Clude Code と繰り返し議論したくない linter を介して賢明に規制できるものの例として、Rails では、something_id は something テーブルの外部キーを意味します。 クロードは時々これを忘れて、他の多くのことをidと呼んでいます。

必要に応じて、コードが変更されるたびに実行されるリンタールールを記述し、Claude と他の世界にフラグを立てることができます: "変数にbox_idという名前を付けましたが、_idsはデータベースキーを参照するためにのみ使用されます。box_codeか別の名前を考えてみてください。」

リンタールールの良いところは、任意のプロジェクト固有の知識を組み込むことができることです。 日本のサラリーマンがずっと前に、大学のウェブアプリケーションを行っている(仲間の)非ネイティブスピーカーと繰り返し議論しました。

なぜ駄目なのですか。 日本の大学は学問科目を科目(京香; 「数学」のような科目)と科目(かもく; 「線形代数」のような主題)、サブジェクトはコードで読むのが恐ろしいため、これらはローマ字表記された日本語によって常に明確であると呼ばれていました。