Stripeの開発ブログでミニオンについての話をチェックしてみて。方向性が似てる気がするよ。

いい仕事だね！自分も既存のJiraプロジェクトでワークフロー別にカンバンを動かしてるエージェントを持ってるから、今日HNであなたのプロジェクトを見れて嬉しいよ。あなたの作業を追いかけるのが楽しみ、シェアしてくれてありがとう。

Windsurfってオープンソースなの？

ここに問題は見当たらないけど、どう思う？それに、Linearもこれに取り組んでるみたいだし。

カンバンボードからエージェントに引き継ぐのを助けるアプリはいくつかあるよね。でも、もっと「人が関わる」感じが必要なんだ。変更セットの可視性がなくてエージェントに引き継ぐのは、私には合わないんだよね。https://www.agentkanban.io では、VS Codeの拡張機能を使ってGitHub Copilot Chatと連携したタスクボードがあるから、タスク管理とチャットからタスクへのコンテキストキャプチャの両方の利点があるんだ。これで、トップハーネス（VS Code）とタスク/プロジェクト管理機能を同時に使えるよ。

テーブルステークって何？

「こんなツール」って何？もしAIがエージェント的なら、PMがエージェントのラルフループをJiraに統合するのに1時間くらいチャットすると思うんだけど。JiraやTrello、Linear、BasecampにはAPIがあるし、どのエージェントもそれを使って話せるCLIがあるはず。開発者やSaaSは、作業を始めるときにタスクがチェックアウトされて、指示が含まれていることを理解するのに必要ないと思う。終わったらチケットをDONEに移すだけでいいのに。

彼らのページによると、これを動かすにはクラウドアカウントのログインが必要らしい。ローカルでもそうだから、試してみるのはやめたんだ。正直、見た目はクールだね。でも、クールに見えるツールは結構たくさんあるから。

https://github.com/openai/symphony

同じ製品だと思ってたんだけど。どっちか使ったことある人いる？

自分も同じことを考えてる。管理してる人からよく聞く答えは、コードを見ないか、少なくとも詳細には見ないってこと。個人的には、エージェントが出したものをいつも調整しちゃうんだよね。そのコントロールを手放すべきか悩んでる…

エージェントの活動の多くは、以前に作られたものを見直して、レビュー用にデスクに届くものに対して合理的な期待を持てるように制約をかけることなんだよね。俺は、しっかりしたファイル構造が助けになると思ってる。3,000行のファイルをレビューするのは本当に苦痛だから。人間でも機械でも、それは受け入れられないよ :) 適切な場所に複数のファイルがあると、認知負荷が減るんだ。時々、エージェントとインタラクティブにレビューすることもあるよ。最初にレビューすべき重要なファイルはどれかとかね。変更を「LGTM」っていう山にまとめるのが好きなんだ。で、もし変更が必要なら、エージェントに「未ステージの変更をレビューしてほしい - ここは違うことをしてほしい」って頼む。

ほとんどの話はAIがすべてのコード、もしくはほとんどのコードを書いているってことだけど、人間がレビューしたコードの割合は、誰も気づいてないし認めたくもないけど、ゼロに近づいていると思うよ。

ここ数週間、趣味のプロジェクトに取り組んでるんだ。古いソフトモデムのバイナリをCコードに変換してる。既存のモデムを使って、テストベクターを作るためのリギングを構築させたんだ。モデム内の作業を指定させて、legacyが新しいコードと同じストリームを生成することを確認したりもした。テストベクターを他のモデムと比較したりもしてる。今は、ターゲットを絞ったリファクタリングやコード削減プロジェクトに取り組んでる。コードはほとんど見てないけど、100KSLOCの塊があって、デコンパイルよりはずっとクリーンだけど、自分が書くものよりはかなり汚い。あまりファクタリングされてないけど、これを70KSLOCにまで削減できる希望はある。そうすれば、小さなブロックで受け入れられると思う。元のソフトモデムよりもパフォーマンスが良くて、同じライン品質でより高いRXレートを達成し、CPUも少なく使ってる。さらに機能も追加されてる。だから、趣味でこんな大きなものを書くことはなかったと思う。これまでに200ドルと数週間の間に20-30分かけて、最終的には信頼できる大きな機能を持つものを作れると思ってる。

それは状況によるね。もしマルチスレッドコードの1万分の1のレースコンディションに取り組んでいるとき、エージェントは何が起こっているのかを理解するのに数時間かかる。俺はおそらく数週間かかるだろうけど、実際にはいくつかの問題はエージェントに向ける前に諦めちゃったからわからない。

誰もコードをレビューしてないよ。マネージャーたちもコードレビューを望んでない。ボトルネックになるからね。何か問題が起きたら（バグ）、その都度修正されるだけ。ソフトウェアエンジニアリングの非常に悲しい時代だよ。もし我々の業界にエンジニアリングがあったとしても、今はほとんどなくなってしまった。みんな適当に「バグを出さないでください」とか「あなたはオーナーであって、借り手ではない」とかの「スキル」ファイルを書いてるだけ。ほんとに低い努力で、非常に不確実なんだ。大きなアプリがAIの粗雑さで常にダウンしてる（例えば、Github）し、あまり人気のないシステムでもそれが頻繁に見られる（例えば、俺の会社や他のSaaSでも）。プロダクトマネージャーはコードに興味を持たない。エンジニアリングマネージャーも、エンジニアだった頃ほどコードに関心を持ってない。ディレクターはコードなんて気にしない。CTOはもうコードがどう見えるかもわからない。我々はチェーンの最後にいて、かつては良いコードに基づいて良いシステムが構築されることを知っていたから、よく書かれたメンテナブルなコードに誇りを持っていたのに、今は自分たちを危険にさらしている。エンジニアである我々がもうコードに関心を持たなくなってしまって、AIによってその問題がさらに悪化している。

普段は、Claudeに夜の作業の後に約500行のコードを書かせることを目指してる。大体は色んなアプローチを試して、それをまとめて、レビューして修正するための比較的小さな差分を出してくれる感じ。

うん、マルチエージェントのワークフローはあんまり満足できてないな。チャットを同時にたくさん動かそうとすると、どんどん迷子になっちゃう。レビューした後はClaudeに計画を正しく実行してもらうのは信頼してるけど、全部の計画をレビューしないと、見落とした小さな詳細があって後で修正するのが面倒になる。俺は一度に1〜2個のチャットがちょうどいいタイプなんだ。そうじゃないと、プロジェクトのビジョンを維持するのが難しいと思う。

同意するけど、小さなタスク、20行未満で1、2分で理解できるものには完璧だね。考えてみると、パイプラインの改善やツールの移行など、やりたいタスクが何百、いや何千もあるけど、時間がないんだ。唯一の疑問は、やる時間がないなら、プロンプトを出す時間はあるのかってこと。

コードの品質を気にする人もいるけど、そうじゃない人も多いよね。今週、6000行のクラスが大丈夫だって言われたことがあって、それはモデルが理解しやすいからで、人間の理解よりも重要だって。彼の言いたいことは分かるけど、それは大きなリスクだと思う。

Vibe Kanbanは本当に便利な機能が詰まった宝の山だよ。ここ1、2週間、新しいツールをVibe Kanbanと同等にするために追加の改善をしてる。Vibe KanbanのDiscordにもいくつかのスクリーンショットを投稿してる。最終的にローンチできるときには、君のユースケースにぴったり合うといいな。俺のツールは、KanbanボードとエージェントのワークスペースでVibe Kanbanよりも良い機能を目指していて、デスクトップウィンドウ、プラグイン、ブラウザ内VSCode統合、htmxのようなサーバーレンダリングUIなどの追加システムも加えてる。リモートアクセスも異なっていて、OpenClawのように全体をホストして、ブラウザからリモートデスクトップUIにアクセスする形になってるんだ。

競争相手は存在するよね。

direnv使えばいいんじゃない？ローカルページのホストするポートを調整する必要があるかもしれないけど、それはN=作業ツリー名に基づくハッシュのモジュロで、ポートはデフォルトポート+Nって感じ。クラウドにこれを設定するように言ってみて。1回のプロンプトでできるはずだよ。

仕事でこんな問題があるんだけど、CCにすごくシンプルなbun CLIツールを作ってもらうよう頼んだんだ。これが結構難しいんだよね。作業ツリーを作成、削除、リストするためのツールで、CLIがその作業ツリー用のURLやDBで.envファイルを初期化するんだ。それから、Vercelのオープンソースパッケージportlessを使って、ユニークなポートで開発サーバーを立ち上げて、作業ツリーごとにURLを取得してる。