AIのコーディングエージェントを使って、何にでもドライバーを強引に作れるところまで来てる。 それはちょっとナイーブな考えだし、そんなに簡単じゃないよ。著者も慎重になっていて、コードを見たわけじゃないからドライバーがどれだけ堅牢か分からないって言ってるしね。仮にそのアイデアを考えても、すでにファームウェアのブロブがあるクローズドソースのNvidiaドライバーとか、他のファームウェアのブロブがあるドライバーをオープンな代替品に置き換えられてるはずだよ。（Nouveauはあるけど、クローズドソースのドライバーほどのパフォーマンスは出せないから不利だし）それは読者がやるべきタスクだね。

あの厄介なGPLはもう私たちを止められないね、クールだ。

うまくいった主な理由は、ClaudeがLinuxドライバーをコピーできたからだよ。事前の作業がない状態で、AIはどうやってプロプライエタリなハードウェアを理解するんだろう？

いつかはできるかもしれないけど、まだそんなに近くはないみたい。OPの記事から見ると、動作するLinuxドライバーを渡して、これをFreeBSDに対応させてくれって頼んだら、できなかったみたいだね。OPは2ヶ月かけて、なんとか動くものを作るのにかなりの労力を使ったみたい。面白いのは、その作業が普通のマネジメントに似ていて、書面での仕様書を求めたり、校正したりしてるところだね。

ドライバーは、手で午後に組み立てられるくらい簡単なものから、集中して6ヶ月の努力が必要なほど複雑なものまで、幅広いからね。

ハードウェアドライバーのバグは、よく同時実行の不安定さやハイゼンバグとして現れることが多い。AIは、数週間ごとにしか問題を引き起こさないバグに対処するのが苦手なんだよね。

インスピレーションに使われたドライバーは完全にオープンソースだよ。https://github.com/torvalds/linux/tree/v6.18/drivers/net/wir... なんでBSDには取り入れられてないのかは分からないけど（多分ライセンスのせいかな）、彼らはOSに含めるものにはちょっと慎重みたい。

「もうすぐAIコーディングエージェントを使って、何でもドライバーを強引に作れるようになりそうだね。」 そうだけど、それってAIがデバイスを完全に壊すようなコマンドを強引に実行しない限りの話だよね。例えば、電圧コントローラーに異常に高い電圧を出させるコマンドを実行して、e-fuseを焼いたり、重要なEEPROMデータを消しちゃったりすることもあるし（工場出荷時のキャリブレーションプリセットが思い浮かぶ）。

未来（10年後？）には、使い捨てのソフトウェアがたくさん出てくると思う。例えば、コンサートのチケットを買いたいとするじゃん。AIエージェントに「チケットが欲しい」って頼むと、その場でコードを生成してチケットを購入してくれる。コードは簡単なcurlコマンドか、いい感じのUI/UXを持ったフルアプリかもしれない。ユーザーとしては、コードを見る必要はないんだ。もし同じ日にもっとチケットを買いたくなったら、AIエージェントは同じコードを再利用するだろうけど、1年後にまたチケットを買うときは、新しいAPIバージョンに合わせてコードを再構築するだろうね。無駄に思えるけど、もっとダイナミックだよ。ベンダーは生のAPIを提供するだけで、エージェントが希望するUI体験を作り出せるからね。その点では、エージェントを持つ会社以外は、使っているソフトウェアにマルウェアを注入できない。ソフトウェアによっては、他より長持ちするものもあるだろうし（例えば、エージェントが提供した音楽プレーヤーは、新しい見た目や機能が欲しくない限り再構築されないだろうね）。ソフトウェアにも「ペットじゃなくて家畜」アプローチを採用することになると思う。

結局、人々はAIに監視なしで構築・運用させるのが安全なものと、実際に中身を理解して監査したり、メンテナンスしたりする必要がある問題のレベルを見極めるようになると思う。僕は自分のヴィンテージゲームと妻の大きなボードゲームコレクションを管理する方法が必要なんだ。意見は結構強いし、リスクも低いから、たぶんクロードに全部作らせて、僕はそれを動かすだけにすると思う。でも、もしそれが僕の財政を管理したり、支払いを期限通りに行ったり、家の安全を確保したり、車を運転してくれるようなソフトウェアだったら、たぶんそうはしないだろうね。その分野の専門家じゃないから、ちゃんと動くことと信頼できることが重要だし、そういうソフトウェアは専門知識と実績のあるベンダーが書いてメンテナンスしているものを選ぶと思う。