もしコードの出力を素早く検証・修正するのが得意なら、95%の確率で当たるのも理解できる。でも、私が自分や他の人のコーディングエージェントの出力を検証してきた限りでは、もっと低い確率だと思う（データエンジニアリングやデータサイエンスの仕事）。それに、同僚の中には質に関係なく生成することにハマってる人もいる。ワークスロップは本当に存在する現象だよ。

その95%のペイアウトは、良いものがどう見えるかをすでに知っている場合にだけ成り立つ。怪しいのは、正しいものとほぼ正しいものの違いが分からないときだ。そこが問題になるんだよ。

それは、得意なことに使っている場合の95%だよ。人は必然的にそれを超えて押し進めようとする（それは自然なことだよね！）、そして能力の限界で運用していると、成功率は最終的に下がる。

95%の確率で当たるスロットマシンにハマっている感じかな。 “スロットマシンのようではなく、スロットマシンのような…使っていて気持ちいいもの” それはさておき、もしスロットマシンがあなたの仕事を95%の確率で正しくやっているなら、あなたがそのスロットマシンが仕事をうまくやっていないときに気づいていないか、スロットマシンが得意な仕事だけをするように自分の働き方を変えてしまったかのどちらかだね。

オンラインカジノのペイアウトは、95%以上が普通だってことを指摘したいな。100%未満なら、ハウスが勝ち続けるからね。

そうそう、「時計の時間」（時間）と「カレンダーの時間」（日/週/月）があるって感じてる。人々に「もっと働け」って押し付けるのは、工場でウィジェットを生産するように、我々の生産性が時計の時間に基づいているという誤解に基づいてる。創造的な活動やアートのように、カレンダーの時間に基づいているわけじゃない。LLMが1時間でリクエストしたコードを出してくれても、使ってみてどう感じるかを処理するのに数日かかるんだ。簡単だからってレバーを10回連続で引きたくなるけど、今は人間としてその変化を処理するのに数週間かかる。これは自分の個人的なプロジェクトだけの話で、ビジネスのインセンティブはもっと強烈だろうね。でも、どんなに素晴らしいソフトウェアやインターフェースでも、顧客が数時間でお金を払うようにはならないって事実は変わらない。

スロットマシンにハマってるみたいなもので、95%の確率で当たるから、うまく騙せるってわかってる。でも、<100%の確率が実際にスロットマシンが中毒性を持つ理由なんだよね。連続して当たると、その行動は長続きしない。これを部分強化消失効果って呼ぶんだ。

Yeggeの最近のブログ記事がこの現象を反映してるって言おうと思ったんだ。あと、hbr.orgにこんな記事もあるよね。https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... これは本当にあることで、クラシックな中毒みたいだね。

$200のプランにいるのは変なモチベーターだね。未使用の週の制限を見て、カウントダウンしてるのを見ながら、すでに支払ったから「無料」でGPT 5.2 Proをスパムできるって知ってる。

ありがとう、スティーブ・イェッジのやつはすごく良い読み物だった。

ギャンブルの例えは、よくよく見ると完全に崩れちゃうね。スロットマシンは、設計上、報酬のスケジュールが変動するようになってるから、すべての要素がデバイスに長く留まるように最適化されてるんだ。ソーシャルメディアもエンゲージメントを最適化してて、強迫的な行動がその結果として出てくる。最適化の対象が中毒を生むんだよ。間欠的な変動報酬は、設計によるものでも副産物でも、強迫的な行動を引き起こす。これはクロードにも当てはまる。

Anthropicの最適化の目標って何なの？？？ できるだけ早く正しい答えを出すことだよ！ 彼らがエンゲージメントの指標を測ったり最適化したりしてないって本当に確信してるの？だって、少なくともOpenAIは提供してるすべての製品でそれをやってると思うよ。

そうだね。使えば使うほどお金が入るプラットフォームは、できるだけ少ないトークンで正しい答えを引き出すように最適化してるに決まってる。どの企業にとってもそれをするインセンティブは全くない。インセンティブは、モデルをちょっと悪くして、戻ってくるようにすることだけど、あまりにも悪すぎて競合に行くようにはしたくない。これまでにその様子は見てきたし、Googleが収益を上げるために検索結果を悪化させたことも知ってる。同じインセンティブがここでも働いてるけど、さらに悪化してる。

Anthropicの最適化目標は何？？？できるだけ早く正しい答えを出すことだよ！それはちょっと優しい解釈かもね。正しいかもしれないけど、彼らは君がすぐに正しい答えを得るとあんまりお金にならないんだ。君が「次回こそは」と思わせるためにできるだけ多くのトークンを使わせた方が、もっとお金が入る。実際にそう最適化してるとは言わないけど、チャーリー・マンガーが「インセンティブを見せてくれれば、結果を見せてやる」と言ったからね。

Anthropicの最適化目標は何？？？できるだけ早く正しい答えを出すことだよ！どうしてそう信じるの？現在の主要プロバイダーのトレンドは、できるだけ多くのエージェントを立ち上げさせて、請求額を増やすことのように見えるよね。> スロットマシンは設計上、変動報酬スケジュールを持ってる。主要プロバイダーのLLMsは、君を引き込むために完全には理解できない方法で最適化されているRLHFを使っている。これらは非常にナイーブな仮定だよ。AnthropicやOpenAIなどは、君が「すぐに答えを得る」ことに興味があるわけじゃない。彼らが気にしてるのは、君が支払い続けて、すべての数字が上がることなんだ。これは君への親切でやってるわけじゃないし、これらのシステムが君の利益のために最適化されているとは思えないよ。> LLMが出る前から、俺は物を作るのに夢中だった。これからも夢中で作るよ。「ギャンブル仮説」の核心的な主張は、多くの人が本当に物を作っていないってことだ。はっきり言うと、君に特に当てはまるかどうかは分からないけど、たぶんそうじゃない。でも、これが君に特に当てはまらないからって、しっかりした議論じゃないってわけじゃないよ。

Anthropic自体がCCをスロットマシンと表現してるよ。https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135a... (cmd-f "スロットマシン")

ギャンブルの例えは、よく見てみると全く成り立たないね。うん、ブルースカイの埋め込みは、OP自身よりも俺が体験してることに近いと思う。

ありがとう！なんでこんなに多くの人がダークパターンをどこにでも見たがるのか理解できない。全ての議論は大きな反論を見落としてる：競争相手がいる世界では、たとえ無料でも、ふざけてる場合じゃない。ちゃんと動かす必要があるんだ。私にとってはスロットマシンじゃない。人々は一体どうやって使ってるの？もしそうなら、他のところにお金を使うよ（例えば、kimiとかopenrouterとか）。できるだけ正確に私の仕事をしてほしい。それが彼らのビジネスなんだから。テック系の人たちが経済について語るのは本当に痛い。「企業は悪い」っていつも言ってるけど、まるで彼らが真空の中に存在してるかのようだ。

反対だな。不安定さは道具のせいじゃなくて人間のせいだから、解決できない問題なんだ。完璧なLLMでも、非自明なクエリに対してゼロショットで完璧な出力を出すことはできないよ。人間は必要なコンテキストをすべて提供しないからね。LLMはあなたの心を読めないし、特別な好みがないユーザーや、どうしたいかをじっくり考える時間があるユーザーに動かされない限り、常に不快な仮定をするんだと思う。ジャックポットが来るまで、ほとんど退屈なやり取りが続くと思う。将来の世代は、その領域での人間の好みではなく、デフォルトのLLM出力に自分の好みを合わせるかもしれないけどね。

もう一つ面白いのは、「燃え尽きてるけど質の悪い仕事をしている」状態と「完全に疲れ果てて仕事ができない」状態のギャップがAIによってさらに広がっていること。プロンプトを出すだけのハードルは低いけど、正しいプロンプトを知ってそれを検証するための精神的な努力はずっと高いから、その部分をスキップしちゃう。ひどい仕事を何ヶ月も続けた後、結局全体のコードベースが崩壊することもある。

テック業界の就職市場が厳しくて、AIツールがリアルな成果を簡単に出せるようになってるから、仕事の時間とプライベートの時間の境目がほとんど消えかけてる。これは全然一般的には当てはまらないよ。「すべてのテック企業が996になる」っていうミームがよく出てくるけど、リンクや逸話は同じ数少ないソースに戻るだけ。ポストCOVIDの時期はほとんど誰も解雇されず、仕事も見つけやすかったから、テック業界の就職市場が再び競争が激しくなっているのは確かだね。でも、中央値や90パーセンタイルのテック職がそんなに過酷になって、プライベートの時間が消えつつあるとは思わない。もし、過労をみんながやってることとして普通にしようとしている職場にいるなら、ただもっと働かせるために嘘をつかれてるだけだよ。

今のところ、仕事を自動化しようとしてハマるより、Runescapeを grind したい気分だな。

これも俺の経験だよ。もし、全てのリポジトリをクラウドプロバイダーがサポートする最新エンジンにアップグレードするような大きなタスクを処理してくれたら、一晩中放置できるかもしれない。でも、それでも「ちょっと違う」っていう大量のレビューと再作業が待ってるだけだろうね。

エージェントを7時間ぐらい動かしたのは一度だけだな。Playwrightのテストを生成するために。足場ができたら、各コンポーネントのテストを書くのは簡単なんだけど、でもその時も「放置しておく」ってわけじゃなかった。

今のところの印象は、並行エージェントの話は「AIインフルエンサー」とそのラボの作り話だと思ってる。3〜4のClaudeセッションを動かすことはあるけど、それが「複数のチャット」を持つ唯一の方法だから、無関係なことを聞くためにね。たまにタスクが長引いて複数のセッションを忙しくさせることもあるけど、それはかなり稀で、そうなるのはエージェントが長時間かかるタスク（例えばテストスイート全体）を実行している時だけ。複数のエージェントを使ってフル機能を並行して構築するって話は、俺の経験ではあまり合わないな。まだ複雑さが極めて低いグリーンフィールドプロジェクトなら少しは機能するけど、3x3より大きい機能相互作用マトリックスがあると、システムにバカな仮定をさせないように手を貸さなきゃいけない。もしくは、すごく正確にプロンプトを出す必要があるけど、これにも時間がかかるし、並行処理の状況に入ることを妨げる。機能相互作用マトリックスのサイズは、エージェントによるコーディングがうまくいくかどうか、またどの抽象レベルでうまくいくかの現在の指標「擬似メトリック」になってる。

これについて少し光を当てられるかも。俺は組み込みから来たんだけど、エージェントを効果的に使えたのは、クイックな往復の反復作業ぐらいだった。エージェントはまだ本当に役立ったけど、放置しておくなんて考えられなかった。でも最近、人気のあるフレームワークを使った「フルスタックウェブ」にドメインを切り替えたんだ。エージェントとやり取りしながら、詳細な実装計画を立てて複数のエージェントを使うために、かなりの時間を使うと、彼らが正確に生産できる作業の範囲には限界がないように見える。これは、全体の計画を読みながら、バカなミスや大きな実装ミスをチェックしてからエージェントを動かすからなんだ。特定の部分で作業を並行化できるところや、他の部分でブロックされるところが見えるのもいいし、一度にどれだけの作業を並行化できるかもわかる。準備ができたら、最新のモデルを使わなくても始められることが多い。実際の実装は非常に簡単にプロンプトが出せるから、ほぼ完璧に近い結果が得られる。通常はその横に座って、動いている間に確認するけど、誰かが一晩中動かして、朝に新しいPRを見つけるのも容易に想像できる。誤解しないでほしいけど、全体を「バイブ」させるよりはまだ多くの作業があるけど、実際に実装するよりもずっと効率的なんだ。特に繰り返しのパターンやボイラープレートが多い時はね。* 限界は、実際に自分の頭の中でどれだけ考えをまとめられるか、隅々まで考え抜いた方法で仕様を作れるかにかかってるけど、これはまだ限界だけど、エージェントから来るものではない。1つのドキュメントを実装したら、次に進む時には自分の新しいメンタルコンテキストがあるから、作業がずっと楽になる。

そのエージェントたちは実際に何をしてるの？主に、注目を集める見出しやブログ記事のための素材を提供してるんだよね。実際にエージェントを一晩中動かしてなかったら、良心的に言っても「エージェントが一晩中動いてた」なんて言えないよ。

開発者じゃないけど、いくつかのサイドプロジェクトをやってる。エージェントを使ってると、よく自分のタスクの範囲外の新しい問題にぶつかって、コンテキストがずれちゃうんだ。エージェントに短い問題の説明をつけてGitHubのイシューを作成させて、そのまま現在のタスクを続ける。別のターミナルで新しいエージェントを立ち上げて、「GHイシュー123を調査して」って言うと、そいつが調査を始めて、根本原因を見つけて、修正案を提案してくれる。問題の修正がどのコードの部分に影響するか、他に動かしてるエージェントによって、3〜4のエージェントがほぼ独立してイシューを閉じたり、PRを作成したりできるんだ。エージェントは自分の作業を作業ログに記録して、何をしたか、何がうまくいったか、何がうまくいかなかったか、ツールを使って遭遇した問題を記録してる。大体1日に1回、エージェントが作業ログをレビューして、学んだことをAGENTS.mdに更新してるよ。

もしかしたら、プログラマー版の「ローリングコール」みたいなもんかも。

これに関していくつか役立つ例があったよ。うまくいかせるためには、品質ゲートを定義して、かなり複雑な仕様を作る必要がある。私は個人的に、ゲートを作成するためにhttps://github.com/probelabs/visorを使ってる。コードレビューゲートや、実装が仕様にどれだけ合ってるかを確認するためのものだね。基本的には、エージェントがそれを通過するまでループさせるんだ。特にClaude Codeを使うときの一つのヒントは、「タスク」を作成するように明示的に頼むことと、サブエージェントを使うこと。例えば、すべてのドキュメントを検証して再構成したい場合は、まずドキュメントの状態を調査するタスクを作成させて、その後具体的な詳細ごとにタスクを作成させて、タスクが終わった後に品質を再検証するタスクを作成させる。もっとシンプルなツールを使ってゲートをいじることもできるよ。例えば、https://probelabs.com/vow/ 役に立つといいな！

5.3 Codexを使えば、execplansスキルと具体的な実装タスクを設定することで、1ターンで数時間分の作業ができちゃうよ。それって「寝る前にセットアップして、朝に見直す」っていう範囲に入ってる。ループを設定しておけば、例えばOpenClawやRalphループを使って、さらにその時間を延ばすこともできる。そういう段階に達したら、コードレビューを行うような対抗システム（例えば、CodeRabbitやSourceryを使って）を整えて、自動化してそのフィードバックをコーディングエージェントに返すのがいいと思うよ。

これはエージェントに何をさせるかによってかなり変わるね。ソフトウェアの場合、詳細なAPI仕様を提供して、LLMにクライアントライブラリを作らせることで、結構成功してるよ。エージェントが何を作るべきか分かっていれば、無人で動かしておけるし、ルートや返されるステータス、可能なエラーメッセージを提供してるから、あまり修正も必要ない。人によっては、夜のうちに完全なSaaSlopアプリを作っちゃうこともあるの？もちろん、LLMに計画を作らせて、アプリにやってほしいことを全部盛り込んで、動かせばいいんだよ。