The scariest part to me is that we become dependent on these new machines in new ways. Software has always depended on tools. I remember the time when I had to pay for compilers. These new tools are a flashback to times where creating software came with real costs. But now it’s no longer a one-time payment, it’s a constant dependency. Not just a dependency on a filled wallet, but also a cognitive dependency.

• The Coming Loop | Armin Ronacher’s Thoughts and Writings

Pi Coding Agent を開発する Armin Ronacher が agent 依存の高まるコードベースへの不安を語っている。なんとなく既視感を感じた。

昔々 WebKit/Blink の仕事をしていたころ, fuzzing によって見つかったクラッシュバグを毎週のように直していた。GCP 上のクラスで動く Fuzzer は半ランダムに DOM を操作する JS のコードを生成しては実行し、継続的にクラッシュバグを見つけてくるのだった。

ブラウザのコードを触ればバグは埋め込まれる。その不都合な事実を fuzzer によって叩き込まれると同時に「これクラスタ代を払うカネが無くなったらどうなるんだろう」と不安も覚えた。カネがないとバグが直らない。Mythos がないとバグを見つけられない昨今の風潮に通じるものがある。百倍くらい価格差ありそうだけど。

相対的にカネがないブラウザはどうするのだろう。そう思って Firefox に目をやると、彼らはクラッシュしない言語たる Rust をつくり、それでブラウザを書き直していた. もっというと DOM は JavaScript に乗せメモリ管理を GC に任せていた。計算資源を燃やすかわりに知恵を使う。クールじゃん。そう当時は思った。(Chrome の名誉のために補足しておくと、Blink の DOM もその後何らかの GC を導入してある種のメモリ安全性を達成したらしい。)

エーアイ時代にも、カネと計算機の力でねじ伏せるコードと知恵と勇気(友情でも愛でもなんでもいいよ)で切り抜けるコードがあってよい。

上でリンクした記事は、来たるべき時代の予兆として Curl 開発者の burnout 寸前事例を挙げている。が・・・これはどのくらい一般化できるのだろう。世界一人気のあるネットワーク・プロトコルの世界一メジャーな実装として世界一攻撃に晒されているというのによりによって C で書かれているこのライブラリ、ソフトウェア開発の未来として一般化するより人類の限界をベンチマークする事例と見たほうが適切ではなかろうか。

ソフトウェアのバグは一般に直すより見つける方が難しい。Ronacher が恐れるような「攻撃にエーアイを使われたら防御にもエーアイが必要」というとき、別にエーアイにコードを書かせる必要はない。むしろ Ronacher がいうような、ヒトが慎重で硬いデザインを詰めていくほうが妥当なことは多いと思う。防御のためのエーアイは、攻撃者より先にバグを見つけるのに使えば良い。

やがてエーアイが人間より硬いコードを書くようになり、しかし人間にはそれが理解できない日がくる可能性はある。たとえば formal method をエーアイに書かせるぞ と息巻く Jane Street はそうした世界にむかい先陣を切っている。ただ個人的には先の話・ニッチな話に感じられる。

どういう形をとるにせよ、計算機の力で人智を超えたコードを生成しまくる世界も、計算資源の嵐を知恵と努力と友情で乗り切る未来も、それぞれの趣や面白さがある。

エーアイ絡みの心配は自分も色々あるとはいえ、重要なソフトウェアがゴミコードに埋もれて窒息する不安は今のところあまり大きくない。ただし前提がある: エーアイ業者はその泡銭で CS 研究者をやとって遊ばせておいてほしい。CS 研究者もそれに便乗しコード環境問題への取り組みを頑張って欲しい。問題は起こるし、もう起きている。でもそういうボヘミアン研究者がきっとなんらかのブレイクスルーを見つけ出すと思うんだよね。それがなんだかは知らないけれど。自分の楽観は、人類が産んだ賢い人々への楽観なのかもしれない。