カレーの恩返し

おいしいのでオススメ。

理解をどこまで手放すかは、リスク許容度と仕組みで決まる

最近「理解負債」とか「認知的負債」みたいな言葉をよく見かける。AI にコードを書かせても理解は手放すな、という記事もよく流れてくる。かと思えば、DHH が AI に Rust でコードを書かせているが1行も読んでないと楽しげに話していたりする。

色々目にして自分も何か書きたくなったので、今どう考えているかを書いておく。来年くらいに答え合わせができるといいな。

理解を手放すなという話は気持ちはわかる

説明できないコードを出すのは怖い。理解してないと検証もできないし、触るのも怖くなる。それはわかる。

ただ、人間の理解と短期的な開発速度が明らかにトレードオフになっているのは、最近 AI エージェントを触っている人ならまず反論しないんじゃないかと思う。ちゃんと理解しようとするほど、エージェントの速さを捨てることになる。

なので、全部理解しようとするのはさすがにもう無理じゃない?とも思っている。無理というか、経済合理性を説明できない気がする。エージェントがコードを書くのにかかった時間の何倍もかけて、コードを理解するのって本当に合理的なんだろうか。

最近のエージェントは本当に賢くなっていて、昔みたいなしょうもないミスはほとんど見なくなった。残っているのは、正解が 3 パターンくらいあって、AI はその中の 1 つを選んだんだけど、それが自分の音楽性とは合わなかった、みたいなやつ。

理解は目的じゃなくて手段

無限に時間があるなら全部理解した方がいい。それはそう。でもそれって「時間があるなら Ruby の内部挙動も知ってた方がいい」と同じ話になってきてるのでは、とも思う。

Ruby の VM の中身なんてほとんど読まずに使っているし、ライブラリの実装も大体そう。知ってればパフォーマンスで困ったときや変なバグに当たったときにすぐ直せるけど、知らなくても普段の開発はできる。AI が書いたコードの細かいところも、だんだんそっち側に寄っていくんじゃないかな。

そもそも理解すること自体が成果じゃない。動くものを届けて、壊れたら直せて、次の開発をしやすい状態を保つ。それがソフトウェアエンジニアの仕事で、理解はそのための手段の一つだと思っている。手段なら、別の手段に替えてもいい。

じゃあどうやって担保する?

とはいえ Ruby と AI が書いたコードでは違うところもある。Ruby を安心して使えるのは、みんなが使っていてテストもされていて、長年動いてきた実績があるから。自分が中身を知らなくても誰かが担保してくれている。AI が書いたコードはそのプロダクトのためだけのものなので、放っておくと誰も担保してくれない。

誰も担保してくれないなら、自分で用意すればいい。Ruby では、実装を読まずに振る舞いだけ信じている。AI が書いたコードでも同じでいいと思っている。手放すのは実装の理解で、振る舞いの理解は手放さない。

例えば型とテストは、実装を読まなくても振る舞いが変わってないことを確かめるためのもの。監視と段階的なリリースは、そこで拾いきれなかった分を本番で見つけて、被害を小さくするためのもの。こういった仕組みを作って担保していく。

意図を誰に記憶させるか

ただ、テストや型が守ってくれるのは「正しく動くか」までで、「なんでこうなってるのか」は守ってくれない。コードは読めるのに、消していいのか判断できない、みたいなやつ。

これまではそこを人間の記憶に頼ってきたけど、理解を手放すならそこも手放すことになる。なので、今まで以上に意図を明示的に残す取り組みが要るんだと思う。コミットメッセージに why をちゃんと書くのかもしれないし、リポジトリに Markdown で履歴を残していくのかもしれないし、Entire みたいに変更と AI のセッションを紐づけるプラットフォームかもしれない。

大事なのは、人間が意図を覚えていることに期待するんじゃなくて、AI が意図を知っている状態を目指すことだと思っている。人間は必要になったときに AI に聞けばいい。

決めるのはリスク許容度と仕組み

どこまで人間が担保すべきかは、その事業のリスク許容度と、理解以外の方法で担保する仕組みがどこまで育っているかで変わる、というのが今の考え。

スタートアップと大企業の例で考えてみる。

スタートアップはリスク許容度が高いので、理解しないリスクを取りやすい。大企業はリスク許容度が低いので、そこは取りにくい。

じゃあスタートアップの方が有利なのかというと、そうでもない。大企業には、理解しなくてもリスクにならない仕組みを作る体力がある。どっちが有利かというより、2つの軸のどこにいるかで取れる手が変わる、という話。

不安になる気持ちもわかるけど、必要なら理解を手放すという割り切りも、これからは必要になってくると思っている。 結局のところ、理解するかしないかそのものより、理解しないことで生まれるリスクを適切に管理できるかが重要なんだと思う。

会社の規模の話でもない

ここから先は半分余談。スタートアップと大企業という分け方もかなり雑で、リスク許容度が高い大企業もあるだろうし、ガチガチなスタートアップもあるはず。

最近ちょっと思ったのが、上場企業が新規事業をグループ子会社として切り出すのは、上場企業に求められるガバナンスでスピードが落ちるのを、スタートアップっぽく動きたい事業に持ち込まないためでもあるんだろうな、ということ。親会社の仕組みは借りつつ、リスク許容度は高いままにしておける。

個人的には、これから一番強くなるのはこういう大企業だと思っている。子会社化なりでスタートアップっぽく動けて、しかも仕組み化する体力もある大企業。社内のいざこざもあるので、実際にそれができる大企業はごく僅かだとは思う。でも、それができる大企業に敵うところはない気がする。

個人としてどうするか

会社の話ばかり書いたけど、個人としてどうするかも考えておきたい。

この流れはもう止まらないと思う。理解を手放した方が速いなら、速い方がスタンダードになるはず。資本主義なので。

個人的には、安全に手放せる状態を自分で用意できるようになるしかないと思っている。テストと型で振る舞いを固定して、壊れたら気づけるようにして、意図は AI に届く場所に残しておく。ここまで担保と呼んできたものを、自分が作る側になる。


書いたものを改めて読んでみて、現場を離れるようになった EM の悩みとかなり似ていることに気づいた。自分が書いていないコード・プロダクトに責任を持ち、把握するところ・把握しないところを判断していく。 AIエージェントによって、ソフトウェアエンジニアがみんなマネージャーにならざるを得なくなるとはよく言ったものですね。