あいつは今、20人のエージェントを同時に動かしてて、素晴らしい影響力を本当に拡大してるね。

なんか戦術的な竜巻みたいだね。これを思い出したよ：“ほとんどのソフトウェア開発組織には、戦術的プログラミングを極めた開発者が一人はいる：戦術的竜巻。戦術的竜巻は、他の人よりも遥かに早くコードを生み出す prolific プログラマーだけど、完全に戦術的な方法で作業する。クイックな機能を実装する時、戦術的竜巻より早くやる人はいない。いくつかの組織では、マネジメントが戦術的竜巻をヒーロー扱いすることもある。しかし、戦術的竜巻は破壊の跡を残す。将来、彼らのコードで作業しなければならないエンジニアたちからは、ほとんどヒーロー扱いされない。通常、他のエンジニアたちは戦術的竜巻が残したゴミを片付けることになって、実際のヒーローである彼らが戦術的竜巻よりも遅い進捗をしているように見えちゃう。” - ジョン・アウスターハウト、『ソフトウェアデザインの哲学』

俺も（ほぼ）そのタイプだったPRが一つあったよ。ライブラリや外部ツールをうまく活用して、コードベースの20％以上を削除したんだ。ただ、それによってほとんど全ての作業が自分たちが書いた関数じゃなくてライブラリの関数を使わなきゃいけなくなったけどね。でも、良い回帰テストとリンターがあれば、コードがちゃんと動いててひどくないってわかるから、レビューは正確性をチェックするために一文字ずつ見るんじゃなくて、全体的な質を重視すべきだと思う。ただ、レビューはやっぱり面倒だったけどね。

「[...] ボトルネックはコードを書くことじゃない。コードを読むことと理解することだ。」100%同意！さらに、AIが生成するコードが増えれば増えるほど、実際に理解する人は減るよね。

大規模なPRには文脈が全てだよ。もしダイナマイトセッションからの大規模PRが一度もないなら、「平均的でのろのろした」以上にはなれない。じゃあ、大規模PRの文脈は何で、どう扱うべきか？ * 収益を上げている成熟した製品で、中堅エンジニアが全てをリファクタリングして「良くなった」？お願いだから黙ってて、まずはどうしてそうなっているのか、そしてそれがどうして良いのかを理解していることを示さないと、この話は始まらないよ。 * グリーンフィールド開発で、信頼されているエンジニアが何か大きなものを0から1にする？2週間も委員会で止めるべきじゃないかも。多くの反対意見は表面的なスタイルの問題かもしれないし。もちろん、他にも多くの文脈があって、これは多次元空間の2つの極端な例に過ぎない。でも、プロセスが「全ての行を訴訟する」なら、それは革新的な場所とは言えないよ。確かに、ほとんどのPRは小さくて、ターゲットを絞って、レビューしやすく、チケットに関連付けられるべきだけど、もし革新を目指しているなら？定義上、ちょっと違うんだよね。

大きなPRを自動的に拒否して、小さなものを作るように言えばいいのに、なんでそうしないのか理解できない。これは技術的な問題じゃなくて、コミュニケーションや社会的な問題に思える。AIを使っても、小さくて自己完結したPRを作るように指示すればいいんだよ。僕はClaudeやGPTモデルでこれをやってるけど、うまくいってるよ。

これが証明してるのは、ボトルネックはコードを書くことじゃないってこと。コードを読むことと理解することだ。だから、読むことや理解することなしにコードを書けばいいんだ！ラリー・ウォールはずっと正しかった！

AIがなければ、コードを書くことも読むこともボトルネックになるよね。古いコードを見直して、ひどい品質に驚いたこと、何回ある？自分で作ったものが雑だったりするし、それはGenAIの出力と変わらない。ただ、人間が貴重な時間をかけて作ったってだけ。何かしらの理由で動かすために急いでコードを出すことに制約があったんだろうね。本当の問題は、一方が自動化を使って、もう一方が手動で確認できる以上のコードを作れる非対称性にある。

AIのおかげで、みんなが「その人」になれる時代だね。

それは、ボトルネックがコードを書くことにないことを証明してるよ。ボトルネックはコードを読むことと理解することにある。いや、PRの提出が文字通りスパムされてるってこと。提出した人はスパマーみたいに、たくさんのゴミを送り出して、何かが引っかかるのを期待してる。つまり、AIが見つけて生成したものをレビューする役割を果たしてないってことだね。

アクティビティゼロのアカウントが何もしないのを続けるのは許されないってこと？もしかして、間違ったアカウントをシェアしちゃった？

いいアイデアだね。

それは管理のオーバーヘッドを増やすし、提出者が自分が正しいって無限に議論するインセンティブも高くなるね。

簡単に利用されちゃうよね。動かないプログラムを閉じる方がいいと思う。

お金を動かすのはタダじゃないし、支払い管理とかは本当に頭が痛くなることがある。簡単な時もあれば、そうじゃない時もある。

正直、これはいいアイデアだと思う。唯一の提案は、すごく名目上ではなく、「妥当な」金額にすべきってこと（つまり、$1じゃなくて$10）。これをメンテナや従業員に直接リンクさせることも可能だよ。もし1時間に10件のAIやリアルなものをレビューできるなら（AIの雑なものならもっとできるかも）、新しい収入源を生み出してることになる。今、彼らがSFベイにいるのか、物価が低い第三世界の国にいるのかは分からないけど、「追加」として、1時間$100は悪くないよ（AIのゴミを見つけるのが得意なら、むしろ「低め」かも）。ちなみに、「脆弱性」が実際の脆弱性かどうかを確認する方法はないのかな？...それなら、$10の提出料で動かすLLMを使ってみたらどう？

そのアプローチの問題は、本物の提出も妨げる可能性があるってことだね。「報酬なし」のシステムよりも、むしろ悪影響が大きいかも。雇用の一環でバグに遭遇した人たちは、今度は雇い主に前払いでお金を出させる必要がある。ほとんどの雇い主にとって、たとえ小額でもお金を使わせるのは大変なんだよね。自営業や趣味でやってる人にとっても、「私のエクスプロイト報告に対して嫌な態度を取るかもしれない」と賭けるのはリスクが大きい。Tursoに対して悪気はないけど、ソフトウェア企業の大半はそういう報告の扱いがひどい。多くは、報酬を不当に奪う非公式なポリシーを持ってるし。今日、そんな報告を提出するには、自分の仕事が統計的に見て、製品のユーザーのために無償の労働を提供することになるって受け入れなきゃいけない。現金の手数料を追加することで、提出がさらに妨げられるし、特に何度もお金が戻ってこなかったらね。（「AI検出ツール」が実際には信頼性の低い機械学習や時にはLLMシステムであることを考えてみて。）

残念ながら、これは単純な話じゃないんだよね。会社が報酬を払いたくない場合もあって、脆弱性を「範囲外」や「意図通りに動作している」として攻撃的にマークすることもある。その場合、時間を失うだけじゃなくて、将来的にはお金も失うことになる。特に小さな会社だと、提出する前にどう反応するかわからないから、余計に厄介だよね。

バグバウンティは、ユーザーにシミュレーターを拡張させて、見つけたバグの種類をカバーさせる必要があるみたいだね。提出前にシミュレーターのテストスイートをフルで実行することを求めるのもいいかも？それでシミュレーターが壊れてないかのチェックになるし、もしかしたら作業証明のアーティファクトも生まれるかもしれない…（これって可能なのかな？セキュリティに詳しくないからわからないけど）。

提出者に支払いを求めること バグを提出するためにお金を払わせるのは、会社のために無料で働かせることを求めるインターネットドラマの火種になるよ。プログラムが実際に報酬を支払っても関係ない。もし一つでも報告が誤って閉じられたら、終わりが見えないだろうね。

Phabricatorも似たようなシステムで運営されてたよ。バグレポートや機能リクエストを送るのにお金が必要だった。オープンソースプロジェクトとしてはちょっと変な感じだけど、私が働いてた会社はPhabricatorを使ってて、ちゃんとお金を払ってた（他では絶対払わなかっただろうけど）。だから、これは有効な戦略だと思う。しかも、スロップから免疫ができるしね！でも、彼らは1年くらい前に閉鎖しちゃったけど、理由は言ってなかったな。

記事から: > 自動化システムを設定してこれを制御することは可能だけど、金銭的価値が無視できないから、AIたちがただ議論を続けたり、同じPRを再オープンしたりするインセンティブが大きすぎるんだよね。

それか、プログラムがデータをそんなに簡単に壊さないようにして、他の人が見つけた問題ごとに$1000払わなくて済むようにすればいいんじゃない？

いいプロジェクトだね！でも、すぐにAIボットにブラックリスト入りしちゃうかも。

これがよくわからないんだけど、そのプロジェクトがバグバウンティを提供してないなら、なんでこんなにPRが多いの？ゴミみたいなPRを出すために本物のお金をトークンに使うインセンティブって何？PRが製品をスパムしてるの？

AIは有用なエクスプロイトを見つけられるけど、話題になってるものは偽陽性の海の中に埋もれてるし、成功例はすでに専門家だった人たちが見つけたものばかりだよ。公のバグバウンティプログラムは、粗い中にダイヤモンドがあっても、ゴミで溢れかえるのが目に見える。

何を逆転させるの？curlを例に取ろう。ダニエル・ステンバーグが、AIのスロップが蔓延してるせいでcurlのバグバウンティプログラムを止めなきゃいけなかったって書いてたよ。彼は、最終的にバウンティなしでセキュリティバグレポートを再開したことについても書いてた。バウンティなしだと、レポートの質が高くなるみたい。お金のインセンティブを取り除くことで、本当に善意やセキュリティへの関心からバグを報告する人が集まるようになる感じがする。商業的な利害に汚染されていないインターネットの初期のフリーソフトウェア開発の時代に戻ったような気がする。だから、私の意見としては、セキュリティバグレポートは続けるべきだけど、バグバウンティはやらない方がいいと思う。Tursoは腐敗バグレポートは奨励すべきだけど、バウンティはなしでね。