クラウドで環境を整えるのは面倒だよね。自分の環境で動かす方がずっと楽だと思う。今後しばらくは両方見ることになると思うけど、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の高度な思考能力を使ってコーディングプランを開発していて、より高品質なコードを出力している」

AIがコーディングしてる間にYouTube見るの最高だね。

これについても気になってたんだけど、どうやら統合に向けて動いてるみたい。GoogleのAI Pro/UltraサブスクリプションでもAPI/CLIのクレジットがもらえるとかなんとか -- https://github.com/google-gemini/gemini-cli/issues/1427

それにしても、このGoogle AIがなぜかYouTube Premiumをくれるんだよね（どう関係あるのか全然わからないけど）。Googleのモデルに特有の一般的なテストの一つは、YT動画の理解なんだ。要約、トランスクリプション、ダイアリゼーションなど。彼らのAPIの一つでは、コンテンツを自分でダウンロードする代わりにYT動画のIDを提供できるんだ。

でも、他のUltraサブスクリプションの一部とは違って、YouTubeプレミアムを家族と共有できないんだよね。だから今、両方持ってるけど、Googleから何度か「それはやめた方がいいよ」って言われた。

早くからGoogle for Domainsを使ってて、自分のGoogle Workspaceアカウントを持ってる人は、本当に大変だよね。何もかもうまくいかないから。

AIと一緒にバンドルするのは、エンジニアが自分のYouTubeアカウントの広告をオフにしようとする厄介な内部問題に対処するためなのかな。

皮肉なことに、複雑なサブスクリプションプランは、人々が物を過剰に支払うのに効果的な方法だと思ってる。

同じこと考えてる。Githubの承認プロセスが変化の間に入るのは嫌なんだよね。Claude Codeのキラーフィーチャーは、悪い方向に進む前にそれを止められることだし、その間に自分でコーディングできることなんだ。ジュニアに質問せずにフル機能を完成させさせるの？それとも、困った時にチェックインさせるの？

今のところ、君に同意だよ。Googleはベンチマークで好成績を出して、World Models Genie 3みたいな印象的なモデルをリリースしてるけど、Gemini CLIの提案や変更はちょっと型にはまりすぎてる気がする。まるで、タブとスペースの違いにこだわるOCDのコーダーみたいで、役に立つ機能を作ることよりもそっちを優先してる感じ。最近のプロジェクトでは、Google CLIがその日のトークンを全部、ESLintの設定を調整したり、モジュール化が必要ないコードをモジュール化したりするような些細なタスクに使っちゃった。対照的に、Claude Codeは僕のプロンプトをより良く解釈して、ユーザーのために実際の製品機能を出す手助けをしてくれる。多分、システムプロンプトの問題かもしれない。僕のプロンプトが原因で問題が起きてる可能性もあるけど、Claude Codeは僕の意図をよりよく理解してるみたい。

Source graph ampも結構いいけど、Claudeコードのような洗練さや機能は欠けてる。でも、特にコードレビューのために時々使うことがあるよ。o3に呼びかける「オラクル」ツールがあるからね。

これがまさに、superconductor.devを作った理由なんだ。各エージェントのライブアプリプレビューを提供してるよ。Claude Codeだけじゃなく、Gemini、Codex、Ampもサポートしてる。興味があったら、サインアップフォームにHNって書いてくれれば、優先的に対応するよ :)

ずっと放置してたGitHubリポジトリをつなげて、ちょっとしたことをいじってるだけなんだ。依存関係の更新とか、実際の実装詳細を変えずにコードをリファクタリングしたり、ちょっとした機能やスタイルの更新をしたりね。そういう使い方にはほとんど問題なく動いてるよ。でも、重要な開発を任せるかは微妙かな。

Julesを初めて使ってみたけど、データレイヤーを再構築するのがすごく上手だった。Copilotよりも期待以上だったかも。最初は感心してるけど、これがどれくらい持つか見てみよう。Copilotには感心してたけど、使ってるうちにすごく混乱したり、動きが遅くなったりすることがあって、結局時間を無駄にしちゃうんだよね。これが今のAIの現状だね。

Julesをサイドプロジェクトで使ってみたけど、出てくるコードの質がGH Copilotよりもずっと悪かった。もう一度試してみる価値はあるかも。「Julesは今、Gemini 2.5 Proの高度な思考能力を使ってコーディングプランを開発していて、より高品質なコードを出力している」

サイドプロジェクトでちょっとした変更（カラフルなターミナル出力を追加）をするのに使ったよ。PRは素晴らしかった。LLMコーディングエージェントは、いろんなことに秀でてるけど、ランダムに苦手なこともあるみたい。プロンプトを書いて、あとはPRが生成されるのを待つだけっていうのは楽だよね。それに、失敗しても大した痛手じゃないし、いつでも再プロンプトできるから。