「すべてにバージョン管理を」AIエージェント時代の新たな提言
Version Control for Everything
AIによるコーディング支援が急速に普及する一方、プログラミング以外の分野ではAIの活用が進んでいない。その理由として、バージョン管理の欠如を挙げる。コードであればgitがあるため、AIの変更を追跡・監査し、問題があれば元に戻せる。しかし、メールやドキュメント、カレンダーなどの業務ツールにはそのような仕組みがない。本稿では、プロキシ層を設けて変更をステージングし、人間のレビューを経て公開する方法と、すべてをgitに統合する方法の2つの選択肢を提示する。後者は理想的だが、人間にとっての使い勝手が課題だと指摘する。
「LLMを『新人開発者』や『ベテラン開発者』に置き換えても、すべての主張は成り立つ。すべてのツールにブランチとバージョン履歴、アトミックな変更があれば、私自身の生産性も上がるだろう。」
HNでの議論
53- cfjgvjh
私は本当に本当にすべてにバージョン管理をしたいと思っていますが、私のデータのほとんどはバイナリなので、gitとはあまり相性が良くありません。LFSも試しましたが、私の特定のワークフローではうまくいきませんでした。将来的には、もっとテキスト指向ではないものが登場することを願っています。Loreはこの目的のために興味深く見えました。
- PaulRobinson
> デザイン文書をGoogle DocsからチェックインされたMarkdownに？
これは私のチームではかなりうまく機能しました。Google Docsのデザイン文書は、決定事項と同期を取るのが本当に難しく、エージェントが適切にアクセスできませんでした。当初はコメントがなくなることが問題になるのではと心配していましたが、それは実際には起こりませんでした。Slackチャンネルで十分に機能します。このフローでは、デザインの作成者が決定とレビュー結果を作成し、エージェントがそれを個々の領域に伝播させ、そこからタスク（これもMD形式）に伝え、説明をJiraにコピーします。「何かを変更したが、それに依存する別の場所を更新し忘れた」ということはもうありません。少なくとも以前ほどはひどくありません。
- Klaster_1
コードの隣にすべてを置くというアプローチは理論的には良さそうですが、大規模なプロジェクトでは実際には悪夢です。プロジェクトマネージャーからのコミットでgit履歴が埋め尽くされ、要件やドキュメントの小さな変更ごとにコミットがあることを想像してみてください。私たちはそれを試しましたが、1日に何度もブランチをリベースしなければならなくなり、コード変更の全体像を完全に見失ってしまいました。主な問題は、コードは開発中に複数のブランチに存在できますが、ドキュメントや要件にはそれを適用できず、全員にとって単一の情報源が必要であることです。コラボレーションツールが、エージェントに適したテキスト形式で情報を提供/受け入れるように適応していくのを見るでしょう。一方、私は現在利用可能なツールでは、コード用とドキュメント用の2つのリポジトリを持つことが最良の解決策であると見ています。