クリーム色の紙に鉛筆で描いた線画。小さな箱を一つ抱えて歩く人と、その横で傾いている木箱とケーブルの大きな山。文字はない

AIの時代も最後の1%に100%のコストを払わない選択を

AIに任せると、コードもその周りの仕組みも肥大化します。だから私は、固くはなっても重くはならない選択肢だけを選ぶようにしています。

コードを100%AIで書かせたら3倍になった、という話

Xで、ある話が広がっていました(Xのトレンド)。もとはRedditへの投稿です。1年前に「コードは100%AIで書くこと」と命じた会社で、コードベース(その製品を形づくるコード全体)が3倍に膨らんだ。中身は重複だらけで、レビュー(他の人がコードを読んで確かめること)できる人もほとんど残っていない。Node.jsを作ったRyan Dahl(ライアン・ダール)も、驚いた反応をしていました。

投稿の中身を私が確かめたわけではありません。ただ、読んで驚きはしませんでした。似た景色を見たことがあるからです。

数行直すたびに、長いテストを待たされた

仕事で関わったあるプロダクトは、仕様がなかなか定まらないまま走り出した、いわゆる見切り発車でした。幸い、私が自分とAIで開発していたものは、そのプロダクトの一歩先を見ていました。

一方で、そのプロダクトの周りでは、AIに頼りながらも、AIを信頼しきれない空気がありました。信頼できないから、とにかく堅牢にしようとする。そうして仕組みばかりが増え、全体が肥大化していきました。

数行のコードを直すだけで、とてつもない量のテストが走ります。デプロイ(作ったものを本番の環境に出すこと)までに、無駄な時間を待たされました。

私はそれが嫌でした。だから、固くはなるが重くはならない、という選択肢を常に手元に置いてきました。

これは特定の手法の話ではありません。テストも、ハーネス(AIやプログラムを決まった手順で動かし、結果を確かめるための仕組み)も、品質ゲート(基準を満たさない変更を自動で止め、先へ進ませない仕組み)も、私は全部の層で、固くても重くないほうを選びます。

真面目な人ほど重くする

この失敗は、エンジニアならきっと誰もが一度は見ています。

そして、真面目な人ほど重くします。重さが満足感をくれるからです。テストを増やし、確認の段階を増やすと、ちゃんとやっている気持ちになれます。

でも実際には違います。開発の品質と同じで、99%を100%にするには相当なコストがかかります。これはAIでも変わりません。AIが実装をしても、テストをしても、検証をしても、最後の1%の品質にはやはりコストがかかります。だから私は、最後の1%を追うために100%のコストを足すような選択はしません。

不思議なのは、人間が全部やっていた頃は、これが当たり前の判断だったはずだということです。それなのに、なぜかAIにやらせると判断を誤ります。その結果、本当に大事な部分に使うはずの時間が削られていきます。

重さに満足しているのは、作った側だけ

重さがくれる満足感は、作った側のものです。ユーザーはその重さを見ませんし、喜びもしません。ユーザーが喜ばない満足感のために、コストを払うべきではありません。

堅牢さと軽さは両立できます。固くても重くないほうを、毎回選べばいいだけです。数行の修正なら、数行ぶんの待ち時間で出せる。私にとっての堅牢さはそういうものです。