かつて私がそうだったように、プログラミングにおいてSemVerがあまり好きではないとしても、オープンソースソフトウェアの配布というものは、かつては決まった手順を踏むものだと考えることができる。開発が行われるブランチがあり、そのブランチはたいてい安定して使える状態ではない。そこで一定期間、開発を凍結し（その間も、新しい不安定なブランチで作業を続けることはできるとしても）、バグを修正し、人々にテストを頼む。やがてバグ報告の数が減り始め、チームもユーザーも、今後数週間のうちに簡単に見つかるような明白で致命的な欠陥はもうないと思えるようになる。そこでそのブランチを2.4などと名付ける。それで終わりだ。

しかし今、AIコーディングによって変わったのは開発だけではなく、ソフトウェアを使うという行為そのものも影響を受けている。AIにソフトウェアへの変更を頼めるのは自分だけではなく、ソフトウェアを受け取る側自身も同じことができるのだ。これはソフトウェアの主なユーザーがプログラマーである領域では明らかだが、テクノロジーに親しんだユーザーがAIやコーディングエージェントを利用できるようになるにつれ、一般的により広く当てはまることでもある。

この変化のために、すべてを磨き上げた安定版ブランチと、すべてが開発途上にある不安定版ブランチだけを用意するという考え方は、もはや適切なやり方ではなくなっているのかもしれない。コードリポジトリは完成品でもありうるが、ある問題の周辺で物事をどう進めるかのテンプレートであれば、さらに有用になりうる。ユーザーは特定の要件やハードウェア、解くべき具体的な問題に特化させるためにコードを改変するかもしれない。また、一般のユーザーには不安定すぎたり未検証すぎたりするものが、別のユーザー層にとってはまさに求めているものであることもある。

Redisを例に挙げよう。私はここ数週間、ソート済みセットで大幅なメモリ節約を実現するPRに取り組んでいる。この作業が受け入れられれば、Redisの仕組みをまったく知らない人から、長年にわたってコードに貢献してきたユーザーまで、すべてのRedisユーザーに影響が及ぶ。些細なユースケースから、ソート済みセットで50%のメモリ削減が年間のクラウド料金を大幅に削減することにつながるようなユースケースまでだ。後者のようなユーザーにとっては、（「とりあえず動く」ものを洗練させるために私が行っているあらゆるテストや設計変更を経たうえで、しかも最終的にコードベースにすら入らないリスクもある）最終的な製品を待つよりも、初日から95%完成したブランチを手にできる方がはるかに魅力的かもしれない。それは彼らがテストし、適応させ、反復し、目の前の問題のためにより特化させることのできるコードなのだ。

DwarfStarは、コードリポジトリが機能マトリクスのすべてをカバーする完成品であるよりも、優れた事例であるべきだということを、より雄弁に物語る例かもしれない。DwarfStarという具体例におけるローカル推論では、多種多様なGPU、モデル、サーバーモード、エージェントモード、CLI、SSDストリーミング、テンソルおよびパイプライン分散実行といった要素がある。すべてをあらゆる環境でテストするのは複雑だ。しかし、テンソル並列のグラフ実行について二つの確かな実装例があれば、優秀なコーディングエージェントは他のバックエンドとモデルの組み合わせについても同様の実装方法を推論できる。同様に、エンジンがある二つのモデルを十分にサポートしていれば、三つ目のモデルは既存のコードベースをコーディングエージェントのガードレールとして活用することで、ほぼ自動的に実装できる。

これはDwarfStarのようなプロジェクトがそのまま使える状態で動作すべきでないという意味ではない。そうではなく、ユーザーが自らカバーできるより広範な状況へと外挿できるような、一連の機能をしっかりとサポートすることに注力しうるということだ。そしてもう一つの意味もある。mainとunstableの二つだけではもはや足りないということだ。多くの実験的ブランチがプロジェクトの不可欠な一部になりうる。たとえば昨日、Laguna S.1モデルがリリースされた。紙の上では面白そうだが、しかし本当に十分な性能があるのだろうか。新しいDeepSeek v4 Flashのチェックポイントによって、DwarfStarにとってあまり意味がなくなってしまうのではないか。まだ判断するには早すぎる。しかし、皆で考えをまとめるために、このモデルの実装を含むブランチを公開することは良い中間地点になる。人々が試し、各自のコーディングエージェントで磨き上げ、コミュニティ全体でマージに値するかどうかという考えを形成できる。さらに今日、私はDwarfStar内部のコードコーパスが形作るレールのおかげで、その実装がGPT 5.6 Solによって自動的に約2時間で書かれたことに気づいた。DS4やGLM5.2の実装には、モデルカードを読んだり、それらのモデルのアテンションの実装の詳細を調べたりと、多くの舵取りが必要だった。今回はただ動いたのだ。GPT 5.6がより強力になったこともあるが、既存のソースコードの中に多くの良い事例を見つけたからでもある。

今日のソフトウェアは、これまでになくしなやか（malleable）だ。ある意味で、それはより流動的な形でリリースできることを意味する。また、ドキュメント自体も人間に分かりやすいだけでなく、コーディングエージェントがシステムの変更方法を理解できるものであるべきだということも意味する。これが今後正確にどう進化し、安定性、使いやすさ、機能という異なる次元の間で、どこが適切なバランス点になるのかは、私にもわからない。ただ、われわれ開発者は、この先どこへ向かうのかを見極めるために、目を開いておく必要があると信じている。