クラウドで環境を整えるのは面倒だよね。自分の環境で動かす方がずっと楽だと思う。今後しばらくは両方見ることになると思うけど、CLIツールやIDE統合の「悪い方が良い」っていうのが、次の2年で勝つと思ってる。

同意するけど、Codexを動かしてるcodex-1モデルが大好きで、pro 2.5は劣ってると思ってる。ほとんどの人がローカルコードを好むのは興味深いね。移動中にスマホからコーディングできるのが好きなんだ。

完全に隔離されてる方が安全だけど、遅くて高くつくよね。時々、CCが暴走しそうになって、手を打つことがある（あまりにも消費しすぎる前に）。この非同期の設定だと、数時間後に見に行くと、めちゃくちゃな状態になってて（何百万トークンも消費してる）。

Codex/JulesはCC/Curserとは全然違うアプローチを取ってるね。ソフトウェアの中で「大聖堂対バザール」っていう論文があったけど、現代版は、1) 自分の大聖堂を作って、ユーザーを自分の家に連れてくる。これはよりコントロールされた環境で、デプロイが簡単だけど、メリットも限られてるし、モデルが分布外でパフォーマンスを発揮できないことを示してる。OpenAIは、ChatGPTエージェントやCodexなど、すべてのエージェント提供にこのアプローチを取ってる。2) もう一つの選択肢はバザールで、エージェントをユーザーのところに持って行って、彼らの環境の中で1000の異なるアプリや要素と相互作用させること。これを実現するのは100倍難しいけど、より適応性のある良いモデルが必要。でも、リターンは高いよ。君が挙げた問題（環境設定や構成など）は一時的なもので、解決可能だよ。

Github-PRモデルのエージェントコード提案は、既存のコードベースで働いている今日の開発者たちが受け入れるのに一番楽な道だと思う。これには理由があるんだ。この開発者たちは、こういう風にコードレビューをすることに慣れているから。でも、限られた人が参加するために設計されたこの既存のプロセスを、潜在的に巨大なエージェント提案を管理するユースケースに押し付けるのは、すぐに脆くなると思う。要するに、提案が増えれば、もっと効率的でスクリプト化できるレビューのワークフローが必要になるんだ。だから、ClaudeやAiderみたいにエージェントとコマンドラインで作業するのが、人間のメンテナが非同期で並列なエージェントの深いスケーラビリティを最大限に活用できる場所になると思う。> 自分でgit worktreesや他のサンドボックスを設定するよりもずっといいよ。これを自動でやってくれるヘルパーライブラリを作ったから、AiderやClaude用にここにあるよ: https://github.com/sutt/agro。FOSSの目的で、MSやOpenAIなどに、開発環境のサンドボックスに彼らのインフラを使わなきゃいけないソフトウェアの生産手段を支配させたくないんだ。それに、いくつかのケーススタディで出力をレビューするためのCLIトリックの使い方についても書いてるよ: https://github.com/sutt/agro/blob/master/docs/case-studies/i...

参考までに、Claudeコードを非同期でGitHub Actions経由で実行できて、@メンションした問題に対しても動くよ。Claudeコードには、これをするためのGitHubアクション設定でリポジトリを自動的にセットアップするスラッシュコマンドもあるんだ。

変だな、俺のデイリータスクの上限が100に上がったんだ。Google Pro使ってるの？それとも無料？それに、60の制限でも、いろんなことに使って一日中使っても10タスクを超えたことはないし、何も失ってる感じはしなかったよ。はっきり言うと、数ヶ月間毎週末使ってるけど、どの日も10を超えたことはないんだ。15あれば十分だと思うよ、特にお金払ってないならね。忙しい週末でも100は絶対使わないと思う。

モデルが本当に良ければこれが好きなんだけど、そうじゃないんだよね。今ならもう一度試してみる価値があるかも。「Julesは今、Gemini 2.5 Proの高度な思考能力を使ってコーディングプランを開発していて、より高品質なコードを出力している」