BladeからRakuへ：コードベース全体をリネームした土曜日

名前は約束だ。Raku(楽) - 気楽さ、心地よさ、人の手の温もり - は、AI体験が機械的にではなく人間らしく感じられるように構築されたランタイムの背後にある約束だ。これは、それが現実になった週末の話だ。

このランタイムを作り始めたとき、それにはすでに名前がついていた。その名前は仮のものだった。命名について心配するのをやめてコードを書き始められるようにする、あの種の仮の名前だ。選んだ時点で、それが仮のものであることは分かっていた。本当の名前は、いくつかのことが落ち着くのを待っていた。

この週末、その仮の名前が取れた。このランタイムは今、Rakuだ。

なぜ今なのか

理由は3つある。

製品ターゲットが安定した。 ランタイムがAR1+で、次にAR2 Gen1で、それから3つの異なるハードウェアパスのどれかになるかもしれない、という状況では、デバイスファミリーにちなんで名付けることに意味がなかった。ARの方向転換が落ち着いた今、このエンジンはどのデバイス上で出荷されるかに依存しない、自分自身の名前を持つことができる。

パートナーシップの会話が本気になりつつある。 本気になる会話は、コードベースの中に仮の名前があっては成り立たない。ベンダーは、ファイルによっては「BladeRuntime」と名乗り、別のファイルでは「AR1+Runtime」と名乗るコードとはパートナーを組まない。このリネームは、それらの会話がこれ以上先に進むための前提条件だ。

ブランドには何か意味がなければならない。 日本語の「楽」は、気楽さ、心地よさ、楽しさを意味する。それはまた、機械的な精密さよりも不規則さと人の手の温もりを重んじる日本の茶陶の伝統の名前でもある。そのどちらも、このエンジンが何のためにあるかについてのシグナルだ。作りやすく、機械的ではなく人間らしく感じられる体験。漢字の「楽」はロゴにも表れている。この命名の選択は恣意的なものではない。会社のアイデンティティの最初の一片だ。

リブランドに何が含まれていたか

コードベース全体の一掃。その大部分は、連続して行われたエージェントの実行における2件のPRで着地した。エージェントは機械的な作業をこなした。それは良いことだった。なぜならその機械的な作業は膨大だったからだ。おおよそ以下の通り。

• コード、ドキュメント、CI内のすべての「ar1-runtime」への参照が「raku-runtime」に変更された
• ブランディングとパッケージング内のすべての「Blade」への参照が「Raku」に変更された
• ネイティブランタイムライブラリが ar1plus から raku にリネームされた
• エクスポートされるすべてのシンボルの接頭辞が更新された
• すべてのCMakeターゲット名が更新された
• すべてのインクルードパスの参照が更新された
• すべてのドキュメントの相互参照が更新された
• すべてのサンプルアプリのREADMEが更新された
• ロゴとブランドアセットが差し替えられた

2件のPR。両者を合わせておよそ110ファイルに触れた。どちらもビルドを壊すことなく着地した。それが重要な指標だった。

このやり方から学んだこと

3つある。それぞれ、エージェントが構築したコードベースにわたる一掃を計画している誰にとっても有用なものだ。

エージェントは私よりも速くリネームをこなす。ただしイシューが正確であればの話だ。 リネームの大部分を生み出したイシューは、どのシンボルが変わるか、どのパスが変わるか、どのドキュメントが変わるか、そしてどのパターンには触れないままにしておくべきか(チェンジログのエントリ、過去の意思決定ログ、アーカイブされたブランチ)を正確に述べていた。エージェントはその指示に従った。結果はきれいなリネームだった。2日前に試したバージョンのイシューはそれほど正確ではなく、リネームは、考古学的な理由で残すべきだった古いコミットメッセージ内の参照を含め、エージェントが過度に積極的にリネームした30か所とともに返ってきた。

リネームのPRは、たとえすべてに触れる場合でも、小さくありたい。 リネームを行った2件のPRは決して控えめではなかった。それぞれ数十のファイルに触れた。それらが小さかったのは、それぞれが一つのことしかしなかったという意味においてだ。各PRはリネームのみで、機能的な変更は混ぜていない。ほんの一つの小さな機能的変更でもリネームに混ぜてしまうと、そのPRはレビュー不能になる。なぜなら人間のレビュアーは、機能的な変更が本当にそれだけであることを確認するために、すべての行を読まなければならなくなるからだ。純粋なリネームなら15分でレビューできる。

ブランドは、リネームが出荷される前に準備できていなければならない。 この週末の作業の半分は、コードベースの中にはなかった。新しい名前を選ぶこと、ドメインを登録すること、ハンドルを確保すること、漢字の設定を正しくすること、ロゴをデザインすることだった。コードベースのリネームは最初のステップではなく最後のステップだ。もしコードベースのリネームを先にやって、それからブランドがまだできていないと気づいたら、もう一巡のリネームに詰まることになる。

変わらなかったこと

アーキテクチャは変わらなかった。C APIは変わらなかった。ロードマップは変わらなかった。製品ターゲットは変わらなかった。リネームの前の週末と後の週末でコードベースを読んだ人は、同じことをしている同じエンジンを目にすることになる。

これは正しい種類のリネームだった。方向転換ではなく、ラベルの変更だった。

パートナーとビルダーがこれから読み取るべきこと

もしあなたが今このランタイムを見ているインテグレーターなら、私たちのリポジトリとパッケージングのどこかに「raku-runtime」が見えたら、それは先週末まで別の何かと呼ばれていたのと同じエンジンだ。互換性の断絶はない。C APIは変わっていない。SDKバインディングは変わっていない。サンプルアプリは引き続き動作する。

もしあなたが、このエンジンの上で出荷される製品でパートナーシップを組むことを考えているなら、名前は今や安定している。会話は「今のところこう呼んでいますが」から始める必要はない。「これがRakuであり、これが何のために作られたものかです」から始めることができる。

もしあなたがAR2デバイスのチームの中にいて、自社のプラットフォームでどのランタイムをターゲットにするか考えているなら、この名前の変更はまた、このエンジンが市場のどこに位置づけられているかについての声明でもある。Rakuは「AR1+ランタイムが成長したもの」ではない。それ自身の主張を持つ、それ自身のものであり、最も適したハードウェアパートナーのどれの上でも出荷する意志がある。このリネームはその声明の一部だ。

静かな週末だった。機能的には何も変わらなかったという意味で。正しい種類の静けさだった。