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

AIはここでは役に立たないと思うよ。OPのタスクは、FreeBSD用にオープンソースのドライバーを別のものに変換することだったからね。Macにはそもそもオープンソースのドライバーがないから、結局は人が地道にリサーチしなきゃいけない。AIにコンピュータの最下層で完全にインタラクトして、接続されているハードウェアを観察する能力を与えられるまでは、そうなるよね。

これは、デロリアンが自作のタイムマシン用のスペアパーツを作らなかったと文句を言ってるようなもんだね。

著作権の懸念から、コードを書く手助けにAIを使うことはないんだ。それはポリシーに反するからね。私たちはやっていることに非常に注意を払わなきゃいけないし、AIがAppleのドキュメントやAppleのバイナリをリバースエンジニアリングしたことがないとは保証できないからね（その点については非常に厳格なクリーンルームポリシーがある）。生成されたコードがGPL+MIT互換であるとも限らないし（同じサブシステム内の他のGPL専用ドライバーからインスパイアを受けるかもしれないから）、私たちはBSDがドライバーからインスパイアを受けるためにGPL+MITを使いたいと思っているんだ。

そのパッチ、共有してくれない？

AI支援のクリーンルーム逆コンパイルとオープンソースライセンスの洗浄の境界線は薄いと思うし、記事で説明されているものは洗浄に越えていると思う。クラシックなクリーンルーム設計では、1つのチームがインターフェースを文書化するけど、コードは文書化しないんだ。

ありえないと思う。未来にはそういうことをする人もいるだろうけど、正直言って、そういうのはすでに何かを作ることに興味がある人たちがほとんどだと思う。フルオンのソフトウェア開発じゃなくてもね。うちの両親、石灰石の採石場でダンプトラックを運転している兄、義理の姉、みんなテクノロジーの仕事をしてないし、自分たちを技術的だとも思ってない。彼らは絶対に自分でソフトウェアを書くことはないし、アプリストアからアプリをダウンロードしたり、やりたいことを実現するウェブサイトにサインアップしたりするだけだよ。

これ、3Dプリンターが一般市場に出たときの感じに似てる。みんなが「もう買い物は終わりだ、家で印刷すればいい」って言ってた。標準化されたソフトウェアにもたくさんの利点があるよね。企業は、社内ツールをゼロから教えるよりも、すでにPhotoshopやXero、Webpackなどを知っている人を雇えるっていう事実に頼ってるんだ。

これが大きなポイントだと感じるね。「すべての問題を解決する」わけでも「マージするには十分じゃない」わけでもなくて、解決策が自分の抱えてる問題を解決するのに十分なところに来てるってこと。初期のGithubを思い出すな。カスタムでユニークなソフトウェアがみんなにもっとアクセスしやすくなった時期。掘り下げる必要が減ったし、我慢することも少なくなった。

著者は特に、コードを読んだり、出力をしっかりテストしたりしていないと言ってたよ。意図的にただの素朴なおもちゃとして遊びたかっただけなんだ。AIやAIの能力とは何の関係もない。本人はあまり努力を入れなかったんだよ。

ソフトウェアの代わりに、LLMがすべてのコンピュータのインタラクションに対して特注のコードを出力することになる。これ、GPUのアップスケーリングのアイデアに似てるね。ゲームを低解像度でレンダリングして、アルゴリズムを使ってモニターのネイティブ解像度にアップスケールすることで、ゲームパフォーマンスと視覚のシャープさを向上させる。実際に高解像度でレンダリングするよりも、なんか安く済むんだよね。GPUに低コストで違いを幻覚させるって感じ。

プログラマーは常に追加の抽象化レイヤーを求めてきたよね。LLMコーディングはまさにその衝動に応えてる。

現状を批判するのは正当だよ。ハイプに乗ってる人たちは、未来を予想してワクワクしてるだけ。これは、以前は不可能だったマイルストーンだから注目すべきだね。自分でハードウェアやドライバーのプログラミングをほとんど学ばずに、動くドライバーを作った人からのものなんだから。まだ製品としては準備ができてないけど、何かの初期の動作バージョンもそうだし。ここで進展が急に止まる理由があると思う？

この反応が理解できないな。すごいじゃん！バグのあるFreeBSDカーネルドライバーを作れるプログラマーって、どれくらいの割合なんだろう？もし自分でこれを開発しなきゃいけなかったら、最初にちょっとでも動くものがあるとめっちゃ助かるよね？

次はPostfix/Dovecotをやってほしいな。まだまだ苦労してるから。