以前から、なぜ自分は他の人よりずっと多くのバグに気づくのか不思議だった。僕は簡単に週に数百から数千件のバグを見つけ、何もかもまともに動いていないように感じる。だが話を聞く限り、ほとんどの人はそんなことはまったく経験していない。長い間、これは自分のコンピュータの使い方が特殊だからだと思っていたが、時間をかけて気づいたのは、みんな同じバグに遭遇していても、ただ気づいていないだけだということだ。

もしあなたがプログラマでないなら、それはおそらく世界の見方としてはむしろ幸せなのだろう。ただ、プログラマにとっては、この品質／バグに対する盲目を治すことは役に立つと思う。僕は多くの友人や知人に（単にバグを指摘するだけで）それをやってきた。数週間もすれば、そういう傾向のある人は自分でもバグに気づくようになる。

こういうことに気づくせいか、これまでのいくつかの職場では、ディレクターやVP、役員などが、本当に問題を見つけられる（そして必要なら修正したり、修正を推進したりできる）人からの率直な意見が欲しいときに、僕に何かを評価してくれと頼んでくることがあった。何も見つからないこともある（僕が気づかないタイプの問題はあるのだろう）。より多いのは、「軽度」から「中程度」のどこかに入る問題が見つかるケースだ。そして時には、問題が深刻で、率直に言って「そもそも動いていない」と言えるレベルにまで達していることもある。

この最後のカテゴリーは僕にとって少し謎だ。なぜなら、そのモノがどうしてこんな状態になったのかについての社内の議論を遡ってみると、たいてい「素晴らしい」「よく動いている」といったコメントがずらりと並んでいるのに、いざ自分で開いて試してみると、直感に反する回避策をいくつも知っていないとまともに動かない状態だったりするからだ。十中八九、普通のユーザーなら使いこなせないどころか、笑えるほど／腹が立つほどひどい体験をして、友人にそのことを話したくなるようなレベルだ。

この記事の構想はもう10年近く前からあったのだが、ずっと書くのをためらっていた。心のどこかで、自分が知らず知らずのうちに普通のユーザーが踏まないような変なコーナーケースを踏んでいるのではないか、という疑いがあったからだ。だが、製品がローンチして、僕が見たのとまったく同じ問題にユーザーがぶつかって見事にこけるケースを何度も目にするうちに、一般的には、僕が普通のユーザーならやらないような変なことをしているからバグに当たっているわけではないと思うようになった。僕が使ってひどく欠陥があるように見える製品は、おそらく本当に欠陥があるのだ。そして今ではLLMという魔法のおかげで、LLMに多くの面で普通のユーザーのように振る舞わせて、問題がさまざまなシナリオで再現することを示すことさえできる。

いくつかの例

仕事として「それがどれだけちゃんと動くか」を見た具体的な例は挙げたくない。社内の事例は建設的で誰かを責める意図がなくても、外部に再掲されると必ずしもそうは読まれないからだ。なので、あまり面白くもなく、裏付けも弱い「ランダムな」例をいくつか挙げることにする。

少し前に、僕はいくつかのウェブ検索クエリの結果をまとめたことがあり、Google、Bing、Kagiのいずれも結果がひどいことを見つけた。一般に、大手検索エンジンはクエリに対して良い結果を返せず、低品質なSEOスパムだらけのページや、実際に詐欺サイトであるページを返していた。ちなみに、上で述べたスケールで言えば、僕はこれを「深刻」ではなく「中程度」と考えている（深刻というのは例えば、検索エンジンが半分の確率で500エラーを返すとか、結果の大半が詐欺であるとかいったレベルで、僕の中での深刻の基準は、ユーザーが悪い体験をするというより、普通のユーザーがそもそも使い物にならないというレベルだ）。GoogleやBingの検索結果についての僕の評価に異議を唱える人はほとんどいなかったが¹、Kagiについては僕が間違っていると言われた。実際に自分の検索結果を送ってくれた人もいた。どのケースでも、僕の目には良い結果は含まれておらず（例えば季節予報のクエリでは、最新の季節予報がまったく返ってこなかった）、SEOスパムだらけだった。ある人はKagiのフィルター一覧と、そのフィルターで得られた検索結果を、良し悪しの主張なしに送ってくれたが、多くの人は結果が良いと主張し続けていた。実際には、結果は有用なページへのリンクを欠き、スパムだらけだった。唯一例外的に、GitHubを結果のトップに固定するようなことをした場合は、GitHubでホストされているソフトウェアをダウンロードする目的のクエリではうまくいったが、もちろん記事中の他のクエリではまったく役に立たない。

抽象的には、何かのファンである人はその欠点に盲目になりがちだというのは理解できる。例えば、僕はサンプル外の衝突試験での成績を見てVolvoを買って以来、疑問があるとVolvoのフォーラムで答えを探すことがある。10年以上前から存在する信頼性データ（そしてVolvoを扱う整備士の経験談もこれを裏付けていると思う）では、Volvoの信頼性は並から低レベルなのだが、もちろんVolvoのフォーラムは「Volvoは最も信頼性の高い車の一つだ」「データは全部間違っている」と主張する人で溢れている。

テーマにより近い例としては、Blackboard（授業管理ソフトウェア）がある。大学の授業で最も広く使われていた当時、このソフトウェアは学生にも教授にも広く嫌われていた。僕の周囲では、最も広く嫌われていたソフトウェアだったと言っても公平だろう（Visual SourceSafeのようにもっと強く嫌われているソフトウェアもあったが、そうしたものは広く使われていなかったため、全体で最も嫌われているというほどではなかった）。Wikipediaのページにはこうある。

Blackboardは「教育分野で最も嫌われ——ひどく忌み嫌われさえ——している企業の一つ」になっていた。

また、

2011年12月、Fast Companyは、Amplicateの顧客意識調査の回答者の93%が同社を「嫌っている」と報じた。

僕がまだずっと若く、遠慮というものを知らなかった頃、Blackboardで働いている人に会ったとき、考えなしに「あんなにみんなに嫌われているソフトウェアを作るのはどんな気分ですか？」といったことを口走ってしまった。幸い、相手はまったく気を悪くするどころか、むしろ困惑していた。彼らは、自分たちのソフトウェアはユーザーに本当に好かれている、広く愛されているソフトウェアだと思っていたからだ。僕の言ったことを信じようとせず、僕の方が勘違いしていたということにして、その場は別の話題へと移った。当時、ずっと若くナイーブだった僕は、自分の周りではおそらく最も広く嫌われていたソフトウェアが、会ったその社員（そしておそらく他の社員たちも）にとっては本当に好かれているソフトウェアだと思われていると知って、本当に驚いた。

Volvoのフォーラムがああなるのは理解できる。今の車は全体的に十分信頼性が高く、故障を経験することがほとんどないため、「データが間違っているに違いない。だって自分の車は一度も故障したことがないんだから」となりやすいからだ。僕にとってより謎なのは、スパムだらけの検索結果を見ておきながら、特定の検索エンジンのファンだからといって「結果は素晴らしい」とメッセージを書き殴れる人がいることや、嫌われていることで有名なソフトウェアを「ユーザーは概ね気に入っている」と思える人がいることだ。僕が話す人全員がそれがいかにひどいかを語り（しばしば自発的な不満として）、人々がどれだけそのソフトウェアを嫌っているかを論じるニュース記事があり、ほぼ普遍的な嫌悪がWikipediaのページにまで書かれているというのに。Blackboardに似た別の例としては、Discourse（フォーラムソフトウェア）のウェブパフォーマンスが挙げられる。この記事を書くきっかけの一つは、Discourseはパフォーマンスが素晴らしいと考えているDiscourse社員との議論だった。これが興味深かったのは、Discourseには実際にページの読み込みを遅くするコードが含まれていたからで、それはLCPのようなウェブパフォーマンス指標でごまかすためだった。それは単にベンチマーク向けに最適化するというレベルをはるかに超え、ユーザーにとって何の利益もないどころか、実際に害を及ぼす不正のレベルにまで達していた。あるレベルでは、そのような不正を実装し、ユーザーがうっかりその不正を台無しにしないように助言しているプログラマたちは、自分たちのアプリの実際のパフォーマンスが低いことを知っているはずだが、こういうことに関して人はとても簡単に心の壁を作ってしまう。

今となっては、こういうことを十分に見てきたので、驚くとは言えない。むしろ起きない方が驚きなくらいだ。ただ、こういうことが起きたとき、人の頭の中で何が起きているのかは今でも不思議に思う。

プログラミング以外の例としては、「自明な」事実に対する人々の見方の違いについての以前の記事でも触れたが、主観的には同時代で最もダーティな選手と広く見なされているバスケットボール選手がいる。NBAは選手のダーティさを客観的に追跡していないが、彼はさまざまな指標で突出しているように見える。例えば、1950年以前のリバウンドと同様に、股間への打撃は公式に記録されているスタッツではないが、彼は今世紀において、殴る、蹴る、膝蹴りするなど、何らかの形で相手選手の股間を打った回数で間違いなく記録を持っている（時代調整した数字でも記録を持っているはずだが、80年代や90年代は全体的にプレーがはるかにダーティだったため、通算記録は持っていない可能性もある）。議論の中では、彼のチームのファンの大半はこのことに気づいていないようで、「ナチュラルなリバウンド動作」「ナチュラルなシュート動作」というフレーズは、彼が相手の股間を打つ際の不自然な体勢を正当化しようとするファンの鈍感さを揶揄する定番のジョークになっている。

平均的に、人間は自分がファンであるもの、とりわけ自分自身や自分の会社の仕事については、欠点を無視する能力が非常に高い。良くも悪くも、僕はその逆のようで、すぐに自分や自分の仕事の欠点に目が行ってしまう。ブログ投稿がきっかけで、「自分の仕事を批判されたらどう思うか」「自分の仕事は良くないと言われたらどう感じるか」といったメッセージをもらったことが何度かある。前者については、僕は自分の論理の穴を突いてくれる人からの批判を得るために多大な努力をしているので、少しでも理にかなった批判をもらえればそれは素晴らしいことだと思う。後者については、僕は自分の仕事は重大な欠点だらけだと思っているので、ええ、そうですね、良くないと言われてももっともだと思う。自分の仕事の中でも面白いとか良いと思う部分はあるが、全体として、自分がやってきたことの何かを「良い」と評価できるかはわからない。自分に盲点がないと言っているわけではないが、この特定の盲点に関しては、たいていの人よりは少し陥りにくいと思っている²。

習慣化された回避策

自分が持っていた類似の盲点について考えると、思い浮かぶのは小さい頃、友人が僕のコンピュータを使ったときのことだ。この話を理解するには、それがメカニカルマウスの時代だったことを知っておく必要がある。時間が経つと、ゴミがマウスボールにこびりつき、掃除しないとポインタの動きが不規則になるのだった。

友人が僕のコンピュータを使おうとしたとき、マウスポインタの動きがほとんどランダムに見えたため、マウスを使うのが不可能だと感じた。僕が再びコンピュータに座ってマウスを使うと、まったく問題なく使えたのだが、ポインタをまっすぐスムーズに動かすために自分の手が何をしているかをよく見てみると、手を激しくあちこちに振り回していた。マウスボールにゴミが蓄積していくにつれて徐々にそれに適応し、マウスの極めて不規則なトラッキングを、逆方向の不規則な動きで補正していたのだと気づいた³。自分がそんなことをしているのに気づかないなんて、かなり驚くべきことだと思ったし、今でも自分が何か同じようなことをしていないかと考えることがある。

バグを回避するために自分が身につけてきたあらゆる対策について考えることがある。例えば、新しいGoogle Docsを開いたとき、以前はすぐに付けたいタイトルを入力していた。ある時、おそらく10年ほど前に、Google Docsが何らかの遅延を追加したせいで、ドキュメントを開いた直後にタイトル欄に入力した文字が上書きされてしまうようになった。なので今では、Google Docsを開いたら一度別のことをしてからタイトルを変えるという習慣がついている。Google Docsにどんどん機能が追加されるにつれ、さまざまな落とし穴を避けるための一連の習慣が身についた（例えば「間違った」タイミングで検索しようとして、Google Docsの検索ではなく役に立たないブラウザ標準の検索が出てしまうのを避ける、といったことだ）。

コンピュータ・リテラシーやソフトウェア・リテラシーの大部分は、こうした習慣の膨大なライブラリを無意識のレベルで身につけることだという気がしている。これらはしばしば状況に非常に固有のものだ。例えば、Microsoftで働いていたときに身についた、ログインする前にノートPCのWiFiスイッチをオフにする習慣がある（他の人もやっているのに気づいた）。これは、あるサービスがログインを「現在ログオン要求を処理できるログオンサーバーがありません」というエラーで失敗させることが頻繁にあったためだ。だが、そのサービスがまったく接続できないようにしておけば、そのチェックはバイパスされてログインできたのだ。

品質に対する盲目

そういう例だけで記事を埋めることもできるが、本題に戻ろう。品質に対する盲目を克服するためにしばしば提案される方法の一つは、自分たちのソフトウェアを自分たちでドッグフーディングすることだ。平均的には、ドッグフーディングしないよりはずっと良いが、それが機能するのは、人々がソフトウェアの問題を回避する習慣を（身につけて、そして忘れて）しまわない限りにおいてだ。平均的に、プログラマはソフトウェアの癖を回避するのがかなり得意だ（LLM以前に有能なプログラマであるためにはそうである必要があった）。だから、注意を払っていなければ、プログラマがこうした問題に気づかないのは非常に簡単なことだ。

逆に言えば、アプリを人々が使いやすくすることの大部分は、こうした奇妙な習慣を不要にすることにあるように思える。口で言うのは簡単に聞こえるが、こういうことについてフィードバックしようとする人々を見てきた経験からすると、ほとんどの開発者の反射的な反応は「え？ Xをやるのは簡単だよ、ただ［そのアプリを何度も使ったことがなければ、わざわざ説明されるか誰かがやるのを見ない限り、普通の人が思いつくはずのない複雑な手順］をやればいいだけじゃん」あるいは「え？ この手順はマニュアルの43ページに明確に書いてあるのを見なかったの？ 261ページの付録Bの手順を実行した後に出てくるやつだよ」といったものだ。

とはいえ、品質に対する盲目は治せると思っている。僕は何度もそれをやってきたからだ。これは相手に受け入れる姿勢があるときにだけ本当に機能すると思う。人には意図的な盲目に対する無限の能力があるが、受け入れる姿勢がある場合には、気づいていなかった問題を指摘するだけで効果があるようだ。数年、あるいは10年後に「今ではどこにでもバグが見えるようになった」と言ってくれる人もいる。

これをやる価値があると思う理由は、品質に対する盲目の度合いが高い人々やチームが、製品の品質問題のせいで成功の可能性が低下し、あるいはまったくなくなってしまうようなものを出荷するのを見てきたからだ⁴。品質をスピードと意図的にトレードオフするのは一つのことだ⁵が、僕が見てきたケースでは、常にある種の品質盲目があり、プロジェクトに関わる全員が、自分たちは非常に高品質なものを出荷していると思っているのに、実際はそうではないという状況だった。

これは昔から重要でなかったことはないが、コーディングエージェントの登場でさらに重要になっている。低品質なソフトウェアを量産することがかつてなく容易になった一方で、パフォーマンスの向上であれ、バグの削減であれ、品質を向上させることもかつてなく容易になっているからだ。

だが、そうするためには、これが可能であること、品質は改善できるのだということに実際に気づかなければならない。

Yossi Kreinin、Dennis Snell、Michael Malis、Emu Chu、Gary Bernhardt、Jon Surrell、Matt Mullenwegにコメント／校正／議論の協力を感謝する。

当然のことながら、Gary Bernhardtはこの記事のドラフトを読んでいる最中にGoogle Docsのバグに遭遇した。

追伸：過去4回の投稿でも述べたように、LLMのおかげでデータを見て物事を解明するのはずっと簡単になったので、もっと速く記事を書こうとしている。ただ、LLMを使って文章を書いているわけではないので、品質と速度のトレードオフの別の点に移らない限り、書き上げるのにかかる時間は根本的には変わっていない。以前は、実験を走らせて数人の友人に話して、それで終わりで何も書き上げないという結果になっていた。アムダールの法則により、何かを書き上げることが実験を走らせるための帯域を実質的にすべて消費してしまうからだ。実際、そうしようと努力しているにもかかわらず（1記事の執筆を30分で済ませるのが目標だ）、前回の投稿を書いてから、十分まともなブログ記事になりそうな結果が3つあるのに、書き上げる時間が取れていない（仕事でやったことを含めれば、さらにいくつか増える）。LLMに代わりに書かせるのでなければ、1記事あたりの時間を30分より大幅に短くする合理的な方法は見当たらない（しかも目標をしばしば超過して30分以上かかっていると思う）。なので、LLMを使わない選択肢は、普段の記事よりもずっと雑な（人間的な雑さという意味で）記事を出すか、あるいはほとんど投稿しないかのどちらかになる。

いずれにせよ、これらの速成的で（そして確実により間違いの多い）投稿について意見があれば、ぜひ聞かせてほしい（X Bsky Mastodon）！

付録：広告に対する盲目

Michael Malis（Freshpaintの創業者で元CEO）は（メッセージでのやり取りのため、メッセージのような形式で）次のように述べている。

似ているが少し違うデータポイントとして——広告に関しても同様の盲目を見てきた。Freshpaintについて説明するとき、病院のマーケティングを支援していると伝えていた

よく聞かれる質問は、なぜ病院がマーケティングをするのかということだ。奇妙なことに、注意して見てみると、病院はものすごく大量のマーケティングをしている

サンフランシスコにはUCSFやSutter Health、Stanfordなどの、そしてさまざまな治療法についてのバス広告やビルボードが大量にある

これはMichaelのコメントともこの記事の本題とも別の話題だが、一言言っておくと、広告はまったく効果がないと信じている人にかなりたくさん会ってきた。だが、僕が勤めていたある大企業での広告のA/Bテストについて、データ手法と判断を信頼している人と話し、別の会社では自分でデータを見たが、そのどちらのケースでも、広告が本当のリフトをもたらす（広告費をはるかに上回る）という因果関係の証拠は強いと思った。僕が見たケースでは、地域ごとにA/Bテストを行い、一部の地域では広告を買い、他の地域では買わないというものだった（これは世界規模で行われ、地域は米国の州やカナダの州といった単位だった）。このような地域分割が行われたのは、クロスデバイス追跡を使っても、誰かが広告に接触したかどうかが100%明確になるわけではないからだ（もちろんこの分割でもそれは変わらず、僕としてはもっと人口密集地に集約され、例えば境界をまたいで通勤する可能性が比較的高いような分断がない分割の方が好ましいと思うが、この種の混入は一般に、真のリフトを推定されたリフトよりも大きく見せる方向に働く）。そのため、人々は時々このような地域分割A/Bテストを行うのだ。

いずれにせよ、これらのA/Bテストでは、広告費用対効果は直接的な収益増だけでもかなり良く、さらにユーザー数の増加もあり、将来的により多くの収益につながる可能性が高いように見えた（その後の収益は分析されていない）。広告の効果一般についてや、あなたの特定の広告が効果的かどうかはわからないが、よく繰り返される「広告は一般的に効果がない」という考えは、僕には間違っているように思える。

Michaelのコメントに関連して言えば、プログラマは広告に気づかないことが多いと思う。僕の知るプログラマはほぼ全員が広告ブロッカーを使っているし、現実世界でも、彼らの目は広告をただ素通りして気づかないように見える。これが「広告は効かない」という考えにつながるのもわかる。いったい誰がこんなものを見るんだ？ と。しかし、「普通の」人々との交流や、Google時代に見たデータから知る限り、多くの人、あるいは大多数の人は、広告の多くが広告であることすら気づいていない。Google検索をして一番上の結果をクリックするとき、彼らは自分が見ているのがGoogleが「最も良い」と考えたリンクではなく、その広告枠を買うためにGoogleに最も多くお金を払った人のリンクであることに、しばしばまったく気づいていないのだ。

付録：他の方々からのコメント

Em Chu、習慣化されたバグ回避策について：

このセクションのために無限に例を集められるのはわかってるけど、ただ文句を言わせて：ノートPC（Mac）をスリープから起こしてロックを解除するとき、とても簡単に「起きている」のに使えない状態（カーソルのある黒い画面など）になって、物理的に蓋を閉めて開け直すことでのみ直る状態になることがある。これを回避するために、画面がついてから1秒待って、トラックパッドを触ってからロックを解除するようにしていると思う。とはいえ正直ほとんど無意識にやっていて、月に数回はまだこのバグに当たるので、まだ練習が必要なのは明らかだ。

これを読んで、自分のノートPCの開け方を観察してみたところ、他のノートPCのバグを回避した結果として身についた奇妙な習慣があることに気づいた。ここで言及されている特定のバグは僕のノートPCでは再現せず、以前のノートPCのために身につけた習慣的な回避策はやめられそうだ。

Gary Bernhardt、この記事のドラフトを読んだときの経験について：

読んでいる最中に、Google DocsのUIが壊れたようで、スクロールして上のコメントを読むことが不可能になった（スクリーンショット参照［記事には掲載せず］）。

スクリーンショットを見る限り、僕はまったく同じバグを見たことがあり、それに対する回避策もいくつか持っている（文脈によって異なるものだ）。個人的には、Google Docsのソフトウェア品質は平均をはるかに上回ると評価している。主要な代替手段（Microsoft Word、OpenOffice、StarOfficeやLotusといったとっくに消えた古いエディタなど）よりも、ずっとバグが少なくガタつきも少ないと感じている。それでも、Google Docsのバグとそれらに対する回避策について、座って1万語の記事を簡単に書くことができる。

時々、一日中品質問題だけを修正する仕事に就けないかと探してみたことがある。これは、これがあまり高い優先度ではなく、また企業が通常用意している職種でもないという理由の組み合わせで、実現したことはない。インターンとして会社に入って、数ヶ月だけ品質問題を修正して去るということを空想することもある。実際には、そんな仕事に就いたとしても、修正の多くはブロックされ、インターンとして3ヶ月で実際に変化を推進するのは非常に難しいと思うので、誰も自分のやることを気にしないような、ほぼ放置されたプロジェクトである必要があるだろう（そして企業の優先順位が機能の出荷にばかり集中していて、修正がすぐにまた壊されるようなことがないプロジェクトだ）。

@IncidentNoodle

意図せず本題に沿った話だが：<abbr> タグは先週くらいまではモバイルで動いていたが、今はどのiOSブラウザ（Safari/Chrome/Firefox）でも動かなくなっている。そしてmacOSのブラウザ（3つとも）では、表示までの遅延が長いせいでホバーで表示されることに気づくのが難しかった

@[email protected]:

ドイツ語にはそれを表す言葉がある - Betriebsblindheit

@oulipien.bsky.social:

@danluu.comのここでのクレイジーな逸話、もっと率直に、この人にBlackboardが誰かに好かれているという信念をどこで得たのか聞いてほしかった。ユーザー調査？ プリンシパル（エージェントではなく）調査？ 内なる確信？？？［Blackboardの逸話のスクリーンショット］

［人は上司にバグが見えないと言うことを強制されている、という類のバリエーション］

これは記事中の主要な例のいずれとも、ましてやすべてとも整合しないと思う。上で述べたBlackboardの例を考えてみよう。僕や、そのBlackboard社員と話す他の人々が、従業員をチェックする「覆面調査員」である可能性は低く、そしてその社員の反応は、そのような仮説上の（実際には存在しない）覆面調査員でない誰から見ても明らかに馬鹿げている。だからそんな反応をしても、出会う多くの人の目には、なんの得もなくただ少し間抜けに見えるだけだ（例えば、前の引用を見てほしい。典型的な社内の反応のように見える）。ごく少数の非常に疑り深い社員なら、万が一上司の友人や親戚で自分がその会社で働いていることを知っている人に出くわし、その話が上司に伝わり、その上司がそれを気にするかもしれないという可能性に備えて、この体裁を保つかもしれない。しかし、例えば僕にDiscourseのパフォーマンスは本当に良いと説明するために連絡してきたすべてのDiscourse社員がそうだというのは、到底あり得ない。

バスケットボールの例を見れば、これはさらに馬鹿げている。他のファンが、最も馬鹿げた正当化を信じなければ、あるいは信じているふりをしなければ仲間外れにするだろう、といった理屈をひねり出すことは可能かもしれない。しかし、スポーツファンの間で多くの時間を過ごしてきた者として、一般的にそれが当てはまるとは思えない。そして、かろうじて多少当てはまる範囲では、それは自己選択の問題であり、最も極端な正当化を好むファンは、同じく最も極端な正当化を好むファンとより多くの時間を過ごし、そうした極端な正当化にあまり深入りしないファンは、同じく深入りしないファンとより多くの時間を過ごす傾向がある、ということに過ぎない。

また、こうしたことを鵜呑みにせず修正する人々のキャリアパスだけを見ても、これらの問題に気づいて修正することは、その人たちにとって非常にうまくいっている。これらの問題が存在しないふりをすること（それが意識的なレベルかどうかにかかわらず）もうまくいっているように見えるので、これらの問題を修正することが実際にキャリアとしてより良いとは言えないが、一般的には、これらが存在しないふりをするようにという有意義なキャリア上の圧力が全体として存在するほど悪いわけでは決してない。たとえ、これらの問題は存在しないふりをしろという直接的な圧力がかかる個別のポジションがあったとしてもだ。

Daniel Gibson:

他にも、スクリーンセーバーを終了するのにShiftキーを使っている人はいる？ もしイベントが実際のプログラムにまで伝わった場合に、意図しない影響を与える可能性が最も低いからなんだけど。

これは、codexにキューされたメッセージをすぐに送って現在のツール呼び出しを中断したいときに、ツール呼び出しが終了してEscapeキーがメッセージ送信ではなくcodex全体を停止させてしまう時間の窓を減らすために、キーの上に指を置いてできるだけ素早く押すという、僕のやり方を思い出させる。おそらく、この問題や他に遭遇したいくつかの問題を修正したパッチ版のcodexを実行すべきなのだろうが、僕はすでにワークロード固有に最適化された奇妙なバージョンのripgrepを試すといったこともやっており、それは検索開始と並行して別スレッドでマッチング式をコンパイルし、コンパイル完了後に切り替えるネイティブコードコンパイラが追加されたものだ。だから、ワークフローを改善するために奇妙なパッチを作ることに反対なわけではなく、全体的な帯域の問題なのだ（間違いなく、これを書いたら「別のキーを押せばいいだけだよ」とか「このコメントを書くのにかかった時間でcodexにキーのことを聞けばわかったのに」と誰かに言われるだろう）。Google Docsと同様に、僕はcodexをその分野では平均以上のソフトウェア品質だと考えているが、まだ1年も使っていないのに、（習慣として、あるいは場合によっては壊れた挙動を監視して修正する実際のスクリプトとして）自分が実装してきたあらゆる回避策について、簡単に1万語は書くことができる。

John Regehr:

この記事を書いて公開した後、誰かがJohnの投稿にリンクするまで思い出さなかったのだが、どうやらJohn Regehrは僕がブログを始める前に「Operant Conditioning by Software Bugs」を書いていたらしい！ LLMを使って先行事例を探すべきだったのかもしれないが、そうしていたらおそらく何も書けなくなっていただろう。本当に新しいアイデアはそれほど多くなく、ほとんどすべては誰かが言ったことと似たものになってしまうのだから。良くも悪くも、僕はJohnよりもはるかに饒舌なので、この記事ははるかに多くの言葉を使い、より多くのランダムな物語が放り込まれている。もし僕のブログ記事が長すぎると思うなら、それでもなんとかこの記事の最後までたどり着いたのなら、僕の記事よりもJohnの記事の方が気に入るだろう :-) 。