AIコーディングでの変化を車の走らせ方で考える

AI コーディングを業務でも個人でも使うようになってから、「自分はこの判断軸でやっている」という話が少しずつ溜まってきました。一つひとつは雑談で口にする程度の話なのですが、まとめて並べてみると、AI 以前と比べて自分の判断のやり方が結構変わっていることに気づきます。

よく「AIの利活用は車の運転に近い」という話をするので、簡単にまとめてみました。

走る道が一般道から高速道路に変わった

AI コーディングで何が変わったかというと、なによりも速度です。これまで1週間かけていた実装作業が数分で終わり、レビュー待ちのチケットやPRがすごい勢いで積み上がります。

ここで「速くなって嬉しいね」で終われればよいのですが、実際にはそうもいきません。一般道で時速 40km の運転ができるからといって、同じ感覚で高速道路に走ることはできません。主要な高速道路では60km/h以上の速度で走ることが求められておりますし、流れに乗るには80-90km/hは必要でしょう。つまりこれまでの倍以上で走る車を制御する必要があります。また、正しいルート選定ができていない場合、一般道なら次の交差点で戻れますが、高速道路では数キロ先のICを降りて折り返すしかなく、失敗時のコストも大きくなります。

AI コーディングはこれと似ています。速度が上がったぶん、走り方を変える必要があります。具体的には、変更を出すか出さないかの判断、自分以外の視点を入れる仕組みなどです。

Two way doorの考え方でAIに任せる

できるだけAIやエージェントに任せてしまいたい。でも、ある程度制御や監視を入れないととんでもない方向に進んでしまって却って高くつきます。この辺りの任せる・任せないの判断として、two-way door の考え方を今は採用しています。これはAmazon の Jeff Bezos が2015年の株主への手紙に書かれていたもので、「戻れる扉なら気軽に通って、ダメなら戻ればよい。戻れない扉なら、慎重に考えてから通る」というものです。京都など碁盤の目で道が構成されており、高い頻度で交差点がある場所では、すこし道を間違えてもぐるっと1周すればリカバリーできます。しかし高速道路などの有料道路では間違えた際の時間ロスが大きくなるため、事前に走行ルートの検証などを行うべきでしょう。

もうちょっと具体的な指針に落とし込んで、「terrafrom destroyしてapplyしなおしても、それだけで問題なく動作するか？」のような形でも判断しています。ちょっとしたAPIをいくつかよんでSlackに送るだけのワークフローなら、トラブルが起きてもロールバックすればいいと割り切れます。しかしECサイトやサブスクシステムなど、決済や個人情報が絡むDBなどが関係する場合は、気軽に「じゃあ作り直そう」と判断することは難しいです。

AIに任せるかどうかを、ひとまず「やってみて、ダメだったら戻れる領域」つまりTwo-way doorな場所から始めるのが、心理的な不安などを抑えれるのではないでしょうか。

速度が変われば、運転方法も変わる

AI コーディングで起きたのは、何より速度の変化です。速度が変われば、見るべき場所も、ハンドルの切り方も、ルート判断や車線変更の判断時間も変わります。一般道の走り方で高速道路は走れません。

AIの速度に追従する、有り体に言えば「慣れる」ためには、まずは試行錯誤が必要です。そうなるとtwo-way doorで取り返しのつく領域から委任に挑戦するのが良いでしょう。いきなり長距離を運転するのではなく、近場や混雑していないルートですこしずつ慣らしていくようなイメージですね。

ここに書いたのはあくまで現時点での自分の判断軸で、しばらく走らせていればまた差し替えたり足したりしているのだと思います。ただ、「速度が変わっただけだから、走り方は今までと同じでいい」というスタンスでハンドルを握り続けるのは、今いちばん危ない選択肢なのではないでしょうか。