AIのコードは全部読むな、リスクを読め
AIが書いたコードを全部読むのはもう難しい
AIが書いたコードを、人間は全部読むべきか。
最近、そんな議論をよく見かける。読まないなんて無責任だ、という声もある。気持ちは分かる。
自分はここ２か月ほど、AIが書いたコードをほとんど読んでいない。
もちろん、責任を放棄しているわけではない。
むしろ責任を取るために、全部を読むやり方をやめた。
FastAPIやRailsのバックエンド、Next.jsのフロントエンド、API設計、モバイルアプリ、リファクタリングまで、かなりの部分をAIに任せている。
出てきた差分を、上から下まで目で追うことは、もうしていない。
理由は単純だ。
読んでいると、AIのアウトプット速度に追いつかない。
こう書くと、コードを見ていない人に見えるかもしれない。
でも、そうではない。
正確に言えば、全部は読まない。
必要なところだけ見る。
そして最近感じているのは、その「必要なところ」を見極める仕事のほうが、以前より重くなっている、ということだ。
レビューの対象が、変わってきている。
コードの全行から、計画や前提、リスク、責任の範囲へと移っている。
人間のチームでも責任者は全部読んでいなかった
考えてみれば、これは新しい話ではない。
人間だけで開発していた頃も、責任者がメンバー全員のコードを全部読むということはしていなかった。
５人のチームがあったとする。５人がそれぞれコードを書く。そこで責任者が１人で全員分のコードを読もうとすると、その人がボトルネックになる。レビュー待ちで全体が止まる。
だから、相互にレビューさせる。お互いのコードを見てもらう。
そのうえで、朝会で報告してもらう。昨日は何を作ったか。何をレビューしたか。
自分が見ていたのは、コードそのものではなかった。
誰が、何を作り、誰が、何をレビューしたのか。
その流れだ。
報告を聞きながら、引っかかるところだけを拾う。ここは少し怪しいな、と感じた箇所だけ、深く聞く。場合によっては、自分でコードを開く。
つまり、全部は読まない。流れの中に危ない匂いがないかを見て、引っかかったところだけを見る。
今AIに対してやっていることも、構造としてはこれに近い。
違うのは、相手が人間ではなくAIであること。
そして、出てくる量と速度が、人間のチームとは比較にならないことだ。
勘や嗅覚の正体はリスクの事前想定である
「危ない匂い」と書いたが、これを勘とか嗅覚とか呼ぶと、少し精神論に聞こえる。
でも実際は、もっと地味なものだと思っている。
経験から作られた、リスクの事前想定だ。
何を作るかを決める時点で、自分の中ではもう、いくつかの旗が立っている。
ここは仕様が曖昧になりそうだ。ここは既存の機能と衝突しそうだ。ここは権限まわりで事故りそうだ。ここはデータの更新範囲が広くて、影響が読みにくい。ここはテストが通っても、本番で壊れそうだ。ここはリファクタリングで、暗黙の仕様を消してしまいそうだ。
この感覚は、きれいな設計論から出てくるものではない。過去に、自分で壊した場所から出てくる。本番で想定外のデータが入り、なぜそこが壊れたのかを夜中まで追いかけた、その記憶から出てくる。
だからレビューは、コードが出てきてから始まるものではない。
何を作るかを考えている時点で、レビューはもう始まっている。
これは、コードを書く力とは別の力だ。
どこが壊れやすいかを、作る前に見当をつける力だ。
そして、この力は今はまだAIに丸ごと渡せない。
AIは指示された範囲をきれいにこなすが、「この機能はそもそも事故りやすい」という勘所は、こちらが持っておく必要がある。
なぜなら、事故が起きたときに責任を取るのはAIではないからだ。
AIは５人、１０人分のアウトプットを出してくる
人間のチームの話に戻る。
５人のチームなら、出てくるコードの量は５人分だ。責任者はその流れを追えばよかった。
ところが、AIは違う。
以前なら、自分で実装方針を考え、コードを書き、テストを書き、レビューで指摘されたところを直していた。
今は違う。
AIに実装方針を出させる。
そのままRails側の変更をさせる。
APIの仕様を直させる。
Next.js側の表示も直させる。
テストを書かせる。
最後に、その変更をAI自身にレビューさせる。
一つの流れの中に、実装者、レビュアー、テスターの役割が混ざっている。１人のAIというより、５人、１０人分のアウトプットが、短い時間で出てくる。
この量を相手に、人間が全部のコードを読む運用は、もう成り立たない。読むことにこだわるほど、人間の側がボトルネックになる。
だから、流れをこう組み替えている。
AIに計画を立てさせる。
AIに実装させる。
AIにレビューさせる。
AIにリスクを並べさせる。
AIに改善案を出させる。
そして人間は、その上に立ってレビューする。
AIの品質は、これまでチームにいた若手や中堅と、同程度かそれ以上にはなっている。
そして、これからもますます良くなっていくだろう。
部下のように使う、と言うと少し雑だが、感覚としては近い。AIを実装する側として使うなら、人間の側には、責任者としての視点が要る。
AIにレビューさせるというと、責任をAIに渡しているように聞こえるかもしれない。
でも、自分の感覚は逆だ。
AIにレビューさせるのは、責任を渡すためではない。自分が見るべき場所を絞るためだ。
人間のチームでも、相互レビューをさせるのは、責任者が楽をするためではなかった。
リスクを分散し、見落としを減らし、最後に責任者が判断するためだった。
実装の速度が上がるほど、実装そのものではなく、その手前と、その後ろを見る仕事が増えていく。
それでも人間が見るべき場所はある
ここを誤解されたくない。
全部は読まない、という話は、コードを読まなくていい、という話ではない。
むしろ逆で、全部読まないからこそ、どこを読むかの判断が重くなる。
人間が見るべき場所は、はっきりしている。
いつまでも直らないバグ。権限と認可。金額の計算。データの更新。外部との連携。既存の仕様との境界。リファクタリングで責務が変わる部分。
たとえば、いつまでも直らないバグ。
AIに修正させても、同じようなバグが何度も残ることがある。一見すると、AIの実装力が低いように見える。
でも、責任者として見るべきはそこではない。
いつまでも直らないバグは、たいていコードの一部だけの問題ではない。仕様の前提を誤解している。データ構造の理解が浅い。既存コードの責務分担を読み違えている。リファクタリングで、消してはいけない暗黙の仕様を壊している。
こういうとき、差分を上から読むだけでは、原因に届かない。
むしろAIに聞く。
このバグの原因を、実装ミスではなく、設計やデータの流れ、責務の分け方の観点で説明して、と。今の修正方針で直らない可能性がある前提を、三つ挙げて、と。
問い方が、嗅覚の中身になる。
そしてもう一つ。AIに何度か質問しても、説明がぼやける場所がある。
そこは、コードを見る。
なぜなら、そこは実装の巧拙ではなく、事故になったときに責任を問われる場所だからだ。
権限まわりが、まさにそれだ。RailsとNext.jsとAPIが絡むと、権限のチェックが何か所にも散らばる。Railsのモデルやポリシー、APIの処理、データを更新する箇所、データを取得するときの絞り込み、そしてNext.js側の表示制御。
AIが「画面上でボタンを非表示にしました」と言っても、それでは足りない。
UIで隠しているだけなのか。それとも、サーバー側できちんと拒否しているのか。画面に出ていなくても、APIは叩けてしまう、という穴が一番こわい。
AIに聞いても、認可と表示制御を混同したまま、曖昧な答えが返ってくることがある。そのときは、人間がソースを開く。
全部を読む必要はない。でも、ここを読まないなら、責任者とは言えない。
これからのエンジニアにはPM的なリスク判断が必要になる
ここまで書いてきて思うのは、これからのエンジニアに必要なのは、コードを全部読む根性ではない、ということだ。
AIが実装をこなせるようになるほど、人間の側に求められるのはPMに近い力になっていく。
それは、進捗を管理する力だけではない。
何を作るべきかを決める。どこにリスクがあるかを考える。何をAIに任せ、何を人間が見るのかを決める。そして最後に、責任を取る。
この一連の判断だ。
考えてみれば、PMや経営者は、人間のチームに対して、ずっとこれをやってきた。全員の全作業を把握していたわけではない。リスクを見て、問いを立て、責任を引き受けてきた。
AIの時代になって変わったのは、その相手が人間からAIに変わったことだけかもしれない。
だから、これからのエンジニアに必要なのは、コードを全部読む力ではない。
AIというチームをどう動かし、どこで止め、どこに責任を持つかを、判断する力だ。
読む量は、きっとこれからも減っていく。
そして、どこを読むかを決める仕事だけが残る。
その判断を間違えたときの責任だけは、これからも人間の側に残る。
