エンジニアを追い詰める「見えないプレッシャー」との付き合い方

その通りだね。自分も同じことで悩んでたけど、あんたほど上手く言語化できなかったよ。前より書いてるコードの量は減ってるはずなのに、1日終わるとめちゃくちゃ疲れてる。結局、レビューの量が増えてるし、PRからPRへと絶えずコンテキストスイッチを強いられてるせいなんだよね。

もう一つ見かけるのは、「正しい」コード（PRの説明通りに動き、エッジケースのテストも通る）の量産だね。

でもそれは「悪意のあるコンプライアンス」的な正しさなんだ。例えば、新しい機能の足元が少しでもぐらついていたら、その awkward な状態や非決定的な動作、レースコンディションを、新しい複雑な関数や状態を導入することで見事にすり抜けて解決してみせる。そうすると、次のPRはそのぐらついた足元に対処した上に、前のPRの「回避策」もすり抜けなきゃいけなくなる。それが無限に続いていくんだ。

で、もちろんどこかでその複雑さがぶつかり合って、想像もつかないような複合的なバグとして爆発するわけ。テストなんてできるわけないよ。まさに「スイスチーズモデル」だね。そもそもそんな状態が存在してはいけないんだ。

要するに、最先端のAIエージェントでさえ、複雑さを増すことを勲章みたいに扱ってる。特に、10個先のPRで破綻することを見通せないジュニア層の手にかかると最悪。「仕事だけして定時でPCを閉じる」っていう考え方の人が、このスレッドでは間違いなく正解だよ。

結局のところ、答えは「もっとAIを」ってことになるのはわかってるよね？入ってくるPRの妥当性を評価するAIエージェントを作って、ガードレールに引っかかったり重複してるPRは全部弾いて、通過したものだけを人間が承認するっていう仕組み。

あるいは、「完璧な」ソフトウェアを書くのがただ単純に死ぬほど難しいだけなのかもしれない。相対的に見れば、それを壊す方法を見つけるのは簡単だし。そうなってほしくはないけどね。

つまり、curlみたいにプロジェクトがC言語で書かれている場合、事態は間違いなくより深刻なんだよ。もしcurlがGoやRustで書かれていたら、脆弱性は少なかっただろうね。ただ、それらの言語に柔軟性が欠けているのか、他の問題があるのかはわからないけど、今のところ誰もcurlのようなものを移植しようとしていないし、できていないんだ。

もしcurlがGoやRustで書かれていたら、GoやRustのライブラリからしか使われなかったはず。そうすればエコシステム全体や世界中に知れ渡ることはなかっただろうね。CのAPIは今でも一番重要だし。少なくとも今はそう。新しいハードウェアが出るたびにアセンブリとCのサポートは付くけど、GoやRustのサポートなんて付かないからね。

RustやGoのコードからC互換のモジュールをコンパイルできるって知らないの？余裕でできるよ。curlには既にhyperバックエンドが入ってるし（細かい追跡はしてないけど、いくつか問題はあったみたい）。

メモリ安全性は確実に進むべき道だし、curl自体を書き直す必要はない（https://github.com/jonwiggins/urlx みたいにやってる人もいるけどね）。エクスプロイトが見つかりやすい部分だけを差し替えればいいんだよ。

確かcurlは、最後に聞いた話だとhyperのサポートをやめたはずだけど。

RustはFFIを介してCのABIとかなり強固に相互運用できるよ。Rustでライブラリを書いて、共有オブジェクトとしてコンパイルして、標準的なCのヘッダーをエクスポートすればいい。エンドユーザーやOSから見れば普通のCライブラリのように見えるけど、中身はRustのメモリ安全性のお墨付きが得られるんだ。

rustls-ffiが、このアプローチが実用的に完全に機能する良い例だね。

Goでも同じことはできるよ。Cの共有ライブラリやスタティックライブラリとしてコンパイルして、C ABIに関数をエクスポートすればいい。でも、そこまでやるなら、Cが必要な場所では最初からCを使えばいいんじゃない？

Rustの安全性の大部分は、事前条件と事後条件を型の中に丁寧に組み込んだ、練り込まれたライブラリのおかげだよ。コンパイラがライブラリの「正しい使い方」を保証してくれるからね。

結局ライブラリ自体を作る難易度は変わらないし、労力の配分がどこにいくかだけの話だと思う。

それは一部では正解だけど、Rustなら最初からメモリ安全性が手に入るってのも大きいよ（しかもライブラリ依存なんて全く関係なくね）。

結局のところ、答えは「もっとAIを」ってことになるのはわかってるよね？

本当に憂鬱な話だな :-(

2000年代初頭には「XMLは暴力みたいなもの。うまくいかないなら、もっと使え」っていうジョークがあったけど、今は「AIは暴力みたいなもの。うまくいかないなら、もっと使え」になったわけだ。

自分の職場でも既に起きてるよ。数日で山のように積み上がる1万行以上のプルリクをどうやって現実的な時間でレビューすればいいか相談したんだけど、結局返ってきた答えは「AIにレビューさせて、特定の箇所を指摘させて、人間はその一部だけをチェックする」っていうものだった。

で、残りの問題は後から本番環境が爆発して知ることになるんだろうね。自分はAI支援で書いたコードには責任を持ちたいからレビューにすごく時間をかけてるけど、AIは大規模な変更の中で細かいミスをよくやる。一度、そのまま通ってたら新規顧客が全員サービスを使えなくなってたようなミスを見つけたし、今週も機能フラグを間違った場所で読み取っていて、一部の機能フラグが設定されていないとシステム全体が停止しちゃうようなバグを見つけたよ。

コードを読むだけじゃ不十分だと思う。ツールがほぼ完璧になったとしても、1万行の変更につき1つ致命的なエラーがあれば、最終的にはビジネスが終わる。AIでコードを書くなら、リリースのたびにシステム全体をエンドツーエンドでテストする環境が必要になるはず。職場でも以前話が出たけど、残念ながらセットアップが整う前にAI時代が来ちゃったんだ。

気にすんなよ。燃えるに任せとけって。それが経営層が学ぶ唯一の方法だよ。

最近ずっとそんな考え方だ。仕事への情熱を切り離そうと必死なんだけど、これが結構つらい。以前はソフトウェアエンジニアリングにおける問題解決の部分を純粋に楽しんでいたからね。でも今、開発者からその情熱を奪おうとする「戦い」のようなものが起きていて、どうやら負け戦になりそうな気がする。誰も気にしちゃいないんだよ。この気持ちを親に話したとき、なんでそんなに落ち込んでるのか不思議そうにしてたんだけど、母さんが「あんたの仕事は情熱を注げるものだからじゃない？ 私たちにとって仕事はただの仕事で、お金をもらうための手段でしかないから」と言ったことでようやく腑に落ちたよ。

とにかく、言いたいのは、仕事に対する情熱を捨てる努力をしてるってこと。AIのせいで何もかも台無しになったし、もう元には戻れない。だから、あんたが言うように、もうどうでもいいやって思うことにした。コードの品質も、リリースする中身も、知ったことか。何かが壊れたら？ まあ、それならそれでAIに直させればいいさ。

わかるよ。コードの質なんて気にしない奴がチームの中に必ず一人はいるから、この質の低いコードの氾濫は止めようがない。個人的には、昔情熱を注いでいた他のことにフォーカスし直そうとしてる。フィットネスとかアートとかね。

このスレッドを見てると精神衛生上良くないな。こいつらは俺たちの趣味（賢さや運のおかげでキャリアにできたもの）を盗もうとしてるのに、それを黙って見てるだけなんて。新しい職種を覚えるにはもう年を取りすぎてるし。それにさ、俺はコードを書くのも、アイコンやUIを作るのも、やつらが自動化で排除したいと思ってるすべての仕事が大好きなんだよ。

2月以降、技術系のSNSで何を見てもメンタルに悪いことしかなかった。キャリア4年目（2022年卒）だけど、もう袋小路に追い詰められた気分だよ。キャリアアップなんて諦めた。だって詰んでるし、未来が見えないんだもん。インスタ（暇つぶし用）では技術やSWE関連の投稿を全部ブロックしてる。見るだけで不安になるから。前は新しい技術のリリースやカンファレンスにワクワクしてたし、進歩を見るのが楽しかった。でも今は、ステージの上で笑いながら「うちの新しいすごい技術プロジェクトがいかにしてソフトウェアエンジニアを排除するか」を語る経営陣の話ばっかり見て、恐怖すら感じるよ。やつらは自分たちに高い給料を払うのがそんなに憎かったのか、何兆ドルも使って人類の全知識を盗み出し、自分たちを追い出すためのロボットを訓練してるんだ。笑わせるなよ。ここ半年、目が覚めない悪夢を見続けてる気分だ。本当に最悪だよ。キャリアを変えなきゃいけない気がするけど、本当にやりたくない。この4年間、天職を見つけて人生を捧げられると思ってたんだから。まあいいや、もうクソくらえだ。

残念だけど、それだと解雇されるリスクがあるんだよね。AIが失敗しても、責任を負わされるのはAIじゃないし、経営陣でもないんだから。

どのみち解雇されるルートに繋がってそうだな。

結末は次の3つのどれかだ：

• 解雇される
• 燃え尽きる
• 莫大に稼ぐ

この中から2つ選べ。ちなみに3番目は選べないようになってる。

情熱を捨てる必要はないけど、燃え尽きるまで放置するのも手だよ。

仕事に情熱を持つのはいいことだ。だからといって無理してヒーローになる必要はない。システムが脆くて助けが必要だってことを、声を大にして記録に残しておくだけでいい。システムにはそれを支える人やプロセスも含まれるんだから。

システムが実際に失敗した時（あるいは人々がついにそれが失敗し続けていたことに気づいた時）、彼らは君を責めるだろう。その時のために証拠（receipts）を手元に残しておく必要がある。ポストモーテム（事後検証）はまさに因果応報の鞭のようなものだから、わざわざ潤滑油を塗ってあげる必要なんてないんだよ。

すべては証拠を残しておくことに尽きる！メール、プルリクエスト、サーバーログなどなど。誰が本当のバカなのか、奴らが完璧に理解できるようにしておこうぜ。

1万行の変更につき1回発生する致命的なエラーが、いずれビジネスを破綻させるだろう

これについてはどっちの立場であれ自信なんて持てないはずだけど、人と同じように企業も驚くほど適応力があるものさ。

確かに、一つの単純なミスでビジネスが即死するような道はそんなに多くないよね。僕らにとって最悪なのは、サービスの全停止と設定ファイルの紛失で、即座に復旧できなくなることかな。うちはGitHubやCloudflareみたいに大きくないし不可欠な存在でもないから、謝罪だけで済ませるわけにはいかないし。

僕らが取るべき対策としては、顧客からの信頼を完全に失う前に、AIから手を引くことだろうね。

diffファイルに対して wc -w を実行して、その長さを『戦争と平和』の何分の一かで表現するようにしてみたよ。中にはあの作品と同程度の長さのものもあったんだ。誤解しないでほしいんだけど、大好きなんだけどさ、これって午後で読んだり流し読みしたりできるような代物じゃないよね。

ある程度は、いつか収まる嵐のようなものだと思う。現状、AI関連の作業は不当に安く見積もられている。AI企業はシェアを奪って投資を呼び込むためにリソースを安売りしてるからね。最終的にはAIのほうが人間の作業より安くなる可能性はあるけど、今はコストパフォーマンスがいいわけじゃなくて、単なる見せかけの経済だと思う。

現在、AIの作業は過小評価されている

俺が理解している限りでは、これは正しい :-)

でもさ……なんで今、そんなに新しいデータセンターを建てまくってるんだ？

「実験的」な段階や「市場開拓中」の時期を過ぎて価格が上がったら、需要は減るんじゃないの？

それとも、価格が上がっても需要曲線が右にシフトして、値段が上がってもみんなもっと使うようになるって期待してるのか？どうも腑に落ちないんだよね。

中期的には（1）今よりAIが増えて、（2）今よりAIのコストも高くなるっていう前提があるみたいだけど、それは……ちょっと考えにくいかな。

（長期的には、AIの供給コストは下がるっていう考えだろうけど。中期の目標とは思えないね……）

データセンターは、誇大広告で膨らんだ需要予測のためのものだよ。AI企業は何が何でもその熱狂を維持しないと、投資家から見放されて破綻してしまうからな。これらの企業は投資家からの資金を食いつぶして赤字でサービスを提供しているんだ。市場を独占して、ユーザーを自社製品の虜にするためにな。どこか一社が競合を蹴落として支配的になれば、そこから価格を釣り上げて、AIなしではやっていけない顧客から荒稼ぎするつもりなんだよ。

少なくともそれが彼らの計画だろうけど、実際そうなるかは怪しいもんだね。むしろバブルが弾けて、こうした企業の多く（あるいは少なくともAI部門）が崩壊する可能性の方が高いんじゃないか。その後に何が起こるかなんて誰にも分からないよ。

でもそれ、いまいちピンとこないな。膨大な資金を投じてキャパシティを増やした後に値上げするって、それじゃあ増やしたキャパシティが必要なくなるってことだよね？例えばUberなら理屈は通る。価格を低く抑えて乗客を大量に確保し、運賃を補助してドライバーを動機づけ、必要に応じて彼ら自身の資金で車を買わせてキャパシティを増やす。その後にUberが値上げして利益を上げれば、需要が減ってもUberは痛くも痒くもない。責任を負うのはUberのために生活の全てを捧げたドライバーの方だからね :P でも、会社自身が莫大な金を払ってキャパシティを増やした後に、値上げで需要をシャットアウトするなんてやり方は、どう考えてもおかしいでしょ。

あんたの失敗は、2四半期以上先の未来のことまで考えすぎてる点だよ。

他に選択肢なんてあるのか？リクエストが来るたびに赤字を垂れ流し続けるのか？それともレスポンスの中に広告を埋め込むとか？

今は明らかに「勝つためには手段を選ばない、解決策は後回し」っていうメンタリティだけど、AIに投資マネーがこれだけ注ぎ込まれてる現状じゃ、実際に「解決策を後回し」にする必要すらないのかもね。その段階に到達した時、個人的には詰んでると思うけど、誰にも分からないよ。もしかしたら何か上手いやり方を見つけるかもしれない。赤字続きの企業が最終的に倒産するのは初めてじゃないし、赤字続きの企業が持続可能な収益化モデルを見つけ出したことだって初めてじゃないんだから。まあ、時間が経てば分かるさ。

彼らの選択肢は、誰も金を払いたがらないような過剰なデータセンターを建てるんじゃなくて、正当な価格を請求できるようになった時の需要に合わせてインフラを拡張することだよ。

こう言えば分かりやすいかな：

10万トークンを作成するための実コスト（妥当な資本利益率を含む）が10ドルだと仮定しよう。

そしてその価格で、年間100兆トークンの需要があるとすれば、それは素晴らしいビジネスになる！

ところが、本来なら100兆トークン分でいいインフラを、600兆トークン分も超高コストで作ってしまったとしたら（以前、割引価格の10万トークンあたり2ドルで提供していた時の需要に合わせてね）、それはあまり良くない状況だよね。

確かに。でもそういう状況でどうやって勝てっていうの？ 600兆トークン規模のインフラを持ってる相手がいたら、どうやって対抗するわけ？ これってかなり面白いゲーム理論の問題だよね。長期的な需要をはるかに超えた規模まで拡張しないで「勝てる」企業なんてあるのかな。

ていうか、ビジネスプランとしては「彼らが借金を返せなくなって破産するまで待つ」っていうのもアリかもね😂

600兆トークン分のインフラを持っていないのに、誰か他の人が持っていたらどうやって対抗するんだ？

もし600兆トークン分の需要がないなら、そんなのどうでもいい話だろ。それに、使われていないキャパシティに大金をドブに捨てる必要がないっていう利点もあるわけだし。

今のハイプ（過剰な煽り）はビジネス戦略を歪めてるよ。企業はAI需要を必死に吊り上げたいという既得権益があるし、その大部分は「成功するまで成功したフリ」をしてるだけ。需要がとんでもなくあって、しかも伸び続けているかのように振る舞わないといけない。だから実際にはそんな需要がないのに、データセンターを建てまくってるんだ。

投資家に「おっ、あいつらは年間600兆トークン分も設備投資してるから、本気で需要があるに違いない。自分も投資して利益にありつかなきゃ！」と思わせて、その目標に到達するまで補助金を出させるのが狙いさ。

君は論理的で慎重なビジネス戦略の観点から見てるけど、彼らはそうじゃない。バブルだと分かってて、逃げ切る前にできるだけ搾り取ろうとしてる連中もいれば、自分の信じた物語に酔いしれて需要があると本気で信じている連中もいる。あるいは、技術はまだ追いついてないけど、金が尽きる前にAGIみたいな画期的なブレイクスルーが起きて、ゴールラインまで引っ張ってくれることに賭けてる連中もいるんだよ。

その後は誰にも分からない。

その後には、世界中の誰もが格安でRAMを使える未来が待ってるさ！

彼らは投資を使ってシェアを奪い、後から劇的にコストを削減する戦略をとっているんだろうね。コストが十分低くなれば、他のサービスと同じように均衡価格に落ち着くはず。もし限界費用がストライクプライス（行使価格）を上回るようなら、一言でいって詰みだ。一方で、彼らはAGIを開発するようなムーンショットを口にしている。それが実現すれば、今の議論自体が無意味になるけどね（まあ、個人的にはそこまで到達するとは思えないけど）。この特定のドメインにおいて、LLMは脆弱性を探す人間のリサーチャーに対して圧倒的に有利だ。だからこそメンテナは、AIを使って迅速に修正することを強いられる……もし自腹を切るのが嫌でなければの話だけど。AI企業が仕掛けた罠みたいなものだよ。もしかすると、脆弱性を全て公開するのをやめるのが答えなのかもしれない。

どうなるかはまだ分からないと思う。AIのトークン費用はどんどん高くなっていくだろうし、経済的な理由から「昔ながらの泥臭いやり方」を続けて素晴らしいソフトウェアを作る層と、そうじゃない層で分断が起きるんじゃないかな。

教えるよ、それはもう実際に起きてることさ。

これからもっとAIが増えていくと、またxzみたいな状況が起こるはず。誰かが意図的にバックドアを仕込んだパッチを提出するんだけど、LLMに学習させてあるから人間の目には留まらないし、誰もチェックしないっていうね。

AIがコードを書いて、AIがレビューする。うちのCEOが全ての決定をAIに丸投げしてるのと同じだよ！

いや、そうじゃない。彼が言いたいのは、質の高いバグ分析やレポートがどんどん増えていて、それが負担になっているってこと。それは良いことだけど、彼と彼のチームにはそれらの問題を適切に対処するための資金が十分に出ていないんだ。これはAIが何かを台無しにしているんじゃなくて、世界中でcurlに依存している企業がタダ乗りして、コモンズの維持 に必要な最低限の出資すら拒んでいるっていう話。言いにくいけど、これは事実上MITライセンスが原因だよ。ただ乗りに対抗する仕組みが全くないからね。

バグバウンティプログラムはなくならないよ。企業にとっては、本番環境で実際に侵害が起きた時の損害に対処するより、AIが見つけたバグに対して研究者に500ドル払う方がまだ安上がりだからね。

君の言うことはもっともだけど、理由は少し違うよ。LLMは境界線を越えて、バグを見つけるのに十分なレベルになってきた。それに、ボット全盛期はもう過ぎたと俺は見てる。もしセキュリティバグを大量に報告してくる奴がいたら深掘りするけど、それがAIによるスパムだと分かったら即座に不採用にするよ。それに、ほとんどのバグバウンティプログラムは終了したか、スパム投稿を回避するためのフィルターを強化しているしね。

今起きているのは、エンジニアや研究者、学生がLLMを道具として使い、人間だけでは見つけにくかった新しい脆弱性を特定しているという状況だと思う。LLMは人間とは全く違う方法でコードを見ているんだ。彼らはコードの本質を理解しているわけじゃなくて、テキスト内のパターンを見ている。人間が普段見落とすような、問題のあるパターンを特定できるんだよ（しかも、綺麗で読みやすいコードの中に隠れているようなやつをね）。色覚異常の検査で、特定のタイプの人にだけ数字が見えるようなものと似てる。最終的に何が本物のバグかを判断して、詳細なレポートにまとめるには、結局人間の目が必要になるんだ。

だから今はその「ラッシュ」が起きているんだよ。30年間の開発の積み重ねで溜まっていた根深いバグが、一気に露見しているだけ。今後も進めていけば、まとめてではなく発生するたびにバグをキャッチできるようになるはずだ。

単純に退屈な作業っていうのもあるよね。AI企業が資金提供して、ツールをコードベースに投げ込むような巨大なグローバルハッカソンができれば話は別だけどさ。みんなで他の作業を止めて、オープンソースのビッグプロジェクトを一斉に修正しようぜ！なんて言っても、もちろん現実的じゃない。

せめてAI企業がcurlに資金を山ほど提供するのが、本来あるべき姿だと思うけどね。

ああ、状況はかなり泥沼だね。curlに依存している企業はちゃんと金を出すべきだよ。そうしないと、その辺のハッカーがAIを使って同じ脆弱性を再発見しかねないし。セキュリティ上のリスク以外の何物でもないでしょ。もちろん、これには全てのAI企業が含まれるよ。でも俺が言いたいのは、今後は状況が改善するってこと。AIによって隠れたバグが一気に発掘されるみたいな事態はもう起きなくなるだろうし、代わりにバグが混入されたタイミングで検知できるようになるはずだからね。

その一方で、あまりメンテナンスされていない、あるいは放棄されたソフトウェアのバグを見つけるのは格段に楽になったね。

それが記事を読んでのあなたの結論？

何千ものセキュリティバグを抱えてるらしいソフトウェアを、あなたは喜んで使ってるの？

それらのレポートが全部有効だなんて誰が言ったの？それに仮にそうだとしても、その中に数万件の重複が含まれていないって言い切れる？

彼がそんなこと言ってたっけ？俺が見落としてる？

その「数千のセキュリティバグ」ってのは、30年かけて見つかって修正されてきたものの累積数だよ。放置されてたわけじゃない。curlは世界で最も精査され、ファジングされ、検証されているコードベースの一つだからね。毎日1件程度のペースで報告を受けているけど、そのほとんどは深刻度がLOWかMEDIUMで、最後のHIGHレベルの脆弱性は2023年のものだ（記事を読んでいれば知っていただろうけど）。バグが報告されるということはバグが修正されるということであり、報告の洪水は怠慢の証ではなく、絶え間ないセキュリティ作業の証なんだよ。まあ、透明性を持って積極的に問題を追いかけてパッチを当てているプロジェクトに対して大騒ぎするのもいいけどさ。ちなみに、君が今ここでその「見解」を書き込めているのは、まさにcurlのおかげだよ。

もし毎日毎日新しいバグが見つかり続けているなら、それはコードベースが完全に破綻しているってことじゃないの。ひび割れた石を敷き詰めた道路を作って、毎日一個ずつ石を直してるからって称賛されるべき？それとも、そもそもそんなめちゃくちゃな状態にしたことを批判されるべき？セキュリティバグをエンドレスに作り続けているなら、それはもう手法そのものが間違っているんじゃないか？

その道路の例えは的外れだよ。ソフトウェアは静止した石の積み重ねじゃなくて、進化し続ける生きたシステムなんだ。日々新たな脅威に直面し、数え切れないほどのプラットフォームやプロトコル上で動いている。「終わりなきバグ」っていうのは、絶え間ない精査とより良いツールによって発見され続けているっていう証拠であって、セキュリティを意識したソフトウェアにはまさに必要なことだよね。前にも言ったけど、ほとんどは深刻度が低いものだし、すぐに修正されている。繰り返すけど、監査もしていないコードを公開して運任せにしているプロジェクトじゃなくて、徹底的にやっているプロジェクトを批判するのはおかしいよ。

curlに対してそんなこと言っているのが信じられないな。

お前がリリースしているソフトウェアは、絶えず変化する環境の中で、バグが永遠に出ないものなの？

良いソフトウェアに「無限にセキュリティバグが見つかること」を求めてるのか？俺なら設計の段階で堅牢なセキュリティを求めてるよ。次から次へと問題が出てくるようなソフトウェアをどうやって信頼するんだ？もしそうなら根本的な問題があるのは明らかだろ。それが比喩のポイントだったんだけど、伝わらなかったみたいで残念だな。

また、監査されていないコードをリリースして運任せにしているプロジェクトではなく、徹底的にやっているプロジェクトを批判しているわけだ。

バカげた二者択一だな。それにこれは論点そらし（whataboutism）でもある。よくもまあ一文に二つも誤謬を詰め込めたもんだ。わざとやってるのか？お前はcurlを真面目に議論する対象としてではなく、まるで好きなスポーツチームか宗教みたいに必死に擁護してるようにしか見えないぞ。

バグのないフォークを作ればいいじゃん。誰も止めてないし、自由にやれば？

こんなにバグが多いのは、バグバウンティプログラムにゴミみたいな報告が大量に押し寄せているからだよ。

俺が知る限り、curlは最高にセキュアで、どこにでも普及しているHTTPライブラリ／ユーティリティの一つだ。

確かもうバグバウンティはやってないはずだよ：

• https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/

curlは俺が知る限りで最高にセキュアで普及しているHTTPライブラリだ。

curlの開発者はそう思ってないみたいだけどね。どうやら毎日新しいセキュリティバグが発見されているらしいよ。

もし君が本気でそう思ってるなら、インターネットもコンピュータも使わない方がいいよ。全部君の主張に反してるんだから。

1日1件以上のセキュリティレポート？ うわっ、それじゃcurlなんて誰も使わない方がいいじゃん。

wgetやlynx、linksのソースも誰か見てるのか、それとも単にcurlにバグ報告を送りつけるための組織的な嫌がらせなのか、気になるところだね。

記事を読んだ方がいいよ。洞察が得られるかもしれないから。（答えはサポート契約さ。企業はcurlに依存しているから、維持のために自発的にお金を払っているんだよ。）

ざっと目を通したけど、見落としてたみたいだ。

彼はスポンサーの一社で働いてるよ https://curl.se/sponsors.html

まあ、報酬が問題なんじゃないんだよね。こういう人たちや組織がOSSのバグを見つけると、報酬の有無にかかわらず開示することが多いんだけど、その後「責任ある開示」という名目で、一定期間が過ぎたらバグを公開しなきゃいけないって思い込んでるんだ。しかも、深刻度がバラバラなバグを一度に35個も放り投げてきたりするし。

*厳密なところは分からないけど、ハッカーじゃない人がバグを見つけて、報酬が出るまで黙り込んでるケースもたくさんあるのかもしれない。そうじゃないといいんだけど。

言いたいことは分かるし、気持ちはいいんだけど……正直それが良い変更になるとは思えないな。バグ修正のレビューにリサーチャーを参加させるのはありかもしれないけど、彼らがパッチそのものを作るスキルや（ドメインやコードベースに関する）知識を持っているとは限らないから、それ以外に貢献できることがあるのか疑問だし。それに、結局そのコードをレビューするのは（スキルと知識を持った）他の開発者になるはず。だからリサーチャーにレビューを強要しても時間の節約にはならない気がする。まあ、新しいバグを防ぐ助けにはなるかもしれないけどね。

クリックする理由はなくても、コメントする理由はあるってことだろ。まあな。

curlのバグ探しに数千万ドル相当のトークンが消費されてるだろうな

それはないな。こういうバグのほとんどは、無料版や公開版のツールを使ったボランティアが見つけてるんだから。curlが補助金を受けて行ったスキャンなんて、Claude Mythosを一度使っただけだし、それで見つかったバグもたった一つだよ。

それそれ、ずっとそう思ってた。なんでこのライブラリは、この人の週50時間以上をこれだけ長い間食いつぶし続けられるんだろう？