AIコーディングによってソースコードは潤沢になる一方、検証は依然として不足している
Google Newsは、人工知能とソフトウェアをめぐる刺激的な主張を取り上げた。コードは「write-only」、すなわち書くだけで読まれず、使い捨てになりつつあるという。これは現実の変化を捉えた表現だ。コーディングエージェントは、多くのチームが理解、レビュー、安全な取り込みを行うよりも速く実装を生成できる。
対立しているのは、単純な人間対機械ではない。生成速度と組織の理解力との対立である。AIはコードを生み出すコストを下げられる一方、完成したシステムが正しく、安全で、保守可能であり続けることを証明するコストを高める可能性がある。
この違いは重要だ。なぜなら、最も有力な証拠は、AIが書いたコードがすぐに捨てられるという単純な物語を支持していないからだ。むしろ、より深い逆転を示している。ソースコードは豊富になりつつある一方、仕様、アーキテクチャ上の判断、検証、説明責任は依然として希少である。
Google Newsの記事が実際に変えたこと
「write-only code」という論点は、AIコーディングをめぐる議論を入力速度からソフトウェアシステム全体の制御へと移している。
この言葉が注目を集めたのは、HeavybitのゼネラルパートナーであるJoseph Ruscioによるものだ。2026年2月の論考、write-only codeでは、エージェントが膨大な実装を生成し、人間がすべての行を読まなくなるエンタープライズの未来を描いている。
「write-only」は、コードが文字どおり読めないことを意味しない。生成された各行を読むことが、もはや主要な制御手段ではなくなるという意味だ。人間は代わりに、仕様、制約、テスト、アーキテクチャ、観測可能な振る舞いをレビューする。
これは、開発者がより優れた自動補完を使うようになるという話よりも踏み込んだ主張である。AIペアプログラマーでは、依然として人間が実装を書いたり、密にレビューしたりすることが前提となる。コーディングエージェントは、リポジトリを調査し、複数のファイルを編集し、コマンドを実行し、テストを走らせ、限られた介入で自身の作業を修正できる。
Google Newsが取り上げた記事は、エンジニアリングカンファレンスですでに進んでいる幅広い議論にも合致している。QCon London 2026でHannah Foxwellは、大量に生成されたコードをレビューすることは、楽しくも持続可能でもないと論じた。
彼女が提案したのは、ピアレビューを前倒しすることだ。チームは、エージェントが実装を書く前に、仕様、テスト戦略、アーキテクチャを検討する。InfoQのQCon coverageは、この提案をRuscioの「write-only code」という概念に直接結び付けた。
したがって、重要な出来事は製品リリースではない。AI支援開発のための一貫した運用モデルが現れつつあることだ。
このモデルでは、開発者が意図と許容される境界を定義する。エージェントはそれらの境界をコードへと変換する。自動化システムが結果をテストし、人はビジネス文脈やアーキテクチャ上の判断を要する意思決定に集中する。
このモデルは、レビューの単位を変える。数千行の生成コードを含むプルリクエストは、主要な信頼境界としての有用性が低下する。重要な成果物は、要件、脅威モデル、テストスイート、依存関係ポリシー、デプロイ計画、実行時の証拠になる。
使い捨てのAIコードは、このモデルのより積極的な端に位置する。エージェントは、一時的なマイグレーション、診断ツール、データコンバーター、テストフィクスチャ、プロトタイプを生成するかもしれない。チームは、目先の作業が完了すればソースを破棄する場合もある。
しかし、その影響がファイルとともに消えることはほとんどない。短命なスクリプトでも、データベースを変更し、シークレットを露出させ、クラウドリソースを作成し、誤った前提を顧客データに組み込む可能性がある。ソースは使い捨てでも、結果は長く残りうる。
だからこそ、Google Newsの枠組みは注目に値する。実際の変化に覚えやすい名前を与える一方、その名前は誤解も招きかねない。中心的な問いは、人間がすべての行を読むかどうかではない。チームが、それらの行の動作を統治するために十分な証拠と知識を維持できるかどうかである。
より高速な生成がエンジニアリング組織に圧力をかける
AIは実装をより安価な投入要素に変えるが、ソフトウェア提供を同じように安価にはしない。
従来のエンジニアリングプロセスでは、コード生成が大きな制約であることを前提としている。チームは作業を割り当て、変更を実装し、プルリクエストをレビューし、テストを実行し、承認済みビルドを本番環境へ移す。
コーディングエージェントは、実装段階を圧縮する。しかし、製品要件の明確化、セキュリティレビュー、統合テスト、運用準備、組織間の調整まで自動的に圧縮するわけではない。
Google CloudのDORA調査は、AIを増幅器として捉えている。AIは能力の高い組織を強化する一方、苦戦している組織の弱点も拡大する。2025 DORA reportは、成果がツール単体よりも、それを取り巻く組織システムに大きく左右されると論じている。
この知見は、エンジニアリングリーダーに即時の圧力をかける。エージェントがより多くの変更を生み出せば、レビュー担当者のキューは膨らむ。テストインフラへの負荷も増す。プラットフォームチームは、より多くの実験、環境、デプロイ試行を支えなければならない。
従来のボトルネックは消えるのではなく移動する。実装は吸収能力、すなわち組織が増え続ける変更の流れを理解し、統合し、検証し、運用する能力へと置き換わる。
ここで「write-only code」は運用上の重要性を持つ。開発者はエージェントに対し、エンドポイントの追加、テストの修正、ライブラリの移行、小規模な社内アプリケーションの構築を依頼できる。各依頼は、開発者が周辺システムを十分に調査する前に、もっともらしいコードを生み出しうる。
もっともらしさは正しさと同じではない。生成コードはプロンプトを満たしていても、文書化されていない慣習に違反する可能性がある。既存サービスを重複させたり、不適切な依存関係を選んだり、認可チェックを弱めたり、運用コストの高い経路を作ったりするかもしれない。
人間はかつて、変更を実装する過程でこうした制約の多くを学んでいた。扱いにくいインターフェースに直面し、近くのコードを読み、メンテナーに質問し、なぜ以前の決定が存在するのかを発見していた。
エージェントは、その学習過程の多くを飛ばせる。これはしばしば有用だが、組織的な理解の源泉も失わせる。実装は届くが、それを保守するために必要な知識を誰かが身に付けたことまでは保証しない。
この負担はまず、シニア開発者とメンテナーにのしかかる。彼らは、局所的には正しいパッチと、システム全体には有害なパッチを見分けるための文脈を持つ。生成が加速するほど、彼らの判断は共有される、そしてますます希少なサービスになる。
セキュリティチームも同様の問題に直面する。使い捨てのAIコードは、プロトタイプ、社内ダッシュボード、マイグレーションスクリプト、サポートユーティリティ、一時的な自動化を通じて入り込む可能性がある。こうした成果物は、顧客向けアプリケーションに適用される統制を回避しがちだ。
プロトタイプは、同僚が使い始めれば恒久化する可能性がある。一度きりのスクリプトが数か月後に再実行されるかもしれない。一時的な認証情報がログに入り込む可能性もある。テストデータが本番環境へ流出することもありうる。
圧力はジュニアエンジニアにも及ぶ。エージェントが定型的な実装を担うようになると、新しい開発者は、かつてコードベースの構造、デバッグ、本番環境での規律を学んだ作業の一部を失う。
チームは、AIを禁止したり、人間に生成されたすべてのトークンを検査するよう求めたりして、この問題を解決することはできない。意図的な学習経路、明確なオーナーシップ、より小さくレビュー可能な変更が必要だ。
アーキテクチャ上の決定を検索可能な形で記録することは、欠けた文脈の保持に役立つ。 technical knowledge baseを構築するチームは、仕様、インシデントレポート、設計上の制約を、エージェントが変更するコードに結び付けられる。
したがって、組織への圧力は明白である。AIコーディングツールは、すでに強力なテスト、文書化された境界、安定したインターフェース、迅速なフィードバックを備えるチームに報いる。一方で、暗黙知と英雄的なレビュー担当者に依存するチームの弱点を露呈させる。
「write-only code」は従来のレビュー契約を反転させる
従来の契約は、人間がコードを読んだ後に信頼するというものだった。新たに生まれつつある契約では、人間は制約を与え、テストした後の振る舞いを信頼する。
数十年にわたり、保守性とは、別のエンジニアが関数を読み、その意図を理解し、安全に変更できることを意味していた。命名、構造、コメント、モジュール性、ドキュメントはいずれも、人間の理解に役立つものだった。
「write-only code」は、その基準を支えてきた経済性に疑問を投げかける。エージェントが正確な仕様からコンポーネントを再生成できるなら、実装の細部をすべて維持する価値は低くなるかもしれない。
しかし、それによって保守性がなくなるわけではない。維持すべき対象が変わるのだ。
永続的な資産は、現在の実装ではなく仕様になる可能性がある。テストは、意図を実行可能な形で示すものになるかもしれない。内部の洗練性よりもインターフェース契約が重要になる可能性がある。アーキテクチャのルールは、文書内の指針ではなく、機械によって強制される制約になりうる。
この反転は、ソフトウェア抽象化における過去の変化に似ている。今日、多くの開発者はアプリケーションを出荷する前に、生成された機械語命令を確認しない。コンパイラ、型システム、テスト、オペレーティングシステム、ランタイム監視を信頼している。
AIが生成するコードには重要な違いがある。コンパイラは、範囲が限定された決定論的な変換を行う。コーディングエージェントは、設計、依存関係、API、振る舞いについて確率的な判断を下す。
この違いにより、チームはエージェントを単なる別のコンパイラとして扱えない。エージェントにはハーネス、すなわち作業を制約するツール、権限、文脈、テスト、フィードバックループが必要となる。
優れたハーネスは、禁止された依存関係を拒否し、モジュール境界を強制し、ネットワークアクセスを制限し、セキュリティスキャナーを実行し、変更を受け入れる前にテストを要求できる。また、生成された編集を、意味のあるAIコードレビューが可能な大きさに保つこともできる。
レビュー自体も多層化する必要がある。高速な自動チェックは、フォーマット、型、依存関係ポリシー、既知の脆弱性、テスト、アーキテクチャルールを対象とすべきだ。人間のレビュー担当者は、意図、トレードオフ、脅威境界、障害モードに集中すべきである。
これは、テストスイートが通ったからという理由で、巨大で不透明なパッチのマージを許すものではない。テストが検証できるのは、表現されているケースだけだ。誰も特定していない前提を守ることはできない。
仕様にも同じ限界がある。エージェントは詳細な依頼に従っていても、誤った製品を作る可能性がある。要件には、アクセシビリティの必要性、保持ポリシー、地域ごとのルール、運用上の制約が欠けているかもしれない。
したがって、新たに生まれつつあるレビュー契約には、複数の制御点がある。人が何を変更すべきかを承認する。機械が定義済みの制約が満たされているかを確認する。本番テレメトリーが、最終的な振る舞いが現実と一致するかを明らかにする。
それぞれの制御点は異なる種類の失敗をカバーする。どれか一つだけでは十分ではない。
この変化は、チームが開発者の生産性を評価する方法も変える。生成された行数、完了したタスク数、作成されたプルリクエスト数は活動量を測る。しかし、ユーザーが価値を得たか、システムがより運用しにくくなったかは示さない。
DORAの後続分析では、AI導入の増加はスループットの向上と不安定性の増加の両方に関連していた。そのAI delivery tensionsに関する議論は、作成時に節約された時間が、監査と検証に再配分されることが多いとしている。
その結果は、コーディングが速く感じられても、デリバリーが同じ割合で速くなるとは限らない理由を説明している。開発者は生成による即時的な恩恵を得る一方、組織は統合の遅延コストを負う。
実務上の境界線は、手書きコードか生成コードかではない。統制された変更か、統制されていない変更かだ。
サンドボックス内で動作する孤立した変換処理であれば、統制された使い捨てAIコードは合理的であり得る。対照的に、統制されていない生成コードは、すべての行が一般的に見え、何年もリポジトリに残り続けたとしても危険になり得る。
エビデンスは使い捨てAIコードという主張を複雑にする
AIが作成したコードが、すべての実際の開発環境において自動的に短命・低品質・高速に作成できるとは限らない。
Musfiqur Rahman氏とEmad Shihab氏による2026年のプレプリントは、201のオープンソースプロジェクトにまたがる20万超のコードユニットを調査した。そのコード生存性研究は、使い捨てコードの語りに反する結果に到達している。
行単位では、エージェント作成コードの変更率は人間作成コードより15.8ポイント低く、変更ハザードも16％低かった。言い換えれば、観測されたAIコードはより長く存続していた。
ただし、これはAIコードが優れていたことを証明するものではない。コードが変更されないのは、正常に動作しているからかもしれないし、誰にも使われていないからかもしれない。あるいは、保守担当者が触ることをためらっている可能性もある。長寿命であることだけでは、こうした説明を区別できない。
この研究では、エージェント作成コードの修正目的の変更率がやや高く、人間作成コードの23％に対して26.3％だったことも分かった。個々のエージェント間のばらつきは、エージェント全体と人間全体の差を上回っていた。
これらの結果は、作成元というラベルが粗すぎることを示唆している。モデルの選択、タスクの種類、リポジトリの品質、人間による監督、組織の実践は、AIが最初の草案を作成したかどうかより重要になり得る。
別の実験は、もう一つの厄介な結論に達した。METRは、自らが保守する成熟したオープンソースリポジトリで作業する経験豊富な開発者16人を募集した。この試験は246件の実際の課題を対象とし、AIツールの使用をランダムに許可または禁止した。
2025年初頭のAIツールを使用した開発者は、割り当てられた課題の完了に19％長い時間を要した。生産性試験では、印象的な認識の乖離も明らかになった。
参加者は作業完了前、AIによって24％速くなると予想していた。その後も、測定上は遅くなっていたにもかかわらず、AIが20％高速化したと信じていた。
研究者らは、この結果をすべての開発者やタスクに一般化しないよう警告している。参加者は大規模なリポジトリをよく理解しており、ツールも急速に変化する市場の特定時期を代表するものだった。
こうした制約があっても、この研究は使い捨てAIコードに関する主張の重要な弱点を浮き彫りにしている。高速な生成は、高速な完了と同じではない。プロンプト作成、待機、確認、修正、統合によって、一見した利得は消費され得る。
開発者の意識もこの慎重論を裏付けている。Stack Overflowの2025年調査では、AI利用が拡大を続ける一方で、信頼は低下した。AIの正確性を信頼していた回答者は29％にとどまり、以前の調査の約40％から低下している。
同社の開発者信頼分析によれば、回答者の84％超がAIツールを利用している、または利用を予定していた。導入と信頼は逆方向に動いていた。
これらの知見は、書き捨てコードを否定するものではない。必要となる条件を明確にするものだ。
第一に、再生成は、現行実装を理解して修復するよりも本当に低コストでなければならない。これは、決済台帳よりも小規模なアダプターやテストフィクスチャのほうが成立しやすい。
第二に、仕様が実際の要件を十分に捉えていなければならない。ハッピーパスしか記述しないプロンプトでは、安全な再生成を支えられない。
第三に、環境が受け入れられない挙動を検出できなければならない。テスト、ポリシーチェック、アクセス制御、実行時の可観測性がなければ、チームは成功した生成ともっともらしい失敗を区別できない。
第四に、誰かが結果に責任を持たなければならない。エージェントは障害、プライバシー侵害、セキュリティインシデントに対して責任を負えない。人間と組織の責任は、作成主体が変わっても残り続ける。
したがって、懐疑的な見方は重要である。「使い捨て」は、設計品質や文書化を怠るための都合のよい言い訳になり得る。チームは後でコンポーネントを再生成できると考えるかもしれないが、実際の仕様が本番環境での挙動とスタッフの記憶の中にしか存在しなかったことを、後になって発見する可能性がある。
コードは安価に再作成できても、文脈の復元には高いコストがかかり続ける。
使い捨てのソースは永続的なセキュリティおよびデータへの影響を残し得る
生成されたソースを削除しても、そのソースが実行した操作は元に戻らない。
ある開発者がエージェントに、一回限りの顧客データ移行を作成するよう依頼したとする。スクリプトは古いスキーマを読み取り、レコードを変換して新しいサービスに書き込む。
チームは移行後にスクリプトを削除するかもしれない。しかし、変更されたレコードは残る。破損したフィールド、漏えいした識別子、不完全な監査記録、意図しない権限も同様に残る。
生成されたインフラストラクチャスクリプトも同じ問題を生む。公開ストレージバケット、広範なサービスアカウント、長期有効な認証情報をプロビジョニングする可能性がある。ファイルを削除しても、必ずしもリソースは削除されない。
一時的な社内アプリケーションにも、恒久化する傾向がある。営業チームが生成されたダッシュボードを使い始める。オペレーション部門がその出力に依存する。元の開発者は別のプロジェクトに移る。
使い捨てAIコードとして始まったものが、今では業務プロセスを支えている。所有者、依存関係ポリシー、バックアップ計画、アクセシビリティレビュー、インシデント手順が欠けている可能性がある。
このリスクは、エージェントに広範な権限を与えると増大する。シェルコマンドの実行、ネットワークサービスへのアクセス、データベース照会、変更の公開ができるコーディングエージェントは、補完ツールよりはるかに大きな影響を持つ。
権限確認のプロンプトが提供する保護は限定的だ。特にツールが多数の要求を出す場合、人は承認に慣れてしまう。より強力な防御は、決定論的な隔離である。
エージェントには、タスクに必要な最小限のファイルシステム、ネットワーク、認証情報、デプロイ権限のみを与えるべきだ。高リスクな操作は、明確なログと有効期限ルールを備えた隔離環境で実施すべきである。
チームは、可逆的な操作と不可逆的な操作も区別すべきだ。ローカルファイルの生成は通常、可逆的である。メッセージ送信、本番データの削除、共有シークレットのローテーション、外部アカウントの変更はそうではない可能性がある。
不可逆的な操作を許可する前に、システムはより強い証拠を求めるべきである。その証拠には、ドライラン、人間による承認、変更プレビュー、バックアップ確認、ポリシー評価などが含まれる。
AIコードレビューでは、ソーススタイルだけでなく副作用を検討しなければならない。レビュー担当者は、プログラムがどのデータを読み取り、どのシステムに接続し、どの状態を変更し、操作をどのようにロールバックできるかを問うべきだ。
プロベナンスも重要である。チームは、どのモデルまたはエージェントが変更を生成したか、どの仕様を受け取ったか、どのツールを呼び出したか、どのテストが実行されたか、誰が結果を承認したかを把握する必要がある。
この記録は官僚的な飾りではない。生成された実装が後に置き換えられたり削除されたりした場合に、調査担当者が障害を再構築する助けになる。
サプライチェーンリスクも、もう一つの永続的な影響を生む。エージェントは名前の類似性や古い例に基づいて依存関係を選択するかもしれない。そのパッケージは、初期コードが消えた後も長く脆弱性やライセンス上の義務をもたらし得る。
リポジトリの管理機構は、未知のパッケージをブロックし、ロックファイルを必須とし、ライセンスをスキャンし、インストール元を制限できる。エージェントは利便性のためにそれらを回避するのではなく、その管理機構の内部で動作すべきだ。
目標は、すべての使い捨てソースを永久に保存することではない。ソースがもたらした影響を説明し統制するために必要な証拠を保存することである。
一時的なプログラムは、その環境が隔離され、入力が管理され、出力が検証され、寿命が強制される場合に一時的であり続けられる。こうした条件がなければ、「一時的」は性質ではなく意図を表すにすぎない。
Google Newsの読者が次に注目すべきこと
書き捨ての未来を決めるのは、コード生成のデモではなく、検証の経済性である。
最初に注目すべきシグナルは、組織がレビューを上流へ移すかどうかだ。エージェントが実装を始める前に、仕様、テスト計画、脅威モデル、アーキテクチャ上の制約に、より正式な注意が払われるべきである。
そのような変化の証拠は、書き捨てコードの論点を強める。チームは意図を永続的な成果物として扱い、実装をその置き換え可能な表現として扱うことになる。
プルリクエストだけが増大し、レビューの実践が変わらなければ、この論点は運用モデルとして弱まる。結果として生じる理解の問題を解決せず、コード量だけを説明することになる。
第二のシグナルは、個人の生産性とともにデリバリー指標も改善するかどうかである。組織はリードタイム、変更失敗率、復旧時間、流出した欠陥、運用負荷を測定すべきだ。
生成コードが増えることは成功ではない。安定した本番挙動を伴う完成済み機能が増えることが成功である。
DORAの研究は、AIがスループットを増加させる一方で、不安定性も増加させ得ることを示唆している。両面で持続的な改善が見られれば、テスト、プラットフォームエンジニアリング、ガバナンスが生成技術に追いついていることを示すだろう。
不安定性が続けば、逆の結論を支持することになる。それは、組織が安全に受け止められる速度を上回って実装を生み出していることを意味する。
第三のシグナルは、コーディングエージェントがより強力で測定可能な隔離を得るかどうかである。デフォルトのサンドボックス化、制限された認証情報、機械可読なポリシー、完全なツールログ、不可逆的操作への必須承認に注目すべきだ。
これらの管理策は、人間がすべての行を確認しない場合でも影響を制約するため、使い捨てAIコードをより安全にする。また、企業がより大きなタスクを委任するための信頼できる根拠にもなる。
エージェントに関連する漏えい、無許可の変更、放置された社内アプリケーションが増えれば、このモデルの弱点が露呈する。それは、廃棄によって可視性は低下したものの、結果としての影響は低下しなかったことを示すだろう。
読者は、すべてのAIコーディングワークフローを一つのカテゴリとして扱うことにも抵抗すべきだ。生成されたユニットテスト、リポジトリ移行、自律的な本番変更は、それぞれ異なるリスクを持つ。
適切な監督水準は、データの機密性、可逆性、システムの重要性、検証への信頼度に左右される。チームには、一律の承認プロセスではなく明示的な分類が必要である。
Google Newsは挑発的な表現を注目させたが、その表現は分析の終わりではなく始まりであるべきだ。コードは説明責任を失わずに書き捨てになり得る。結果を伴わないものにならずに、置き換え可能になることもできる。
実務上の課題は、意図、制約、テスト、プロベナンス、運用上の証拠を、いかなる単一の実装よりも永続的なものにすることだ。その均衡を実現できるチームは、制御を手放すことなく、より安価な生成の恩恵を受けられる。
そうした制御を説明できないチームは、自分たちのコードを使い捨てと呼ぶ前に立ち止まるべきだ。より難しい問いを投げかけるべきである。誰もこの実装を完全には読まないなら、顧客が気付く前にどの信頼できるシステムが誤りを見つけるのか。
