彼らはその一部を凍結させて、AIを生成して脆弱性を紹介し隠そうとするのと、別のAIを使ってそれを見つけて修正させるのがいいと思う。すべてのコミットが一手で、人間のチェスの進化をモデル化しようとしてる感じだね。

このやり取りが示しているのは、LLMとやり取りする際にどれだけの知識が必要かってことだ。Claudeが真ん中で生み出した「一つの大きな欠陥」は、明らかにこのエンジニアより暗号コードに不慣れな人には見つけられなかっただろう。そして同様に、多くの人はPBKDF2に移行するという奇妙な選択を疑問視しなかっただろう。これが私の重要なポイントだと思う。自分が有能なレビュアーで、言葉が悪いけどリーダーであれば、LLMを使うことで適切な効率を得られる。もし自分がその分野の知識をLLMほど持っていなければ、重要でないことをやるか、信頼せずにすべてを確認する時間が必要だ。

自分でやることについての最後の段落には賛成だな。人間は考えながらショートカットを取る傾向があるから、最終的な製品に期待するものに似たものを見つけると、あまり批判的にならなくなる。見た目や美的感覚は、読んでいるコードの中で問題を見つけるのにすごく重要だよ。自分のコード変更にバグを入れて、レビュアーがそれを見つけられるか試してみるといいよ。一方で、自分で何かを書くと、ゆっくり考える状態になって、細部にもっと注意を払うようになる。これによって、普段は考えないようなバグを見つけることができる。だから、使っているツールのトイバージョンを書くことを勧める人が多いんだ。自分で書くことで、ただ資料を読むよりもずっと学びが深まるからね。これは私たちの認知がどう働くかに関係している。

記事では無駄なコメントはあまりないと言ってるけど、コードにはこう書いてある：// リクエストからOriginヘッダーを取得 const origin = request.headers.get('Origin');

「LLMによって書かれた」という部分は、コードベースに注目を集めたり、ドメインの専門家からの無料レビューをたくさん受けるための手段でもあったんだ。他にも、AIの効率を投資家にアピールしたり、実験したりする目的もあったけどね。

最近、データを移行するためのKafkaコンシューマーを書き終えたんだけど、これはAIにとってはベストケースのシナリオだった。知ってるけど10年近く使ってない言語（Go）での使い捨てのグリーンフィールドコードだよ。複雑な理由で、全データベースが1つのトピックに集まってるから、十分なパフォーマンスを引き出すために結構複雑な並列化をやってる。全体的に見て、AIのおかげでほぼ2倍のスピードアップがあったかな。Goの構文を忘れた時に調べる手間を省けたのが大きい。ただ、Kafkaやマルチスレッドプログラミングに詳しくない人なら、少なくとも4つの微妙なバグ（もっと目立つバグもたくさんあった）をそのままプロダクションに出してたと思う。実際、バグを見つけるのに結構時間がかかったよ。もっと大きくて長生きするコードベースでは、10-20%の改善を見たことがある。これらはすべて最新のモデルを使ってる。全体的には、メモリ管理された言語に移行した時の生産性向上に近い感じだね。エンジニアをPMに置き換えるようなことは、今すぐには起こらないと思う（ここ3年で見た変化のペースからすると）。本当に心配なのは、中堅の技術者が、私の経験上最も厄介なプログラマータイプである彼らが、微妙なバグを見つけたり気にしたりすることなく、10倍も生産的になってしまうこと。シニアやスタッフエンジニアが、レビューの洪水に追いつけるとは思えない。ほとんど動くものを作るのが簡単になった世界では、ジュニアからシニアへのパイプラインも心配だね。今でもコピー＆ペーストプログラマーの問題があるのに、コピー＆ペーストプログラミングがさらに簡単になってしまった。市場が最終的にはこれを解決すると思うけど、数十年かかるかもしれないと心配してる。

こんにちは、ライブラリの作者です。（少なくとも、それを生成したプロンプトの作者ですが。） > 「私はOAuthの専門家でもあります」って言っておくけど、ニールの方がずっと専門家だと思うから、彼がコードレビューしてくれたのは嬉しい！ :) でも、いくつかのポイントには反論したいな。 > 最初に気になったのは、私が「YOLO CORS」と呼ぶものなんだけど、これはあまり珍しくないよね。CORSヘッダーを設定して、ほぼすべてのオリジンに対して同一オリジンポリシーをほぼ完全に無効にすることだ。確かに「YOLO CORS」は初心者のよくあるミスだけど、ここで起こっていることはそうじゃない。これらのCORS設定は慎重に考慮されているんだ。OAuth API（トークン交換、クライアント登録）エンドポイントやOAuthベアラートークンで保護されたAPIエンドポイントに対して、特にCORSヘッダーを無効にしている。これは正当な理由があって、これらのエンドポイントはブラウザの認証情報（例えば、クッキー）で認可されていないから。CORSの目的は、悪意のあるウェブサイトがリクエストを送信して、ブラウザがあなたのクッキーをそのリクエストに追加することを防ぐことなんだ。でも、これらのエンドポイントは認証にブラウザの認証情報を使っていない。言い換えれば、CORSヘッダーがオープンなエンドポイントは、世界に対して意図的にオープンな制御エンドポイントか、OAuthベアラートークンで保護されたAPIエンドポイントなんだ。ベアラートークンはクライアントが明示的に追加しなきゃいけなくて、ブラウザが自動的に追加することはない。だから、ベアラートークンを受け取るためには、クライアントがユーザーによって明示的にサービスにアクセスすることを許可されている必要がある。CORSはこの場合、何も守っていないし、ただ邪魔になっているだけ。 （CORSのもう一つの目的は、公開インターネットで利用できないリソースの機密性を保護することだ。例えば、認証が全くないローカルネットワーク上のウェブサーバーがあるかもしれないし、IPアドレスに基づいて認証するサーバーを使うこともある。でも、ここでの問題は、ユーザーがクライアントを明示的に許可しない限り、興味深いものは提供されない。） 余談だけど、昔、CORSの仕様の著者たちと議論したことがあって、仕様全体を捨てて、ベアラートークンを明示的に認識するものに置き換えるべきだって主張したことがある。ブラウザの認証情報を使うエンドポイントでCORSを開くのはほとんど安全じゃないけど、ベアラートークンを使うエンドポイントで開くのはほぼいつも安全だと思う。もしそのことをずっと認識して受け入れていたら、たくさんの混乱やフラストレーションを避けられたと思う。まあ、仕方ないけど。 > より深刻なバグは、トークンIDを生成するコードが健全じゃないことだ：偏った出力を生成する。これが「深刻な」バグだとは思わない。トークンには明らかに十分なエントロピーがあって安全だし（著者も認めている）。確かに、もっとバイトあたりのエントリを詰め込むことはできる。コードをレビューしているときに気づいたけど、その時はこう決めた：1. 現状でも安全だし、最大限効率的ではないだけ。2. 将来的にはアルゴリズムを自由に変更できる。後方互換性の心配はないから。だから、私はそのままにした。もしこのコードが今まで書いたものより100倍レビューされるって知ってたら、たぶん修正してたかも… :) > コミット履歴によると、初日に一人の開発者からメインに21のコミットがあったけど、コードレビューの兆候は全くなかった。 GitHubに表示されるコミット履歴の最初のタイムスタンプは、後でリポジトリに本来含まれないファイルを削除するために行った履歴の書き換えのせいで誤解を招くから注意してね。GitHubはリベースの日付を表示しているようだけど、git logは実際の著作の日付を表示している（これらのコミットは2月27日から数日にわたって広がっている）。 > トークンストアの暗号化実装をちょっと見たけど、デザインは結構好きだ！かなり賢いと思う。ありがとう！このデザインには結構誇りを持ってるよ。（もちろん、AIが自分で考え出したわけじゃないけど、私の明示的な指示に基づいて詳細を埋めるのはかなり良かった。）

人々が自分のプロンプトをGitに提出するのは面白いね。これが一般的に受け入れられることになると思う？それとも、ただのプロンプトの見せびらかしだったのかな？

LLMとかを心から支持してる人たちの「崖から飛び降りる」ような行動は見たことないよ。意味不明なことを「学ぶ」ために、ブラックボックスに頼りすぎて、自分の仕事をやらせたり、レビューさせたりしてる。しかも、信じられないくらいのエネルギーを消費して、人を排除する口実に使われてるっていうのが本当にすごい！君の人生を10倍にしてるんだろうね！

関連：CloudflareのClaudeが生成したコミットを全部読んだよ https://news.ycombinator.com/item?id=44205697