危険すぎるコード読み飛ばし：LLMがあなたが読むより速くコードを書くとき

前提はシンプルだ：LLMが生成したコードを一切読むのをやめたらどうか？ アセンブリ、バイトコード、トランスパイルされたJavaScriptのように扱うのだ — 高水準言語のソースも一種のマシンコードと見なす。このアイデアはThoughtworksのリトリート報告書とFacundo Olanoのブログ記事に基づいている。

なぜこれが理にかなうのか

LLMは非決定論的な出力を生成し、人間が読むよりはるかに速くコードを生み出す。すべての差分をレビューすることはもはや現実的ではない。厳密性を放棄するのではなく、仕様とテストに移すのだ。

組織的な前提条件

これは個人やチームレベルの判断ではなく、組織的に決定されなければならない。アムダールの法則が当てはまる：プロセスを再構築せずにコード生成速度だけを最大化しても、真の利益は得られない。ある開発者が1日に2万行の粗悪なコードを量産し、他の開発者がそれを読んで承認するという体制は持続不可能だ。

要件は次の通り：

• 人間をループから外し、調整やゲートキーピングを減らす
• 事実上無限の要求量、エンジニアが自律的に作業ストリームを担当する
• やり直しのコストがほぼゼロなので、誤った作業を防ぐのではなく、仕様/テストで検出する

提案されるワークフロー

標準化されたMarkdown仕様を新しい知識単位として使う。プロダクトオーナーとエンジニアが協力して、ビジネスルールの仕様とテストケースを作成する。これらを実装コードと一緒にリポジトリにチェックインする。

自動化されたプルリクエストチェックで以下を検証：

• テストが通っているか
• コードが仕様に準拠しているか

チームが理解し、レビューし、責任を持つのは仕様であって、コードではない。

重要な区別

仕様はプロンプトではない。テストはTDDではない。これは厳密性を実装層ではなく契約層に移すことだ。