ここ数週間、エージェント（CC、今はPiをテスト中）をEmdash経由で運転してる。やっと生産的なワークツリーのセットアップができたよ。始めた頃はまだ粗い部分があったけど、チームはすごいスピードで進んでるし、懸念事項もすぐに解消してくれてる。ネイティブCLIの上に構築するのは正しい戦略だと思う。

質問なんだけど、もしエージェントがRLでどんどん良くなっていったら、この環境やUIは将来的にどうなるんだろう？5〜10のエージェントを管理するのは大変だってみんな知ってるよね。5〜10のエージェントから100%の集中力で良いPRを出せてるとは思えないんだけど、間違いを犯してる可能性が高いし（他の人もそうだと思う）。だったら、1つのエージェントが5〜10のエージェントを管理する方がいいんじゃない？開発ループのほとんどはbashで進んでるし、エージェントがbashを使うのが上手くなれば、6ヶ月後にはどうなるんだろう？エージェントがワークツリーを横断してエージェントを調整できるなら、これは高い抽象レベルで動いてるとは言えないと思う。

それで、ビジネスモデルはどうなってるの？これはYCの製品なの？それともYCの製品を作ってるときに開発したツールなの？

こんな開発スタイルを試しているところで、今のところの経験から言うと、構築の複雑さがストーリー作成や手動テストのフェーズにシフトしている感じがする。タスクを完全に引き継いで、エージェントに実装を一発でやらせる必要があるから、具体的で明確にコンテキストや目標を伝えないと、ただコードを積み上げるだけになって、管理できないゴミの山ができちゃうかも。新しいUIコンポーネントが必要な変更は、手動調整やUXの詳細なテストが必要になることが多いし、ユーザーがこの段階で期待する体験の仕上げレベルも求められる。こういう風にできるタスクの感覚が出てきて、普通のスプリントの20〜30%くらいはこれに該当すると思う。残りの70%は、AIに改善・修正を指示する前にコードに慣れる必要があるから、リターンが減っていくか、場合によってはマイナスになるかも。これを作る上での経験から、以下についてどう思う？1. あなたの製品は、各タスクを十分な精度で完了させるためのプロジェクト管理や要件収集をどのように減らすの？2. あなたの強みは並列処理にあるようだけど、私の分析を考えると、小さなチームにとっては本当に痛手だとは思えない。これは、主にメンテナンスや強化モードの安定した製品をスケールアップするためのツールとして意図されているの？3. このツールが各タスクのコードを実際にe2eテストする自動化された方法を実装することを想像してる？

こんにちは！新しいものを作ったこと、おめでとう！すぐに調べてみるつもりだけど、ここにいるかもしれないから聞いてみるね：効率的にワークツリーを作成する方法をシステムに簡単に伝える方法はある？私の問題は、いくつかのこと、特にフロントエンド関連の手動テストをしたいんだけど、各ワークツリーにはそれぞれのポートや特有の設定が必要なんだ（例えば、dockerボリュームが衝突しないように）。git config --worktreeがこれを助けるはずなんだけど（すぐに見てみるつもり）、なんか原始的に感じる。Emdashに「新しいワークツリーを作成するときは、このスクリプトを実行する必要がある」って伝える方法はあるのかな？前もってありがとう、そして再度、新しいものを作ったこと、おめでとう！私たちが進んでいる方向に明らかに合ってるね。

GitHubのイシューを読むアプリを作ったんだ。特定のタグが付いていると、バックグラウンドのエージェントがプランを作成するよ。別のタグがあれば、サーバーのエージェントがイシューの会話全体をコンテキストとして考慮してPRを作成するんだ（上のプランを使ったというアイデアだけど、技術的には必須じゃないよ）。PRにコメントすると、エージェントがまたそのコメントをコンテキストとして読み込んで、対応しようとするんだ。すべてがgitとGitHubにあるから、自動的にCIも拾ってくれる。シンプルに見えるけど、何か見落としてるかも。

リモートやモバイルのコントロールプレーンを追加する予定はあるの？CLIを使ったアプローチが好きなんだ。https://yepanywhere.com/も似たようなアプローチだけど、主にモバイル経由のアクセスに焦点を当ててるよ。[デスクから離れていることが多いから] あ、実際に君のアプローチを見てみると、エージェントSDKや--json出力を使ってないみたいだね。ターミナルウィンドウを埋め込んでるだけなんだ。それだとモバイルインターフェースは難しいね。デスクトップに集中している理由がわかるよ、他のプロバイダーとの統合が楽になるから。

こういうカスタムAIツールは、なかなか厳しい戦いを強いられるよね。webdevcodyのAutomaker[0]がその例だ。彼は他の人たちと一緒にオープンソースのエージェンティックコーディングツールを作ったんだけど、これがGitHubで人気を集めたんだ。彼はそれをストリーミングで宣伝したりしてたんだけど、数週間後に「もう自分では使ってない」って理由を語った動画[1]を投稿したんだ。彼はClaude Codeに戻ったんだけど、これは時間が経つにつれてツールやスキルが増えて、みんなが慣れ親しんでいるターミナルにあるんだ。私も似たような経験があるよ。新しい開発時代のためにいろんなツールやIDEをダウンロードしたけど、CLIのClaude Codeや時々Codex（無料トークンがあるから）以外は何も定着しなかった。ターミナルを何回でも簡単に分割できるし、カスタムリクエストでターミナルに書いたり話したりできるからね。そして、誰かがClaudeが持っているものの上に賢いアイデアを思いついたら、次の数週間以内に何らかの形で追加されると思うよ。ベイジアンカーブのミームがここにぴったりだね：- すべてにClaude Code、カスタムIDE/ツール、すべてにClaude Code。[0] https://github.com/AutoMaker-Org/automaker [1] https://www.youtube.com/watch?v=3H_t78QcueA&t=382s

作業ツリーの分離は賢いけど、シェルアクセスで複数のエージェントを並行して実行する場合のセキュリティモデルが気になるな。CLIベースのエージェントを実行した経験から言うと、一番のリスクはエージェントが「暴走する」ことじゃなくて、長時間のセッション中のコンテキストウィンドウのずれなんだ。エージェントが履歴を圧縮して、どの作業ツリーにいるかを見失って、間違ったブランチのファイルを編集し始めることがある。もっと悪いことに、間違ったデータベースに対してテストを実行することも。Gitの作業ツリーはファイルの分離に役立つけど、同じ.gitディレクトリを共有しているから、並行操作中（リベースやreflogの競合）にお互いに干渉することがあるよ。5つ以上の並行エージェントでこれに直面したことはある？ネイティブCLIアプローチはプロバイダーの機能に追いつくために賢いけど、各プロバイダーのサンドボックスを信頼することになるね。プロバイダーによっては、より良いものもあれば、そうでないものもある。ターミナルを完全に置き換えようとするのではなく、このワークフローのためにツールを作っている人がいるのはいいね。

なんでMITライセンスなの？GPLがユーザーの障壁になるなら、彼らが望む例外付きの有料ライセンスを提供すればいいのに。でもMITだと商業団体が君のコードを取り込んで、クローズドソースにして商業化することができるんだ。GPL-3（カスタム商業ライセンスのオプション付き）は、この点でMITよりも優れているように思えるんだけど。この選択がそんなに人気なのはどうしてか、教えてもらえる？