AIにコードを書かせて、動いたのを確認して、マージする。この一連の流れの中で、あなたは何行「なぜこう書いたか」を自分の言葉で説明できるだろうか。
正直に数えてみてほしい。おそらく、思っているより少ない。
私はここで、あえて強く言い切りたい。自分でレビューできないコードは、書いていないのと同じだ。しかも、書いていないのと「同じ」ではすまない。むしろ質が悪い。なぜなら、そこには「書いた人間」が一人もいないからだ。バグを埋め込んだ本人も、設計判断をした本人も、責任を取れる立場の人間も、その場に存在しない。存在するのは、動くという結果だけだ。
「レビューできる」とは、行ごとに理由を言えることだ
まず言葉の定義をはっきりさせておきたい。ここで言う「レビューできる」は、構文が読めることでも、テストが通ることでもない。その行がなぜそう書かれているかを、自分の言葉で説明できることだ。
なぜこの条件分岐なのか。なぜこのデータ構造なのか。なぜここで例外を握りつぶさずに投げているのか。逆に、なぜここでは握りつぶしていいと判断したのか。こうした「なぜ」に一つずつ答えられて、はじめて「レビューした」と言える。
差分をざっと眺めて、変な名前の変数がないか、明らかなタイポがないかを確認する作業は、レビューの入り口に過ぎない。多くの現場で「レビュー」と呼ばれているものの実態が、実はこの入り口止まりになっていないか。AIが生成したコードが増えるほど、この問いは切実になる。
ここで先回りして断っておくと、これは信頼して使っているライブラリやフレームワークの内部実装まで一行残らず説明しろという話ではない。境界線は「自分が設計判断を下した部分かどうか」であり、他人が書いた基盤の中身については、なぜそれを選び、どう使うかを説明できれば十分だ。問われているのは、AIに書かせて自分のロジックとして取り込んだ部分――つまり、自分が設計判断を下したことになっている範囲――を、自分の言葉で説明できるかどうかだ。
AIが飛ばしてくれるのは「作業」ではなく「理解」
AIにコードを書かせることの本当のインパクトは、タイピングの時間を節約することではない。理解する工程そのものを、丸ごと飛ばせてしまうことにある。
人間がゼロから実装するとき、設計を考え、手を動かし、動かないところを直す過程で、いやでも中身への理解が積み上がっていく。書く行為と理解する行為は、切り離しがたく結びついていた。
AIはこの結びつきを断ち切る。プロンプトを渡せば、それらしく動くコードが数秒で返ってくる。テストも一応通る。ここで「理解」という工程を意図的に挟まなければ、何も理解しないまま、動くものだけが手元に残る。これは怠慢というより、構造的な誘惑だ。締め切りが迫っているとき、この誘惑に抗える人は多くない。
厄介なのは、理解を飛ばしても短期的には何の支障もないように見える点だ。動く。テストも通る。レビュー依頼を出しても、他の誰かが「LGTM」を付けて流れていく。理解を飛ばしたことのツケは、その場では一切可視化されない。
「動けばいいだろ」への反論
ここで当然出てくる反論がある。「結果が正しければ、理解していようがいまいが関係ないだろう」。
一理ある。ソフトウェアは動くために存在する。だが、この反論には見落としがある。壊れるのは、動かないときではない。動いていないコードは、すぐに気づかれ、すぐに直される。本当に厄介なのは、動いているように見えて、静かに間違っているときだ。
境界値の扱いが一つずれている。並行処理の前提が本番の負荷では崩れる。ある入力パターンだけ、想定外の値が黙って混入する。こうした不具合は、レビュー時のテストでは表に出ない。しばらく経ってから、しかも往々にして一番困るタイミングで顔を出す。
そしてその瞬間、レビューを飛ばして理解を積み上げてこなかった本人は、そのコードを直せない。直すためには、結局そのとき初めて、本来レビュー時にやるべきだった「理解する」という作業を、締め切りに追われながらゼロからやり直すことになる。理解を先送りにしても、消えてなくなるわけではない。ただ、一番都合の悪いタイミングに移動するだけだ。
責任を取るのは、いつも人間だけ
もう一つ、忘れられがちな事実がある。AIは責任を取らない。取りようがない。
障害が起きたとき、原因を追われ、説明を求められ、再発防止策を書かされるのは、常に人間だ。AIが「すみません、生成が間違っていました」と頭を下げることはない。AIがコードを書いたという事実は、責任の所在を一切変えない。マージボタンを押した人間だけが、その結果に責任を持つ。
これは今に始まった原則ではない。ライブラリのコードも、先輩が書いたコードも、レビューして取り込んだ以上、責任は取り込んだ側にあった。AIはこの原則に例外を作らない。むしろ、生成の速さゆえに、この原則を忘れやすくしている。書いた実感がないコードに、無自覚に自分の名前で責任を負わされている、と言ってもいい。
実践ルール:説明できないコードはマージしない
ここまでの立場から導かれる結論はシンプルだ。説明できないコードはマージしない。これを、AIを使うかどうかに関係のない、自分の中の一律のルールにする。
具体的には、AIが出したコードに対して、必ず「なぜこの実装にしたのか」を自分で説明させてみる。他のやり方ではなく、この書き方を選んだ理由。エッジケースをどう扱っているか。この設計が壊れるとしたら、どこから壊れるか。AIに聞いてもいいし、自分の頭の中で言語化してもいい。腑に落ちなければ、書き直す。動いているからという理由だけで、その違和感を飲み込まない。
面倒に感じるかもしれない。だが、これは新しい負担ではなく、もともと人間が書いていた時代からずっと払っていたコストを、後払いにするか前払いにするかの違いでしかない。前払いした理解は資産として残り、後払いにした理解は、いつか利子付きで請求書が届く。
最後に、自分自身への問いを一つ置いておきたい。今週マージした行のうち、理解を飛ばしたまま通した行はどれくらいあっただろうか。数える気になれないなら、それがすでに答えだ。
AIが書いたコードを、自分の言葉で説明できる側に立ち続けたいなら、判断の土台になる技術書は手元に置いておきたい。tasklogでは、Qiita・Zennで実際に開発者から言及・引用された回数をもとに、いま読まれている技術書をランキングしている。