2025年にはエージェントによるコーディングの台頭が見られました（どうやら「vibe coding」という用語は時代遅れになったようです）。AIアシスタントやエージェントワークフローの普及により、私たちがこれまで見たこともないようなスピードで機能が生み出されています。企業がコードベースの何パーセントを完全にAIで記述したかを自慢することは珍しくありません。
これが良いことか悪いことかはまだ分かりませんが（私は個人的には良いことだと思っています）、このコーディングスピードの向上には結果が伴います。生成される大量のコードをレビューすることは消耗し、コードレビューは急速にボトルネックになりつつあります。一部のチームやオープンソースプロジェクトは、AIによって生成されたPRを一切受け入れないという究極の選択をすることさえあります。
AIを禁止することで一息つくことはできますが、長期的には良い選択肢だとは思いません。私のお気に入りの架空の種族が言うように、「抵抗は無意味」です。この新しいレベルの生産性を生き抜くためには、機械がよりうまくやれる仕事を私たちがやるのをやめなければなりません。AIと戦うにはAIを使いましょう。しかしAIだけでなく、昔ながらの決定論的なツールも驚くほどの効果を発揮します。もしlinterが問題を検出できるなら、私はそれを見るべきではありません。もしformatterが自動的に修正できるなら、私は本当にそれを気にする必要はありません。
私の「不人気」な意見：コードを書いたのが人間かエージェントかは本当に気にしません。オープンソースにおいて、コントリビューションはゼロトラストです。コードが経験豊富なFAANGのエンジニアによって書かれたものであろうと、スリランカの高校生によって書かれたものであろうと、本当に問題ではないはずです。では、なぜAIによって書かれたかどうかを気にする必要があるのでしょうか？
理論上、人間が作成したPRはより小規模になるはずですが、この業界で20年ほど働いてきて、大規模なPRを数多く経験してきたため、大規模だったり雑なPRに対処することは新しい問題ではないと自信を持って言えます。
私はコードを額面通りに評価します。それは機能しますか？安全ですか？既知の問題を修正しますか？私たちのロードマップと一致していますか？私たちの基準に準拠していますか？
これが、本日の記事で、外部のコントリビューションを扱う時だけでなく、私自身のAI生成コードを扱う時にも、私がコードレビューにどのようにアプローチしているかについて少しお話ししたい理由です。実際、AIと一緒にコーディングすることは、AIを常にコードレビューしていることを意味するからです。
私が実際に気にしていること#
最近コードをレビューする時、私はますます高い視点を持つようになっています。ある意味、私が手動で書くコードが少なくなるほど、コードの個々の側面に気を配らなくなります。私が何らかの形でリーダーシップの役割を担ったすべてのチームで、常に言ってきたことがあります。それは「コードは使い捨てである」ということです。これが今日ほど真実になったことはありません。繰り返します。コードは使い捨てです。使い捨てではないのは、特定のコードを開発した時に得たシステム知識です。この知識は通常、ある実装から別の実装へとよく引き継がれるもの、あるいは例えばAPIのv1からv2に移行する時に残るものです。
2回目の開発がより簡単になるのは、多くのことを発見し、多くの曖昧さを減らすという成長の痛みをすでに経験しているからです。何がうまくいき、何がうまくいかなかったかを学びました。何が過剰設計で何が設計不足だったか。これがソフトウェアエンジニアリングにおいて重要な部分です。つまり、知識を集め、反復し、進化させることです。そして、これがAIの時代を生き残る種類の知識です。コードは単なる実装の詳細に過ぎません。
この哲学に基づき、私がコードレビュー時に気にしていることの非網羅的なリストを以下に示します。
アーキテクチャとシステム設計#
AIモデルは全体像を把握するのに苦労し、多くのショートカットを取る傾向もあります。私のレビュープロセスでは、ハードコードされた値や設定、問題空間の過度な単純化（AIはしばしばコーディングリクエストをプロトタイプやデモとして扱います）、そして逆説的ですが、過剰設計などの兆候を探します。また、AIモデルには、本番環境への対応が複雑さと同じであると仮定するという厄介な特徴もあります。言い換えれば、彼らはバランスと実用性に苦労します。これらは私たちが経験を通じて学ぶものであり、言葉に翻訳するのはしばしば困難です。
パブリックAPIとモジュール#
私たちが構築しているもののエルゴノミクスは重要です。パブリックAPIは、それを使わなければならない平均的な開発者にとって「しっくりくる」ものである必要があります。うまく設計されたインターフェースは直感的で、誤用しにくく、コードベースの他の部分から面倒な内部構造を隠します。私はインターフェースが堅牢で適切にスコープ設定されているかを確認し、可能な限り最小の表面積を目指します。APIが使いにくい場合、基礎となるコードがどれほどエレガントであるかは問題ではありません。コードは使いやすく、十分に文書化されていますか？パブリックAPIが優れていることの良いヒントは、テストの質が高いことです。悪いAPI設計は本質的にテストが困難です。
アルゴリズムとパターン#
LLMはしばしば問題を解決するための最も素朴で力技な方法をデフォルトにします。エージェントが、バルクインサート戦略が正しいアプローチであるのに、ネストされたループを使用し数行ごとにコミットすることで、大規模なデータ移行を実行しようとするのはよくあることです。またはコアレベルで：マップやディクショナリが正しいデータ構造である時にリストを使用する。データ構造とアルゴリズムが問題空間に実際に適合していることを確認することで、大規模なパフォーマンス低下を防ぎます。目標は、単にテストに合格するコードではなく、スケールするコードです。しかし、時期尚早の最適化は依然としてリスクです。もしよりシンプルなアプローチがわずかに遅くてもはるかに読みやすく、私たちが小規模で制限されたデータセットを扱っている場合、通常は読みやすさが勝ちます。
依存関係#
新しいパッケージはすべて、外部のリスク、潜在的なセキュリティの欠陥、そしてメンテナンスのオーバーヘッドをもたらします。アプリを小さく保つことは、攻撃対象領域を減らします。GenAI SDKや主要なWebフレームワークのようなコアツールはすぐにパスしますが、それ以外のものはすべて精査されます。少しのコピー（または再実装）は、少しの依存関係よりも優れています。コードの生成と保守が容易になればなるほど、特にそれがコードベースに新しい攻撃ベクトルを追加することを意味する場合は、再利用について心配することが少なくなります。
アンチパターンと品質の問題#
いくつか例を挙げると、エラーの無視や沈黙、副作用、グローバル状態、ミュータブルな状態、リソースリーク、使用されていない関数や変数などです。言語のイディオムも重要です。私はこれらを非常に気にしていますが、これらはgolangci-lint（Go）やruff（Python）のような静的解析（linter）を使用して自動化するのが最も簡単なもののいくつかでもあります。
テスト容易性#
テストが難しいコードは通常設計が悪く、将来の変更に抵抗します。関心事の明確な分離、クリーンな入力、そして純粋関数が理想的です。良いテストはコードが機能することを証明し、将来の変更のための安全網を提供します。UIコンポーネントや複雑なシステムの場合、私は厳格なユニットテストのカバレッジよりも実践的なテスト戦略を受け入れますが、コアロジックはカバーされていなければなりません。
各ケースはそれぞれ異なるため、すべてのプロジェクトにカバレッジ目標を追加しようとするのをやめましたが、テストされるべきものは何でもテストされていることを知る必要があります。理想的には、ハッピーパスの100%と悲しいパスの大部分ですが、すべてのコードの100%、あるいはそれに近いものを達成しようとはしません。優れたオブザーバビリティ戦略と優れたエラーメッセージがある限り、後で新しいエラーモードをテストスイートに追加できるため、成功のための準備が整っています。
ベンチマーキング#
クリティカルパスについては、パフォーマンスについての推測ではなく、実際の数値が必要です。トラフィックの多いコンポーネントに影響を与える変更については、遅いコードが本番環境に到達するのを防ぐために、明確なベンチマークが必要です。
無駄のないロギング#
ログは実用的なものでなければなりません。不要なログはクラウドの請求額を増やし、個人情報を漏洩する可能性があります。開発中の詳細なロギングは問題ありませんが、マージする前にクリーンアップする必要があります。
私が気にしないこと（ほとんど）#
私は自動化ツールに詳細を処理させるので、難しい問題に集中できます。機械ができることなら、人間がやるべきではありません。
コードの個々のすべての行#
LLMによって生成されたすべての行をレビューするのは、コンパイラや静的解析ツールの仕事です。代わりに、私はロジックと接続ポイントに焦点を当てます。
フォーマット#
Goを始めてから、フォーマットのスタイルについて議論したことはありませんが、特定の場所にはまだ存在していることを知っています。できる最善のことは、標準を設定し、linterとformatterにそれを処理させることです。標準がわかれば、コードエージェントもそれにより準拠することができます。CIパイプラインが通過すれば問題ありません。
細かい構文とコードの詳細#
問題を解決する方法はたくさんあり、特定の構文の選択を強制することは開発者の自由を制限します。ロジックが健全である限り、forループであろうとリスト内包表記であろうと気にしません。
デバッグ#
私はデバッグセッションをほとんど行いません（実際にデバッガーを使用するという厳密な意味で）。私にとってデバッグは最後の手段であり、本当にログ行であるべきだった「私はここにいる」というprint文を大量に追加することの同義語です。
何かが機能していない場合、問題をシミュレートするための新しいテストを作成します。問題を再現した後に何が起こっているのか理解できない場合、それは私のオブザーバビリティとログが不十分であることを意味するため、それらの改善に焦点を当てます。
エクスポートされていない名前#
名前が関数にローカルであったりスコープが制限されている場合、多くの関数やファイルにわたって使用されている場合よりも気にしません。私はコードをざっと読み、何かばかげているものを垣間見たら片付けるために立ち止まるかもしれませんが、それ以外はモデルが使用することに決めたもので問題ありません。
マイナーな依存関係#
メジャーなフレームワークやクライアントライブラリの依存関係ではないものです。これらはセキュリティのベースラインを満たしていれば、それほど懸念されません。ただし、セキュリティの悪用や問題のあるライセンスのチェックは依然として必須です。もし私がただ一つの「ヘルパー」関数のためだけに何かをインポートしているなら、私は100％の確率で自分のコードにその関数を再実装し、依存関係を排除します。
結論#
これは万能のプロトコルではありません。コードベースをどのように計装しているかについても、言えることはたくさんあります。コードレビューだけでは潜在的なすべての問題を検出することはできないため、私はこれまで以上にエージェントによるコーディングとともに、自動化を強く推奨します。
現代のコーディングエージェントには、モデルを制約し、より決定論的な出力を得ることができる多くの拡張パターンがあります。Agent Skills、フック、MCP tools、ポリシー、ルール… これらのツールを使用して、エージェントのスコープに明確に定義された制限を設ければ、あなたの人生はずっと楽になります。
車はブレーキがサポートする速さでしか走れません。お気に入りのコーディングエージェントのためのガードレールを学ぶことに投資し、あなたの貴重な時間を自動化できないもののレビューに使いましょう。
ハッピーコーディング！
Dani =^.^=
