愛と幻想のアジャイル

道産子ソフトウェアエンジニアの技術メモ

AIスロップの割れ窓

生成AIが出てきてから、長い文章を目にする機会が増えた気がする。自分も作っている自覚がある。いわゆるAIスロップというやつだ。

読む側に文章のレビューをそのまま丸投げしているようなもので、相手の認知負荷を増やしている面がある。そこはかなり気をつけた方がいいと思う。

でも厄介なのはここからだ。一度ドキュメントをAIに生成させると、「これくらいなら出してもいいか」の閾値がじわじわ下がってくる。

割れ窓理論に似ている気がする。割れた窓を放置すると、その建物全体が荒れていく。最初の一枚が割れているだけで、次の一枚を割ることへの抵抗が減る。

ドキュメントも同じだ。一度雑なものを世に出すと、次はもっと雑でも通ってしまう。妥協が妥協を呼んで、気づけば「まぁこれでもいいか」が基準になっている。

かといって、生成させずに全部手書きに戻すのも現実的じゃない。もう後戻りはできないんじゃないだろうか。

折衷案として考えられるのは、生成物だと分かるようにしておくことかもしれない。これはAIで作った、著者本人も完全には理解し切れていない文章です、と最初に伝える。そうすれば読む側も、そのつもりで頭を切り替えて読める。

閾値そのものは下げないまま、扱い方だけ変えるということだ。窓は割れてしまうかもしれない。でも割れた窓だと分かるようにしておくことはできそうだ。

OSSと牧歌的な時代

最近、OSS文化が廃れてきた気がする。前ほど、無償で公開されることを当たり前だと思えなくなってきた。なぜだろうと考えてみた。

OSSのはじまりを辿ると、1960〜70年代の大学や研究機関のコミュニティに行き着くらしい。当時はコードを書いた人同士で気軽に共有し合うのが普通だったそうだ。その背景には、同じ時代のカウンターカルチャー的な価値観の影響もあったと聞く。

情報は誰のものでもない、共有すればみんなが豊かになる。そういう贈与経済的な発想が、初期のハッカーたちの土壌にあったと聞く。

金より自由。金より共有。そんな空気が、コードを書いて無償で配るという行為を支えていたんだと思う。

でも、いつからか流れが変わった。働いた分はちゃんと対価をもらいましょう、という考え方が主流になってきた。

それ自体は健全なことだと思う。タダ働きを美徳にしすぎるのも、どこかで歪みを生む。メンテナが疲弊して燃え尽きる話も、何度も聞いてきた。

ただ、対価という発想が強くなるほど、あの牧歌的な空気は薄れていく気がする。みんなでただ良いものを作って、ただ配る。そういう単純な動機だけでは、もう成り立たなくなってきたのかもしれない。

自分は別に、昔に戻れと言いたいわけじゃない。ただ、なぜOSSというものが生まれたのか。なぜそこからお金の話に変わっていったのか。

そこを粗くでも理解しておかないと、無償で公開しないメンテナや、スポンサーを募る開発者を見て、「昔は良かったのに」と安易に思ってしまいそうな気がする。

説明できるということ

昔、仕事の半分は開発で、半分は障害対応だった。

障害対応で一番やっかいだったのは、コードの保守性と可読性。

当時はそんな言葉も知らなかったけど。

関数が連番になっている。

手続き的な処理が一つの関数に数百行ある。

1行しかないインターフェースを三つも継承している。

そういうコードを、その場にいない誰かの代わりに読む。

理解するだけで日が暮れて、毎日御前様だった。

自分は、「低保守性コードに村を焼かれたから」とうそぶいてた。

それ以来、マーティン・ファウラーのリファクタリングを写経したりして、保守性と可読性にこだわるようになった。

悲しき申し子だと思う。

いま、AIがコードを書いてくれる。

結構いい感じに作ってくれる。

読まなくてもいいんじゃないか、と感じる瞬間すらある。

でもAIは間違える。

しばらく使っていれば、みんな持っている感覚だと思う。

ベストじゃないけど、まぁこれでいいか、で通ってしまうことも多い。

人間がもうコードを読まずに保守していく世界なら、それでもいいのかもしれない。

でもそうなるかどうかは、まだ誰にも分からない。

分からない間は、なぜそう作ったのか、自分で説明できるようにしておいた方がいいと思う。

なぜそうなっているのか。

どういう考え方で組み立てられているのか。

AIが書いたコードでも、そこは人間が説明できる状態にしておく。

そうしておかないと、いつか自分の書いていないコードに、自分が村を焼かれることになりそうだ。

生産性3倍という計算

コーディングエージェントのおかげで実装が速くなった、という話をよく聞く。

3倍速くなったから、6人でやっていたことが2人でできる。

そう聞くと、一瞬納得しそうになる。

でもこれ、SIerなどで昔から悪習とされてきた計算とよく似ている気がする。

工数が6人月だから、3人いれば2ヶ月で終わる。

そういう単純な割り算が、現場を疲弊させてきたはずだ。

人が減っても、レビューは減らないし、設計判断も減らない。

コミュニケーションのコストも、思ったほど減らない。

コードを書く速度が3倍になっても、チームとして正しい方向に進んでいるかを確認する速度は、そう簡単には3倍にならないんじゃないだろうか。

むしろ、速く書けるようになった分だけ、間違った方向にも速く進めるようになったとも言える。

数字だけを見て人を減らすと、そのしわ寄せは誰か一人に集中する気がする。

コーディングエージェントは、確かに個人の生産性を底上げしてくれる。

でもチームの生産性は、個人の生産性の単純な足し算では計算できない。

そこを忘れて掛け算や割り算だけで人員計画を立てると、以前と同じ失敗を、AIというラベルを貼り替えてまた繰り返すことになりそうだ。

鍛えるためのAI、楽するためのAI

AIが出てきてから、色々助かったり、役だったりしている。

それはそれとして、 やはりAIは自分を鍛えるために使った方がいいんだろうと思う。

AIに思考を丸投げした分だけ、自分の脳で考える機会を損失してるかもしれない。 脳は使えば使うほど、シナプスかニューロンかが活性化して、よりよい思考ができるようになるものだと思っている。 AIのせいで、逆にシナプス刈り込みが起きてないだろうか?そこが気になる。

AIに丸投げすれば、短期的に早く成果物が出せる。 でもそれを続けていたら、いつかAI丸投げしかできない人間になってしまいそう。

依頼人←丸投げ→自分←丸投げ→AI

これだと、自分はいてもいなくても同じになってしまう。だから下記になりそう。

依頼人←丸投げ→AI(自分は消えた)

あとAIの料金もある。
今後もしも高騰したら、いつでも使えるものではなくて、ここぞと言うときだけ使うものになるかもしれない。
そうなったら、人間がオーガニックな開発をする時間が今より伸びるはずだ。
その時になって自分を鍛えていなかったら、困ることになりそうだ。多分、以前出来ていたことが出来なくなっている。
まぁ将来の料金はどうなるのか注視したい。

楽するためにAIを使うと、長い目でみて辛くなる。
自分を鍛えるためにAIを使えば、やがて楽になる。
将来辛くならないように、今のうちに鍛えておこう。