すべてのため​​のバージョン管理

AI支援型エージェントコーディングは離陸速度に達しましたが、プログラミング以外のユースケースでは同じレベルの採用が見られていません。その主な理由はバージョン管理の欠如にあると私は信じています。 Gitリポジトリの外でClaude-codeを使用することを想像してみてください。リファクタリングのような小さなことでも、AIを使用するのは非常にストレスが多く、エラーが発生しやすいでしょう。 LLMが行った変更を追跡することはほぼ不可能です。LLMが生成したコードの監査は、別のタスクに進む前に変更が妥当であることを確認するためにその場で役立ち、将来的にコードがなぜそのように書かれたのかを理解したい場合にも役立ちます。 LLMはコードベースを悪い状態にする可能性があり、ロールバックする方法がありません。これは、LLMが信じられないほど賢く、いかなる「間違い」も犯さなかったとしても同様です。人間のプロンプターが設計上の制約について伝えるのを忘れるだけで、十分に悪い可能性があります。 「開発ブランチ」と「本番」の間に分割がありません。 複数のLLMが異なるブランチで作業できるようにして、開発を並列化することはできません。 Claudeに小さなスクリプトの作業を依頼する場合でさえ、私の生活を楽にするために常に新しいgitリポジトリを作成しています。しかし、コーディング以外では、同じガードレールとアフォーダンスを持つツールを見つけることはほぼ不可能です。 ケーススタディ：ソフトウェア開発のアウターループ ソフトウェア開発プロセスを管理することは困難です。私たちは、作業を管理するために課題追跡ツールとプルリクエストを使用し、人々はドキュメントを書き、電子メール、インスタントメッセージ、会議でコミュニケーションを取ります。これらのチャネルのすべての情報を同期させ、最新の状態に保つことはフルタイムの仕事です。 このシナリオでは、以下のシステムに関心があるとします。 githubの課題（読み取り/書き込み） プルリクエスト（読み取り/書き込み） googleカレンダー（読み取り/書き込み） googleドキュメント（読み取り/書き込み） gmail（読み取り） slack（読み取り） そして、ある情報が別のサービスから別のサービスに伝達されていない場所を見つけるためにLLMを使用することに関心があるとします（例：電子メールの会話の後で課題を新しい情報で更新する）。このタスクは単独では困難ですが、今日のLLMはそれを実行できると思いますが、最大の課題は、これらのサービスのいずれにも、LLMが人間によってレビューされるアクションを提案することを許可する組み込みメカニズムがないことです。 オプション1：プロキシレイヤー 基盤となるサービスを変更せずに、「プルリクエスト」レイヤーを追加するプロキシを構築することを想像できます。これにより、複数の基盤となるサービスにわたる変更をステージングし、公開前にレビューできるようになります。エージェントはこのプロキシを介して動作し、誰かがレビュー、承認、公開するまで変更を収集します。 これはいくつかの理由で困難です。 このようなカスタムシステムを構築するのは時間がかかり、特定のワークフローに依存し、より多くのサービスを統合する必要があるにつれて複雑さが増します。 「ロールバック」はおそらく手の届かないところにあるでしょう。基盤となるサービスは、「元に戻す」機能を実装するために必要な機能を提供していない可能性があり、特に他の変更が積み重なった変更をロールバックする場合です。 基盤となるサービスのマージコンフリクトを検出および解決することは常に可能とは限りません。 アトミック性がありません。誰かが「公開」ボタンをクリックし、いずれかのサービスが何らかの理由で変更を拒否した場合、他のサービスへの以前のすべての変更はすでに公開されています。これは、すでに公開された変更がロールバックできない場合、特に懸念されます。 基盤となるサービスの上に構築されたレイヤーは、変更をマージした場合の世界全体の状態がどのようになるかを確認することを妨げます。コードレビューを行うことを想像してください。ただし、差分だけでなく、差分が適用される前後のコードベース全体のコンテンツを表示する機能とともに、差分のみを確認できるとします。 オプション2：すべてをgitに入れる github、googleドキュメントなどを離れることに抵抗がない場合は、この機能をgitに移行できます。Jane Streetは、ソースコード内のコードレビューコメントをコードコメントとして直接埋め込むことで、コードレビューを有名に行っています。このワークフローの決定により、プロセス内のすべてがバージョン管理で追跡されるため、LLMをコードレビューに簡単に組み込むことができます。なぜ課題をコードベースと一緒に配置しないのですか？プルリクエストとコードレビューのメタデータをソースコントロールに？Googleドキュメントからの設計ドキュメントをチェックインされたマークダウンに？これらのすべてがコード自体と同じリポジトリに保存されていると理想的です。これにより、コード、課題、ドキュメントの変更を、サービス間で調整する必要なく、単一のアトミックな更新で行うことができます。 私の見解では、ここでの主な障害は、真剣な献身なしでは、人間のユーザーエクスペリエンスが大幅に低下することです。これは克服できないものではありませんが、かなりの作業になるでしょう。 LLMにとってより良い世界は、私にとってより良い世界です このブログ投稿を「プログラミング以外でLLMをより便利にするもの」としてフレーミングしましたが、「LLM」を「ジュニア開発者」または「シニア開発者」に置き換えても、すべてのポイントが当てはまる可能性があります。この統合から恩恵を受けるのはエージェントスタイルのLLMだけではありません。私のすべてのツールにブランチ、バージョン履歴、アトミックな変更があれば、私はより生産的になるでしょう。 経営陣に開発者の生産性ツールの投資を促すのは難しいかもしれませんが、今後数年間は、開発者にとってもより良い体験となる「AIインフラストラクチャ」への支出を正当化するのが容易になると思います。おそらく、これをあなたの利点として利用できるでしょう。 追加の読み物 以下は、興味深いと思われるリンクです。 ローカルファーストソフトウェア運動は、データの同期とドキュメントの同期のために、マージベースでコンフリクトフリーな技術を支持してきました。 Irminは、ブランチ、マージなどを持つgitのようなデータベースを構築するためのOCamlライブラリです。