RepoLens Version 2が今週Product Huntで第7位にランクインしました。
その数字はわくわくするものでしたが、私にとってより重要だったのは、それが何を意味していたかです。
この問題が、私だけでなくもっと多くの人にとって響くものであることを示すサインのように感じました。
というのも、RepoLensは私が何度も何度もぶつかってきた苛立ちから始まったからです：
コードベースを理解するのに時間がかかりすぎる。
新しいリポジトリを開くと、私はだいたいいつも同じサイクルをたどっていました：
- ランダムにフォルダを開く
- ルートを探す
- importを手作業で追跡する
- モジュール同士がどう組み合わさっているかを推測する
- 散らばったファイルや、いわゆる暗黙知（部族的な知識）からアーキテクチャを理解しようとする
そのプロセスは遅く、繰り返しが多く、精神的にも負担が大きいものでした。
そこで私はそれを解決するためにRepoLens Version 1を作りました。
Version 1は、開発者がリポジトリをより早く理解できるようにすることを目的としていました。
リポジトリを分析し、スタックと構造を検出し、モジュールと依存関係をマッピングし、APIエンドポイントを抽出し、ドキュメントを生成し、根拠に基づいたリポジトリチャットをサポートし、ブランチを比較し、そしてコードベースを、もっと探索しやすい形へと変えることができました。
それは重要な問題を解決しました。
しかし、それを作っている最中に、実際のつらさの半分しか解決できていないと気づきました。
Understanding a Repository Once Is Not Enough
リポジトリは静的なものではありません。
動き続けます。
プルリクエストは挙動を変えます。
エンドポイントはずれていきます。
依存関係は進化します。
アーキテクチャは少しずつズレていきます。
そしてチームは、常にもっと難しい問いに答えようとしています：
何が変わり、何に影響し、そして本当に重要なのは何か？
そこからRepoLens Version 2が生まれました。
Version 2は、単にリポジトリを理解するためのものではありません。
変更インテリジェンスのためのものです。
この考え方の転換が、私のプロダクトへの見方を変えました。
誰かが一度リポジトリを理解するのを手助けするだけでなく、RepoLensを実際のエンジニアリングのループの中で役立つものにしたいと思うようになりました：
- プルリクエストが開かれたとき
- ブランチが変わったとき
- APIが移動したとき
- アーキテクチャがズレ始めたとき
- チームがレビューやリリースの前に明確さを必要としているとき
What Changed in Version 2
RepoLens Version 2は、より構造化され、より信頼できる形で、チームが変更を理解するのを支援することに今は焦点を当てています。
これで次のことができます：
- プルリクエストを分析し、エンジニアリングサマリーを生成する
- 影響を受けるモジュールを検出する
- 変更されたエンドポイントを検出する
- レビューで重要になりそうなホットスポットを強調する
- ブランチに配慮したチャットおよびPRに配慮したチャットをサポートする
- 正確なコードスニペット参照と、信頼度のシグナルを表示する
- 毎回のフルリビルドではなく、インクリメンタル解析を実行する
- GitHubイベントから自動的に同期する
- アーキテクチャのズレを検出する
- 重要な変更や失敗した解析実行についてアラートを送る
- ワークスペースの利用状況と運用ヘルスを追跡する
この取り組みによって、プロダクトのストーリーはかなり明確になりました：
- Version 1： どんなリポジトリでも素早く把握できる
- Version 2： 何が変わり、何が重要かを把握できる
この明確さは、作り手として私にとって最大級の成果のひとつでした。
What I Learned Building It
RepoLensを作って得られた大きな学びのひとつは、汎用的なAIの出力だけではエンジニアリングのワークフローには不十分だということです。
要約を生成するのは簡単です。
エンジニアが実際に信頼できるものを生成するのは、はるかに難しいです。
つまり、このシステムは「コードについて話す」こと以上のことをしなければなりません。
まず、リポジトリとその変更について構造化された理解を構築し、その構造の上にAIを適用して、出力をより有用で、根拠があり、検証可能なものにする必要があります。
それが、これまでのRepoLensにおけるほぼすべてのプロダクト判断を形作ってきました。
私はRepoLensを、十分な根拠のない“それっぽい”答えを出すだけの別のツールにしたくありません。
チームが次のことを見られるようにしたいのです：
- その答えがどこから来たのか
- 何が変わったのか
- 何が影響を受けたのか
- 何に注意を払うべきか
The Product Hunt Launch
Product HuntでRepoLens Version 2をローンチし、#7まで到達したのは、可視性が高まっただけでなく、そこで生まれた種類の会話のおかげで、励みになりました。
最も興味深いフィードバックは、抽象的な「AI」についてのものではありませんでした。
とても実践的なエンジニアリングの問いでした：
- 重複するPRはどう扱うのですか？
- 変更されたエンドポイントの検出はどれくらい信頼できますか？
- 単一のフレームワークを超えて機能しますか？
- 日々の開発で実際に役立つのはどのシグナルですか？
まさに、私が望んでいた種類のフィードバックでした。
これは、プロダクトが「面白いデモ」領域から「本当にエンジニアリングのワークフローに収まるのか？」領域へと動き始めていることを意味します。
私は、その転換が最も大切だと思っています。
Where RepoLens Is Going
RepoLensは、リポジトリをより早く理解するための方法として始まりました。
今は、変更をより早く理解するための方法へと進化しつつあります。
それは、より重要な問題のように感じます。
というのも、チームはコードを読む手助けだけを必要としているわけではありません。
変化していくシステムを推論する手助けが必要なのです。
それが、RepoLensがこれからもどんどん良くなっていってほしい点です。
Links
ライブプラットフォーム
https://repolensai.com
オープンソースの分析エンジン
https://github.com/mohosin2126/repolens-community
Product Huntローンチ
https://www.producthunt.com/products/repolens
素早く動くリポジトリで作業しているなら、ぜひ知りたいです：
どのシグナルが、あなたのチームの時間を最も節約できるでしょうか？
- PRサマリー
- 影響を受けるモジュール
- 変更されたエンドポイント
- レビューのホットスポット
- ブランチに配慮したチャット
- アーキテクチャのズレに関するアラート
