低 - ドキュメント、コピー、内部専用機能、フラグの裏にある追加変更 > 自動レビューとセキュリティチェックが通れば、特に何も必要ない。 LLMにドキュメントを書かせて、それを読まないなんて、マジで狂気だよ。

人間が手を動かしてコードを理解する能力が、手動コードレビューの能力に直接依存してないってどういうこと？全然わからない。クラウドに解説を書かせる（これ、俺もよくやる！）だけじゃ、複雑なdiffを自信を持って評価できるところには至らないよね。しかも、diffが何を言ってるか、何をしてるかの先入観を、すでにレビューされて承認された同じシステムを通してフィルタリングしてるし。この文章は悪くないけど、人間の文脈を構築する部分にもっと重みを持たせるべきだと思う。

それで、利益が出てないAI企業が、自社のコードとレビューのプロセスをどうトークン最大化してるか説明してる。著者は、モデルを使うコストを考えなきゃいけない立場からこの記事を見るべきだよ。

1日に3万コミットもあったら、意味のあるレビューなんてできるの？

いいアイデアだね。俺も似たようなことを半年くらいやってる。最も重要なのは、バグを減らして、コードが思った通りに動くこと。コードテスト、ログ取り、実行中のアプリとのインタラクションは必須だよ。意図の再調整のために、エージェントにそのプロジェクトに投稿されたすべてのユーザーメッセージを再読させるのが好き。1万メッセージのプロジェクトでも、数分で終わるからね。その新しいユーザー意図を使って、コードとテストをチェックする。長期間の作業では、プロジェクト内にドキュメントとして残るtodoリストを生成するのが好き。各ゲートがエージェントからのフィードバックを追跡する。このタスクファイルは、実装前と後の2回レビューされる。だから、公式は - エージェントのレビュー - テスト - ユーザーメッセージのログだね。

アンスロピックのほとんどの人が自分たちの仕事が危ういと思ってるのも無理はないよ。すでに機械が彼らをペットのように扱うシステムを作っちゃってるからね。アンスロピックが「おそらく回転してる」ことを説明する傾向が全然理解できない。TUIでwhileループをラップするために、1日に多くの変更/PRがあるのは高圧的だよね？ここで減少主義にはならないから、これ以上は言わないけど、複数のターミナルエミュレーターを扱う複雑さは何らかの対処が必要だと思う（たとえ自分たちのレンダリングエンジンを作るのが自分たちの問題だったとしても）。そう、俺は自分でハーネスをゼロから作ったことがあるけど、どう動くかはわかってるよ。彼らがポイント2に実際に対処したかどうかもわからない。彼らは「システムが自分を検証する」って言ってるけど、それはクールだし、自動テストが何十年もやってきたことだけど、システム全体のメンタルモデルを避けて、必要なときにLLMに焦点を当てさせて、システムの一部を要約させるのが好きみたい。だけど...それは知識じゃないよね？ただのGoogleみたいな検索じゃない？だから、検索の質が、いつでも浮かび上がる知識の質を決定する同じ問題に直面してるように思える。注：記事がCCがどのように進むかについて曖昧なので、「1000 PR」を「高圧的な量」に変更した。