コードを読まないことの擁護

 (benshoemaker.us)
38 ポイント 投稿者 GN⁺ 2026-02-25 | 3件のコメント | WhatsAppで共有
  • 「コードを読まない」とは、行ごとのレビューの代わりに 仕様、テスト、静的解析、本番シグナル に依存することを意味し、特定のリスク領域ではコードレビューへエスカレーション可能
  • OpenAI の Harness Engineering と OpenClaw の事例は、コードそのものではなく テスト・観測・自動検証インフラ に集中するアプローチを示している
  • ブラックボックス化、セキュリティ、バグの蓄積といった 懐疑論への反論 として、抽象化レイヤーの歴史的パターンと自動検証ツールの重要性を強調
  • コード読みを完全に排除するのではなく、安全・セキュリティ・アーキテクチャ判断時には直接レビューが必要 というバランスの取れた立場を提示
  • コードは次第に 実装の詳細 になりつつあり、仕様・アーキテクチャ・検証レイヤーが中核成果物として浮上する軌道に賭けるべきだ

「コードを読まない」の正確な意味

  • 以前の文章の「私はもうコードを読まない」という一文が、Hacker News で 200件以上の白熱したコメント を引き起こした
  • 正確には、大半のプロダクトコードに対して 行ごとのレビューを基本的な検証手段にしない という意味
  • 仕様とテスト、変更された diff の選別レビュー、本番シグナルは引き続き確認し、特定のリスク領域ではコード読解へエスカレーションできる
  • コードを読まない理由は、コードの重要性が低いからではなく、とくに大規模環境では 行単位の読解が正確性を保証する最も有効な方法ではないから

根拠となる事例

  • OpenAI の Harness Engineering

    • OpenAI は Harness Engineering のブログ記事で、ソフトウェアエンジニアリングチームの中心的役割がコード作成から 環境設計、意図の明文化、フィードバックループの構築 へ移ったと説明
    • 3人のエンジニアが Codex エージェント だけで100万行のコードを生成し、数百人の社内ユーザーが使う製品を構築
    • コードそのものよりも、その周辺にある ハーネス (harness) —ドキュメント、依存関係ルール、リンター、テストインフラ、観測体制— に重点投資
    • 行単位のコードレビューには別途投資していない

  • OpenClaw

    • たった1人でチームなしに作られた OpenClaw は、この数カ月で最も急成長したオープンソースプロジェクトの1つで、10万件超の GitHub スター を獲得
    • 5〜10個のエージェントを並列で動かす構成で、初心者ではない 経験豊富なエンジニア が設計・運用
    • 「私は読まないコードをデプロイする」というタイトルのインタビューで、リファクタリング、アーキテクチャ、テスト、そして AI コーディングを取り巻くハーネスに重点投資していると述べている

  • Coder から Orchestrator へ

    • ESLint を作り、O'Reilly の書籍を複数執筆したベテランエンジニア が、最近の記事 で、未来のソフトウェアエンジニアリングはコードを書くことではなく AI エージェントのオーケストレーション が中心になると展望
    • 中核スキルは文法や実装から アーキテクチャ設計、仕様記述、フィードバックループ設計 へ移行しつつある

懐疑論への反論

  • ブラックボックス批判

    • 「ブラックボックス的アプローチを自発的に選ぶ例があるのか」という批判に対し、コードの成果物はコード自体ではなく製品だ という点を強調
    • 写真家が写真を見ないのではなく、写真を生み出す カメラ内部の構造をのぞき込まないこと に近い比喩
    • 私たちが直接見ない 抽象化レイヤーの上にシステムを構築するやり方 は、ソフトウェアを含むさまざまな工学分野ですでに一般的な慣行

  • セキュリティ懸念

    • AI が生成したコードに バックドアが挿入される可能性への懸念 について、それは「すべての行を人間が読まねばならない」という問題ではなく ツール群と検証体制の問題 だとする
    • 静的解析、依存関係スキャン、セキュリティリンターは、人間も脆弱なコードを書くからこそ存在しており、解決策は より強力な自動検証体制、すなわちハーネス中心アプローチと同じ方向
    • ただし セキュリティにとくに敏感な領域 では依然として人間のレビューが必要

  • バグ蓄積の問題

    • 「コードが失敗すれば人々の金が消え、飛行機が止まり、車が故障する。コードを読め」という批判が最も頻繁
    • CodeRabbit のデータによれば、AI 生成コードは ソフトウェア品質全般で 1.7 倍多くの欠陥 を生じる
    • しかし AI コーディングのやり方は多様であり、仕様・階層的テスト・アーキテクチャ制約を備えたハーネス中心開発 は単なるバイブコーディングとは根本的に異なる
    • あるコメントで提示されたアプローチでは、仕様・テスト・静的解析に依存しつつ 85% 以上のテストカバレッジ を維持し、範囲を段階的に広げる統合テストである テスティングラダー (testing ladders) を構築し、ベンチマークと厳格なドッグフーディング (dogfooding) でエラーを早期に露出させる
    • 重要な問いは「AI コードは平均的にバグが多いか」ではなく、「よく設計されたハーネスの中で同じ速度で開発したとき、代替手段より多くのバグを出すのか」 である
    • Greg Brockman (OpenAI 共同創業者) も、人間が書いたコードと同じ基準を適用すべきだ という立場

実際のシステム構成

  • キャリアの大半でコードを書いてきており、主に社内ツールだったが、実際のユーザーが依存するシステムも扱ってきた
  • コードの形や構造は理解しているが、あえて直接読まないことを選んでいる

  • 仕様ベースのワークフロー

    • エージェントがコードを書く前に、AI との対話を通じて 非常に具体的で詳細な仕様 を先に作成
    • 要件 ID によって、製品仕様から実行計画まで追跡可能になるよう構造化
    • 実行計画のすべてのタスクに、検証方法が明記された受け入れ基準を含める
      • 自動テストは (TEST)
      • 視覚確認は (BROWSER:DOM)
      • 他に方法がない場合のみ (MANUAL) を使い、その場合でも可能な限り curl や bash ベースの自動チェックを先に作ろうとする
    • 具体的な検証メタデータがないタスクは、監査 (audit) スキルが作業開始前にブロック する

  • AI Coding Toolkit (ハーネス)

    • プロンプト、スキル、フック、スクリプトで構成されるツールキットがエージェントの作業方法を制約し、35 個以上のスキル、構造化されたエージェント指示、階層的検証インフラを含む
    • エージェント指示をインフラとして管理
      • AGENTS.md は主要ルール集として機能: 保守的な修正、既存インターフェースの維持、TDD の順守、推測禁止、git 履歴の書き換え禁止
      • VISION.md は戦略的な境界を定義
    • 階層的検証システム を運用
      • 各段階の終了後に、チェックポイントスキルが型チェック、リンティング、テスト、ビルド、ミューテーションテスト、セキュリティスキャンを含む多層ゲートを実行
      • ブラウザツールが使える場合は自動ブラウザ検証を実行
      • 変更された diff を 別の AI モデル (Codex CLI) に渡してセカンドオピニオンレビューを行う
      • クロスモデル検証 により単一モデルの死角を補う
    • コードを直接読むこともあるが、例外的な状況に限られる
      • すべてのテストが通っているのに製品の挙動が不自然に感じられるとき
      • 重大なアーキテクチャ判断を下す必要があるとき
      • 複数のエージェントでも解決できない障害をデバッグするとき
    • その場合でも目的はコード自体の分析ではなく、ハーネスのどの欠落が問題を許したのかを特定し、再発を防ぐこと

コードを読むべきとき

  • 安全が直接関わるシステム、セキュリティに敏感なサービス、重大なアーキテクチャ判断 では、ソフトウェアエンジニアリングはすなわち工学であり、今のようにコードが大量生成される時代には その重要性はむしろ高まっている
  • 航空分野の 「Children of the Magenta」 という比喩は、操縦士がナビゲーション画面のマゼンタ色の飛行経路に過度に依存するようになった現象を指す
    • 教訓は「オートパイロットを使うな」ではなく、必要なときに介入できる能力を維持せよ ということ
    • 問題が起きたら 自動化レベルを下げて基本に戻れるべき だが、すべての飛行を常に手動で行えという要求は非効率で、より危険ですらある
    • 自動化を活用しつつ介入能力を失わない、そのバランスが核心

軌道に賭けよ

  • コンピューティングにおけるあらゆる抽象化レイヤーは登場のたびに抵抗を受けてきた。その代表例が 1973 年に Dennis Ritchie と Ken Thompson が Unix を C で書き直した事例 である
  • 当時は遅くなる、ハードウェア制御を失う、複雑さが保守性を損なうといった批判があったが、C の抽象化は Unix を 高い移植性と影響力を持つ OS へと拡張した
  • 繰り返されるパターンは、抽象化されるレイヤーに専門性を持つ人たち がそのレイヤー理解の重要性を強調し、それが一部の状況では妥当である一方、大半の時間は より高い抽象化レイヤーで考え設計すること に費やされるようになるということ
  • コードを読まないという選択は、ツールが完璧だという宣言ではなく、多くのユースケースですでに十分に有効で、しかも急速に改善しているという流れへの判断 である
  • コードが消えるのではなく、ますます 実装の詳細 へと移っており、その代わりに 仕様、アーキテクチャ、検証レイヤー が中核成果物として浮上している

関連記事

3件のコメント

 
foriequal0 2026-02-25

AIプログラミングは、抽象化や自動化というより、むしろ外部化・外注化に近いように思えます。
設計と検証も、高度化や精密化のための要素というより、低信頼社会をかろうじてつなぎとめる規制のような要素として導入されている感覚です。
 
sang459 2026-02-25

的確な分析ですね
AIプログラミングは本質的に確率的であるという点が重要だと思います
 
chamchi 2026-03-03

AIでライブラリを作っていますが、リファクタリングやコード品質の向上、欠陥チェックもAIに回すべきだと思います