HN公開: Haystack – 無限キャンバスでコードを探索・編集するIDE
(haystackeditor.com)- HaystackはPRの会話履歴と変更内容をあわせて読み、実際に人の判断が必要な変更だけをレビュアーに回すコードレビューツールとして提示されている
- 問題のないPRは自動マージし、危険なPRは選別対象として分類して、「human code review time to zero」に近いフローを目指す
- 例のPRでは
tenancyInit()とcacheWarmup()をPromise.all()で並列化し、コールドスタートを約4秒から2.4秒に短縮したが、過去の実行順序の決定を覆している - Haystackは会話履歴から、
cacheWarmupはtenancyInitの後に実行されるべきだという根拠を見つけ、サンドボックスで50回の起動中31回クラッシュしたことを確認する - 問題のあるPRは元の順序を決めた
@mayaに渡され、壊れた設計判断と失敗結果がPRに添えられることで、レビュー判断にかかる時間を減らす
PRレビューを自動選別するフロー
- HaystackはすべてのPRの会話履歴と変更内容を読み、リスクを判断する
- 危険なPRはエンドツーエンドで実行して検証し、人の判断が必要なときだけレビュアーを巻き込む
- 画面には16件のPRをHaystackが選別している様子が表示される
- TypeScript、JavaScript、C、Python、Ruby、Go、C++など複数言語のPRが並ぶ
- 各PRは
analyzing状態で表示される
危険な変更の例: サービスブートストラップの並列化
- 例のPR
platform#3120 feat: parallelize service bootstrapは、サービスのブートストラップ段階を並列化する変更である - 既存コードでは
tenancyInit()を実行したあと、cacheWarmup()を順次実行する - 変更後のコードでは、2つの作業を
Promise.all([tenancyInit(), cacheWarmup()])で同時に実行する - PR説明によれば、コールドスタートは約4秒まで伸びていたが、並列化後は約2.4秒に短縮された
- 既存テストはすべて通過するため、表面的には承認しやすい性能改善に見える
会話履歴から明らかになった設計判断
- HaystackはPRの背後にある履歴を読み、この変更が過去の設計判断を覆していることを見つける
@mayaは、cacheWarmupが空の設定を読まないように、tenancyInitが先に完了すべきだと求めていた- テストスイートにはこの実行順序を検証する項目がないため、回帰がテストを通過してしまう
- Haystack reviewはPRに次の情報を添える
- 会話履歴に残っている判断
- 現在のPRが実際に変更する動作
- テストが通過した理由
実行検証と失敗結果
- Haystackはコードを読むだけで止まらず、変更を実際に実行する
- 会話履歴がテストにないタイミング競合を示しているため、サンドボックスでサービスを50回起動する
- 50回のうち31回で、
cacheWarmupがtenancyInit完了前に空の設定を読んでしまう - その結果、サービスは最初のリクエストで例外を投げてクラッシュする
- Haystack QAは、実行した理由、実施したテスト、壊れた箇所をPRにあわせて表示する
人によるレビューが必要なポイント
- HaystackはこのPRを自動マージせず、元の実行順序を決めた
@mayaを参加させるよう推奨する - PRには壊れた設計判断と失敗した起動結果があわせて表示される
- レビュー画面には「Request review」「Chat with @maya」「Doesn’t need review」といった選択肢が表示される
- Haystackのフローは、大半のPRを自動マージし、例のような危険な変更だけを適切な人に回すことに焦点を当てている
1件のコメント
Hacker News の意見
AI 機能についてはよく分からないが、キャンバス上でコード作業をし、フローチャート UI も併用するという考え方は、ずっと前から望んでいたもの
主にデータ処理をしていて、パイプラインを説明したり自分で理解したりするためにフローチャートをよく描く
こういう方向性の開発 UI があれば、CS 専攻ではない人たちが作った扱いにくいコードベースを相手にするのに良さそう
https://www.ni.com/en/shop/labview.html
視覚的なドキュメント化がずっと簡単になりそう
本当に素晴らしい。メソッドや宣言へ移動するとき、ファイル全体を定義位置までスクロールした補助タブとして開くのではなく、関連するコード片だけを見せてくれる点が気に入った
メソッドが呼び出される場所と定義を比較する必要があり、読んでいたメソッドをよく見失うのだが、それがかなりもどかしい
メソッドを横に「固定」しておき、固定されたビューでうっかりファイル全体をスクロールしてしまうことなく眺められるのが良い
少し使ってみたところ、残念ながらマウス中心の傾向が強く、別のメソッド内のメソッドをたどっていくと、管理すべき浮動ウィンドウが多くなりすぎた
どのウィンドウが「親」ウィンドウなのか追跡できるように矢印や線があれば、一種のフローチャートを作りやすそう
個人的に惜しい点はあるが、この領域で別の考え方を見られるのはうれしいし、成功してほしい
コードの何がどこにあるのかをある程度把握していることは有益だと思う
何年も1つのプロジェクトをやっているのに、小さな断片だけを見て作業するせいで、各ファイルがいったい何をしているのか分からない状態になることもあり得るのではないか
コメントとテキストが混在した元のコード、そして整形済みテキストとナビゲーション用ハイパーリンクを含む見やすく組版されたコードがある
http://literateprogramming.com/
「親ウィンドウ」の基準点として何を想像しているのか気になる
特定のウィンドウをアンカーとして指定したいのか、それとも何らかのヒューリスティックがそうしたアンカーを見つけてくれることを望んでいるのか知りたい
リリースおめでとう。最近は完全に逆方向に進んでいて、集中力や ADHD 傾向のせいであちこち飛び回って圧倒されるのを減らすのに役立っている
ウィンドウ1つ、すべてを最小化、そして最も重要なのはツリー探索をなくすこと
ファイルに移動する必要がある場合は、Intellij の最近使った項目メニューを使うか、ファイルマーカーへジャンプする
つまり、ファイルマーカーを覚えていて、そこへ行く意図がある必要があるということ。vim ショートカット用に IdeaVim プラグインを使っている
自分にとっては、この方式のほうがプログラミングをはるかに集中できて楽しいものにしてくれる
マルチスクリーンからワイドスクリーンへ移り、そこから再び単一画面へ戻った変化の一部
言及されているような大規模で成熟したコードベースでは、LLM を道案内に使っている
私の経験では、LLM はファイル1つだけを相手にしても、かなり多くのミスや仮定をする
私の経験では、LLM に機能の流れがどこにあるか聞くと、入口はうまく作ってくれるが、細部はしばしば自分で把握する必要があり、時には関連はあるが探していたものとは違う場所を指すことがある
興味深い。いくつかメモがある
Obsidian には「Canvas」という似た機能があるので、そのワークフローは参考になりそう
自分にとってはスタンドアロンツールとしては役に立たず、Idea プラグインとして必要
レイアウトを作る部分が一番嫌い。Git パッチやバグ修正を受け取って、それに合ったレイアウトを作ってくれる AI があるとよい
レイアウト共有は非常に簡単であるべき
Git 履歴をもう1つの次元として統合できるとよい。エディタ内に diff と blame 表示まで入るとよい
AI 学習に使えるデータ、つまり Git コミットがある
デバッグももう1つの次元として統合し、プロファイラデータも統合できるとよい
そこで提供されるものはそのまま得られるということ
Idea 系のツールを使っているなら、現時点では方法がなさそう
こういうものをずっと前から試してみたいと思っていました。アップデートを受け取る方法はありますか？
特に、最初に試す段階だけでも AI機能をオフにするオプションを待っています
関数の中へズームインして、ファイルの残りを隠せる機能が特に良いです。こういうものが欲しいと思った瞬間が意外と多くありました
1つのファイル内で、いま作業している関数を簡単に横にドラッグして並べ、単一ファイルを仮想的に再配置するような使い方もできそうです
編集インターフェース以外にも、エディタの中には可視化の機会が多いと思います
自分のコードとサードパーティ依存関係の相互作用、自分のコードの依存関係/呼び出しグラフまたはその一部、クラスやモジュールレベルの依存グラフ、オブジェクト内部の呼び出しグラフへドリルダウンするようなネストした呼び出しグラフなどが考えられます
これらのケースではいずれも、可視化と編集の間をシームレスに行き来できることが、このツールが目指しているように見えるキラー機能です
エディタにグラフィックが入るだけでも、コード変更頻度のヒートマップ、コード性能のヒートマップ、変数使用の追跡など、さらに多くの興味深い可視化が可能になります
https://adamtornhill.com/articles/crimescene/codeascrimescen...
最後に、The Programmer's Brain を読んでいないなら、このポッドキャストだけでも聴いてみるとよいです
https://se-radio.net/2021/06/episode-462-felienne-on-the-pro...
私たちの脳の働き方に関係する編集アイデアはたくさんありますが、エディタで十分にサポートされているのはまだ見たことがありません
すでにその方向へ一歩踏み出しているので、さらに多くの機会があるかもしれません
最善の方法を考えてみますし、最終的には製品内で直接アップデートをプッシュする予定です
いままさに copilotのオプトアウトを追加しているところです
ここにあるアイデアは良いものばかりで、いくつかは一緒に議論したいです。よければメール/DMを送ります
全体としていろいろな人と話したいですし、feedback@haystackeditor.com でフィードバックを受け取れます
関数から関数へ、ファイルからファイルへ、そしてまた戻ってくる探索方法が本当に気に入っています
もっと便利にするには、ブラウザの履歴のようなナビゲーション履歴ウィンドウがあるとよさそうです
ファイルと関数の間を移動するときに一覧を表示し、開いているウィンドウを苦労して探し回らなくても、前後へ移動したり、履歴内の任意の位置へ直接ジャンプしたりできるとよいです
ここで言っているナビゲーション履歴は、編集履歴とは完全に別物です
編集の取り消し/やり直しがナビゲーション履歴を前後に動かしてはいけませんし、その逆も同じです
もちろん、ナビゲーション履歴を行き来するキーボードショートカットはあってよいです
素晴らしいです。Code Bubblesと関連があります: https://dl.acm.org/doi/abs/10.1145/1753326.1753706
「コードを保存したりログに残したりはしません。探索用copilotの入力としてコード片をOpen AIに送ります。近いうちにこれを無効化するオプションを追加します。」
そのオプションが入ったら確認してみたいです
コマンドパレット（CMD+SHIFT+P）を開き、“Opt out of navigational copilot” コマンドを使えばよいです
Windows/Linuxも近日対応予定です
存在しない関数を呼び出しているという診断がある場合にのみ、Open AIへデータを送る点も覚えておいてください
キャンバスベースのエディタ（Code Bubbles）、従来型のタブベースのエディタ（Eclipse）、そして私が設計したカルーセルベースのエディタ（Patchworks）の探索時間の比較に関する論文を出しました
キャンバスは自由度が高すぎるという結果でした
https://austinhenley.com/pubs/Henley2014CHI_Patchworks.pdf
振り返ると、VS Codeでももうタブは使っていません。開いているファイルが多すぎるからです
ただ一度に1つのファイルだけを見て、切り替える必要があるときはCmd-Pで検索するか、最近使ったファイルの間を移動しています
うまく機能していますが、ファイル/ディレクトリ名を常に頭の中に入れておく必要があります
メソッドを探す作業は、アルファベット順のアウトラインビューがあれば、はるかに問題にならなかったはずです
よければ話してみたいので、メールします
複数のワークスペースにまたがってコードパネルを4〜6個置き、SPC TAB 数字で切り替えています
ツールをきちんと使うには、十分なワイドスクリーンも事実上必要です
要点は、ファイルを縦方向ではなく横方向に扱うことに慣れることです
この縦方向の思考は、初めてHello Worldを書いたときのやり方にかなり深く根差しています
リリースおめでとうございます。素晴らしく、よく実装されたツールに見えますし、試してみるのが楽しみです。
以前から欲しいと思っていて、何度か手作業で作ってみたこともあるものの、共有できる形にはできなかった機能を思い出しました。コードの経路を1つのスクリプトやソースファイルに展開する機能です。
ブレークポイントのようなものを設定して「unravel」ボタンを押すと、その地点までに起こるすべての動作を示す単一のファイルが残るといいなと思います。
理想的には、そのファイルが単一のスクリプトとして実行できればなお良いです。
本質的にはステップ実行デバッガが提供するビューと同じですが、複数のファイルや複数の階層を参照するのではなく、最初から最後まで1つのファイル内ですべて見たいのです。
人々が要件、パラメータ、結果ではなく具体的な実装の詳細に注目すると、多くのことが伝達の過程で失われると思います。
なぜこの実装を望んでいるのか、どんな機能や目的を果たすべきなのかが気になります。