りくとん(Ricton)

コードレビューでトークンを燃やすのはもうやめよう、という記事 swizec.com/blog/stop-burning… ・人間とAIエージェントが安全かつ迅速にコードをリリースするための仕組みを模索した結果、結局カスタムリンターが最適だとわかった ・開発チームが生産するコード量はかつてないほど増えているが、検証プロセスがボトルネックになるため、コードを検証する速度を超えてリリースすることはできない ・粗悪なコードを大量に生み出すツールからシステムを守ることは、アーキテクトやプリンシパルエンジニアの最も重要な役割である ・人間とAIエージェントの双方に、高速で低コストなガードレールとフィードバックループを適用する必要がある ・チーム全体で週に数千件ものプルリクエストを作成するようになり、コードレビューの負担から開発者が疲弊するようになった ・CursorのBugBotというレビュー支援ツールを導入したが、重要ではないエッジケースを指摘したり、存在しないセキュリティの懸念に過剰反応したりすることが多かった ・BugBotの運用には週に約1000ドルの費用がかかる一方で、チームが大切にしているコード構造のガイドラインを全くチェックできず、かえって経験の浅いエンジニアが複雑なコードを書くようになってしまった ・そこでClaudeを使ってチーム専用のコードレビュー機能を構築し、個人のマシンで動かしたところ非常にうまく機能した ・しかし、その機能をGitHub Actions上で稼働させたところ、ノイズが多すぎてコードを読むよりもAIのコメントをレビューすることに時間を取られるようになり、1日で1000ドルのコストを突破したため即座に中止した ・AIが指摘したチーム独自のルール自体は有益だったため、高価なトークンを消費せずに同じようなチェックを高速かつ安価に実行する手段としてリンターに着目した ・リンターはコードの構文を数秒で解析してルールに沿った提案ができるため、LLMほどの高度な判断力はなくても費用対効果のバランスが最も優れている ・AIエージェントのFableに設計ガイドラインであるDESIGN.mdなどを読み込ませ、決定論的な部分を自動的にリンターのルールへと変換させた ・これにより、生のカラーコードの直接指定を禁止するno-raw-colorのルールや、ShadCNとBaseUIというデザインシステムの混在を防ぐチェックを容易に構築した ・さらに他のマークダウンファイルを読み込ませることで、不適切なログ記録を防ぐno-interpolated-consoleや、JSX関数のReactコンポーネント化を強制するno-render-helpersなどのカスタムルールを数多く作成した ・また、テストでの過剰なモック使用を避けるcheck_no_mockや、テスト名にアクター、アクション、エフェクトを明記させるcheck_test_namesなども構築した ・さらに、ドキュメント校正ツールのValeをベースにしたvale-de-blabというルールを作成し、コード内のコメントや仕様書から冗長な表現や受動態、AI特有の不自然な言い回しを検知して自動修正するようにした ・AIによるレビューはコメントが投稿されるまでに10分から30分かかるため、開発者がすでに別の作業へと移ってしまい、結果的にレビュー作業全体の負荷を増やしていた ・それに対して、リンターはもっとも遅いものでも27秒でチェックを終えてGitHubにコメントを投稿できるため、迅速に内容を確認して処理できる ・リンターは開発者のエディタ上でもリアルタイムにエラー箇所を波線で示せるため、コードを書いたその場で問題を修正してシフトレフト開発を実践できる ・さらに、コミット前のフックとして設定しておけば、開発を担当するAIエージェントがルール違反のあるコードを送信する前に、エラーを検知して自ら修正してコミットを再試行するようになる ・リンター自体は昔からある技術だが、AIを使うことで各チーム独自のカスタムルールを極めて簡単に作成できるようになった