2月16日、gritzkoが「SCMandLLM.md · GitHub」と題した記事を公開した。この記事では、LLM（大規模言語モデル）による開発が加速する中で、既存のGitアーキテクチャが直面している限界について詳しく紹介されている。

以下に、その内容を紹介する。

開発の主な作業は「コーディング」から「コードの理解」へ

かつてIDE（統合開発環境）は「コードを書くための道具」であったが、今や開発者の役割は、LLMが生成した膨大なコードを読み解き、対話を通じて修正していく「閲覧と理解」にシフトしている。

著者は、コードを単なる文字の羅列ではなく、相互に関連し合う情報として捉えるべきだと主張する。この膨大な情報をいかに効率よくブラウズし、構造を把握できるかが、現代の開発における成否を分ける。コードの本質的な理解を欠いた開発者は、もはや制御を失った馬に引きずられる乗り手のような、無力な存在になりかねない。

LLMという「超高速な共同作業者」がもたらす摩擦

LLMの登場により、コードの生成スピードは以前とは比較にならないほど向上した。しかし、管理側であるGitがこの変革に対応できていないことが、新たな摩擦を生んでいる。

• 人間を置き去りにする変更量
  LLMは瞬時に大量のコードを書き換える。人間がその膨大な差分（diff）を一行ずつ確認し、意図通りか精査する作業は、もはや処理能力の限界を超えつつある。
• マージ作業の「不確実性」というストレス
  Gitにおけるマージは、機械的なルールに基づくものの、競合（コンフリクト）が発生した際の解決は「人間の手作業と判断」に依存している。このプロセスは決定論的ではなく、作業者のミスや解釈の違いが入り込む隙がある。これが大規模な開発において、心理的・作業的な大きなコストとなっている。
• 「推測」に頼った差分抽出
  Gitのdiffは、行の追加や削除を見て「おそらくこう変更されただろう」という最短経路を計算しているに過ぎない。コードの構文的な意味（例えば「関数名を変更した」のか「古い関数を消して新しい関数を書いた」のか）を理解しているわけではないため、大規模な変更が入ると、人間にとって文脈の読み解きにくい差分が生成されてしまう。
• モノリポジトリ管理における構造的な欠陥
  Gitはリポジトリ全体を一つの単位として扱うため、巨大なプロジェクト（モノリポジトリ）を論理的なモジュールごとに分割して管理したり、必要な部分だけを柔軟に組み合わせて扱う仕組みが根本的に不足している。サブモジュールなどの機能も後付けの補完に過ぎず、プロジェクトの巨大化に伴う管理の複雑化を防ぎきれていない。

「ファイルの貯蔵庫」から「構造化されたデータベース」へ

著者は、Gitが「単なるファイルの貯蔵庫」である限り、これらの問題は解決しないと説く。これからの時代に求められるのは、プログラムの構造（AST：抽象構文木）そのものを認識し、数学的なアルゴリズムによって自動かつ正確にマージができる、「コードのためのデータベース」としてのSCMである。

既存のGitエコシステムの巨大な引力に抗ってでも、このアーキテクチャの転換が必要であるとして、著者はCRDT（対立解消型共有データタイプ）を活用した次世代の基盤技術「RDX」の開発に取り組んでいる。

詳細はSCMandLLM.md · GitHubを参照していただきたい。