どんな「クラシックなCIバグ」がボット同士を永遠に会話させるんだろう？プロの開発者になってからずっとCIをやってるけど、そんな問題に遭遇したことは一度もないよ。以前に「返信ボット」を作ったことは何度もあるけど、IRCで初めて作った時、ほぼ2、3ステップ目で「うーん、これが自分に返信できるのはおかしいから、ループにハマるな」と思ったんだ。だけど、それは「クラシックなCIバグ」ってわけじゃないから、ここで言ってることとは違うよね？

これが起きたのは初めてじゃないよ。実際、かなり頻繁に発生する問題なんだ: https://github.com/google-gemini/gemini-cli/issues/16723 https://github.com/google-gemini/gemini-cli/issues/16725 https://github.com/google-gemini/gemini-cli/issues/16732 https://github.com/google-gemini/gemini-cli/issues/16734

ご理解ありがとうございます！ × 4609

あのリポジトリには、約10人の長期的な貢献者がいるみたいで、彼らはおそらくメール通知を受け取ってるし、他にも通知を受け取る人がたくさんいるから、これでどれだけのメールが送信されたんだろう？ もし10人がメールを受け取ると仮定すると、24時間以内に46,000通のメールが送られることになる… GitHubがバカじゃなければ、これを緩和するためにメールの更新をバッチ処理してるはず。

もうジュニア社員の居場所がないって言ってる人もいるけど、これらのLLMのスパズムが、ジュニアが扱うには適切な複雑さと優先度のある混乱を生み出してるみたいだね。

「みんな、ただREPLY-ALLを押すのをやめて！」これはボットだけの罠じゃないからね。

ここでの推論呼び出しに誰かが金を払ったの？ これらの返答が全く同じ二つの返事しかないことを考えると、AIなしでも簡単に自動化できるタスクだし、実際の推論が原因だとは思えないんだけど。

オーナーはGoogleの社員だけど、安全のために本物のGoogleの組織が所有してるべきだよね。OSSの組織に移行するように頼んだんだけど、残念ながらGitHubのアプリ作成フローが普通の組織ユーザーにはアプリを作るのを不可能にしてるんだ。だから、個人アカウントでアプリが作られて、負担になることが多い。アプリ作成権を組織メンバーに与えるための作業項目があって、次の6ヶ月間の優先度リストに入れてるよ。支払いについてだけど、私の理解では、gemini cliエージェントを使ってる各組織がAPIキーをアクションのシークレットに入れて、それを使ってGoogleの推論APIを呼び出してるみたい。だから、このコメントがある組織が推論の費用を払ってるってわけ。

空飛ぶ車がないことを嘆いてはいないけど、未来がこんなにバカみたいになったのは残念だな。

これがスレッドだよ： https://news.ycombinator.com/item?id=46636291

笑、それすごいね。こういうのを見ると、イライラする（どうしてこんなにバカなんだ！）し、同時に同情もする（彼らの他の人生はどうなってるんだろう？）

Salesforceは一回だけ使ったことがあるんだけど（強制的に使わされた、笑）、誰があんなの使いたいと思うのか全く理解できなかった。むしろ、巨大なエクセルで全部管理したいわ、マジで。

数年前、顧客が自社のITサポートデスクをCCに入れてヘルプデスクにメールを送ったことを思い出す。うちのヘルプデスクは、そのリクエストを認める新しいメールを完全に送信しちゃって、顧客のデスクも新しいスレッドでそれを認めたんだ。ヘルプデスク同士が喧嘩をやめるのに、1時間と数百件のチケットが必要だったと思うよ！

ルールがどこに埋もれているのか探すのにめっちゃ時間かかったよ。Salesforceって本当に厄介なやつだよね。

20年前の話かもね… 学生の頃、学校にはルールを設定できるメールサーバーがあったんだ。他のメールの結果としてメールを送るように設定できたんだけど、ITは馬鹿じゃないから、一連のルールを設定してた。1. 自分にメールを送るトリガーは設定できない。2. ルールでトリガーされたメールに返信できない。3. メールの最大容量は約50MB（当時は結構多かった）。ある昼休みに、友達が「不在」の自動返信を設定して、私はドメイン内のメールに「不在」と返信するルールを設定したんだけど、相手の名前をTO、CC、BCCに入れたら、ルール#2がトリガーされなかったんだ。友達のメールにも同じルールを設定して、一通のメールを送ったら、約30秒ごとにメールが送信されることになった。数時間後、メールボックスに戻ると、何千通ものメールが溜まってた。ある時点でルール#3がトリガーされて、「容量不足」のメールが送信されて、小さな学校のロゴが埋め込まれてた。これらのメールが私たちのメールルールをトリガーして、「メッセージを送信できませんでした」というメールがまた送信されて、またロゴが埋め込まれてた。必死にメールを削除しようとしたけど、逆にもっとメールが来るだけだった。結局、メール削除の努力を諦めて、授業に行ったんだ。約1時間後、メールサーバーがダウンした。数時間後、すべてのドメインログインが失敗した。ログインもメールサーバーで行われてたことが判明した。その後のITからの話では、* 学生はネットワークディレクトリに作業を保存できなかった。* 新入生はログインできなかった。* 教師は出席を取ったりSMARTホワイトボードを使ったりするためにログインできなかった。* ITがサーバーにログインしようとしたが失敗。* ITがサーバーを再起動しようとしたが失敗。* ITがサーバーを分解してディスクをマウントしようとしたが、理由は不明だが失敗。* ITがサーバーソフトウェアを再構築。* ITが以前のバックアップからデータを復元しようとしたが失敗。どうやらバックアップが完了してなかったみたい。* ITは2週間前の作業バックアップから復旧を余儀なくされた。たった一つのメールルールからこんなことになったんだ。私は6ヶ月間すべてのコンピュータの使用を禁止された。やっとアクセスできるようになったとき、ITオフィスにはログイン中に私の画面を常に表示するスクリーンがあった。時々、ITが私のマウスを動かして、彼らがいることを思い出させてくれた。時にはNotepadを開いて彼らとチャットすることもあった。追記：1年後、ITシステムで何かが起こって、私がログインしているのを見つけた彼らは、私のクラスに駆け込んできて、ドアを突き破って、私のユーザー名を叫びながらキーボードから引き離された。先生はかなりショックを受けて、さらに1年前に私がダウンを引き起こしたことを知ってさらに驚いていた。

プロフェッショナルなGitHubのラベル追加・削除ツールは時代遅れになったね。AGIの実用化が達成されたってことだ。