ミリ秒のフィードバック：静的解析とコード標準

Agentが1行のコードを書く。その行が正しいかどうか、どれだけ早く知ることができるか？

答えが「テストが終わるまで待つ」なら、それは数秒から数分かかる。しかし、テストをまったく必要としない問題のクラスがある：型の不一致、未使用の変数、フォーマットの不整合、インポートの欠落。Linterと型チェッカーはコードが書かれた瞬間にこれらを検出でき、フィードバック遅延はほぼゼロに近づく。

人間のプログラマにとって、Linterはあれば便利なものだ。なくてもコードは書ける。体験が少し悪くなるだけだ。Agentにとって、Linterは最もコストの低いフィードバックチャネルだ。Agentが行うすべてのツール呼び出しはトークンを消費する。型エラーがフルテストスイートの実行後に初めて発見される場合、Agentは誤った前提に基づいて既に十数個の関数を書いているかもしれない。Linterはこれらの問題を発生源で食い止め、逸脱の生存時間を直接的に短縮する。

実際にはいくつかの設定原則が重要だ。

ルールはリポジトリに置くべきであり、個々の開発者環境に置くべきではない。.eslintrc、pyproject.toml、rustfmt.toml --- これらのファイルはリポジトリに存在しなければならない。Agentがクローンした時点で追加のセットアップなしにすぐに使えるようにするためだ。Linterの設定が開発者のIDEに散在していると、Agentはこれらの制約をまったく認識できない。

ルールは厳格だが安定しているべきだ。頻繁に変更されるLintルールはノイズを生む：あるイテレーションで通ったコードが、ルールが変わったために次のイテレーションで突然失敗し、Agentは自分のミスと環境の変化を区別できない。ルールを設定したら、Agentが作業している間は変更しない。

フォーマッタはレポートではなく自動修正すべきだ。Agentに「インデントが間違っている」と伝える必要はない。prettier --writeやgofmtで直接フォーマットを修正させる。フォーマットを「フィードバック」から「自動修復」に変えることで、不要なイテレーションサイクルを排除する。

最後に、Agent時代において静的解析の価値は微妙にシフトしている。かつてのコードスタイルに関する議論（タブ vs スペース、命名規則、行の長さの制限）は、主に人間の可読性に関するものだった。コードがAgentによって生成されAgentによって消費される割合が増えるにつれ、「コードが人間にとって美しいか」という次元の重要性は下がり、「コードがマシンにとって一貫しているか」という次元の重要性が上がる。高凝集・低結合のような構造原則は依然として重要だが、命名スタイルに関する美的ルールは、個々の人間の読者の好みよりもコードベースの一貫性に寄与するものとなる。