この2年間で、AIコーディングアシスタントは「おもちゃ」から、多くのチームにとって標準装備へと変貌を遂げた。自動補完、関数生成、さらにはモジュール全体の生成まで、数秒で完了する。しかし、コード生成がこれほど安価になった今日、あるシニアエンジニアによる告白形式の記事が、異なる視点を提示している。彼は今もコアコードを手書きし続け、AIに「代わりにやってもらう」のではなく「手伝ってもらう」方法を見つけたという。
AIの「最短経路」志向
筆者は数多くの「vibecoding」プロジェクトからひとつの法則を導き出した。AIはほぼ常に、既存コードのリファクタリングよりも新規コードの追加を好む。このやり方は「AIが私のコードベースを空にしてしまった」といった極端な事故こそ防げるものの、別の落とし穴をもたらす——アーキテクチャ上の問題を静かに未来へ先送りしてしまうのだ。
例えば、エンジニアがAIに機能の実装を依頼し、ある細部の指定を忘れたとする。AIはそれを自分で補完してしまう。重複したロジックをつなぎ合わせたり、多重のif-elseを積み上げたりすることはあっても、「この要件はインターフェースを変えない限りきれいには実装できません」と自ら指摘することはほとんどない。経験豊富なエンジニアなら、実装に着手した時点で違和感に気づき、小規模なリファクタリングで解決策がはるかに明確になることを見抜けるものだ。この判断こそ、現在のAIに最も欠けている能力である。
さらに厄介なのは、AIが生成したコードは往々にしてフォーマットが整い、コメントも完備され、見た目が美しいことだ。しかし、その奥に潜む本当の問題——アーキテクチャの歪み、冗長なコード、未処理のエッジケース——は表面の下に隠れている。コードレビューの場では、こうした欠陥は最も見落とされやすい。
guideme：「どう書くか」を「どこを直すか」へ
AIの「近視眼」に対抗するため、筆者は自分用に guideme というSKILL.mdを設計した。その動作はClaudeのLearning Modeにいくぶん似ているが、対象とするのは新人ではなくシニアエンジニアだ。
このスキルは、コピーしてそのまま貼り付けられるコードブロックを生成しない。代わりに、引き継ぎタスクのように、変更が及ぶファイル、変更すべき内容、その理由をエンジニアに伝え、関連モジュールのアーキテクチャ概要を添える。実装部分は完全にエンジニア自身に委ねられる。
- 変更範囲を明確にし、コンテキストを提供する
- 設計の動機を説明し、説教じみた基礎解説は避ける
- 手作業での実装を求め、アーキテクチャの問題を浮き彫りにする
筆者は強調する——ガイドを自らの手で実装することこそ、レビューでは見落とされていたアーキテクチャ上の近道を発見する決定的な瞬間なのだと。機械が生成したコードは「詰まる」こともなければ、ここに設計上の矛盾があると教えてくれることもない。しかし人間にはそれができる。
AIプログラミングツールの次の一歩
この事例は、AIプログラミングツールの進化にとって大きな示唆を与える。AIの価値はコード補完にとどまらず、コードへの理解をより深める手助けにもあるということだ。AIを「自動補完ツール」として使うより、「道案内役」として使うほうが良い。
チームにとっても、これは重要な気づきをもたらす。AIが生成したコードをレビューする際、表面上の整然さに惑わされてはいけない。構造が合理的か、不要な遠回りをしていないかに、より注意を払う必要がある。将来、より成熟
コメント
コメントはまだありません
最初のコメントを書きましょう