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

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

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

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

DwarfStarは、コードリポジトリが機能マトリクスのすべてを網羅する完成品であるよりも、優れた実例であるべきだということを、より雄弁に物語る例かもしれない。ローカル推論において、DwarfStarの場合を考えると、さまざまなGPU、モデル、サーバーモード、エージェントモード、CLI、SSDストリーミング、tensor並列やpipeline分散実行といった要素がある。すべてをあらゆる環境でテストするのは複雑だ。しかし、tensor並列のグラフ実行についてしっかりした実装例が二つあれば、優秀なコーディングエージェントは他のバックエンドとモデルの組み合わせについても同じことをどう実装すべきかを推測できる。同様に、二つのモデルを十分にサポートするエンジンがあれば、三つ目のモデルは既存のコードベースをガードレールとしてコーディングエージェントの実装を導くことで、ほぼ自動的に実装できる。

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

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