使い捨て vs 耐久：AIエージェントでコード品質がまだ重要なとき

AIコーディングエージェントはチームが生産できるコードの量を変えた。どのコードが投資に値するかについての判断の必要性を取り除いたわけではない。

Max Kanat-AlexanderのAI Engineer NYC 2026での最近の基調講演は、きれいな意思決定ルールを与える：コード品質は常に二つの理由のために存在してきた——システムを理解することと、それを安全に変更すること。他のすべて（構造、テスト、可読性、レビュー）はこれらの二つの目標に奉仕するものだ。

これらの二つの目標が重要でなくなったとき、品質も重要でなくなる。

使い捨てソフトウェアが今やデフォルトのボリューム

Kanat-Alexanderは、常に存在していたがこれから大幅に一般的になるカテゴリを説明する：使い捨てソフトウェア。

それは持つ：

失敗した場合の結果が最小またはゼロ
人間またはシステムの依存者が少ない（またはない）
捨てて再生成するコストがほぼゼロ
本質的に長期のメンテナンス負担がない

その世界では、品質実践が防ぐように設計されていた累積リスクの大部分が消える。出力を一時的なものとして扱える。エージェントは再生成が安いので、このカテゴリを大規模に実用的にする。

耐久ソフトウェアは反対だ：長寿命、多くの依存者、本物の本番結果、理解の喪失の高いコスト。そのソフトウェアにとって、品質はまだ重要だ——そしてある意味ではより重要で、不透明さのコストが非線形に複合するからだ。

チームにとっての実用的な問いはもはや「品質は重要か？」ではない。「私たちのシステムのどの部分が使い捨てで、どれが耐久か？」だ。

基調講演を見る：Does Code Quality Still Matter? — Max Kanat-Alexander

ソフトウェア工場が区別にフィットする

エージェント的ワークフローに関する最近のトークは同じ方向を指す。

David Ondrejのソフトウェア工場（トリガー、スキル、チェック、人間のゲートを持つエージェントループの集合）のフレーミングは、工場が耐久コアを保護しながら多くの使い捨て中間作業を生産することを許されるときに最も有用だ。スケジュールされたチェック、バグトリアージ、探索的プロトタイプ、ワンオフ分析は軽い基準で走れる。アーキテクチャ変更、共有ライブラリ、本番制御プレーンはそうできない。

Kerim Satirli（HashiCorp）は、エージェントを自由なジュニアエンジニアではなく、制約されたCI/CDパイプラインのように扱うと説明する。プロンプトルールはリクエストだ；硬い制約と決定論的チェックが本当のガードレールだ——特に本質的に耐久なインフラ上で。

Carlos Kelkboomのルール——理解できない瞬間に生成されたコードを捨てる——は使い捨て/耐久分割の直接の適用だ。説明できないなら、それは耐久表面に属さない。

それに続く実用的なルール

生成前に分類する。 任意の非自明な作業について、事前に決める：予想寿命、爆発半径、依存者の数、置換コスト。書き留める。
どこでも安全の床を保つ。 使い捨てコードでさえ、資格情報を漏洩させたり、確認なしで破壊的操作を開いたり、ログに秘密を残したりしてはいけない。セキュリティとプライバシーは、コードが一時的だからといってオプションにはならない。
耐久表面に厳格さを集中させる。 テスト、所有権、可観測性、レビュー、明確な構造は、一年後もまだそこにあって他のシステムが依存する部分に属する。
厳格さを安くする。 Kanat-Alexanderの第二のレバーは正しいことをするコストを下げることだ：標準、ワークフロー内ツール、簡単なテスト、最大の厳格さで、抵抗の最も少ない道が安全な道になるようにする。それが耐久作業がボトルネックになるのを防ぐ。
役立つところで使い捨てのために設計する。 実験を隔離し、結合を低く保ち、使い捨てスクリプトの英雄的メンテナンスより再生成を好み、使い捨てコードをうっかり耐久コアに昇格させるのを避ける。

これがボトルネックビューの隣にどう位置するか

以前の投稿は、ボトルネックがコードを書くことからレビュー、信頼、検証に移ったかをカバーした。使い捨て/耐久フレームは欠けていた分類を追加する：すべての生成された変更が同じ検証予算に値するわけではない。すべてを耐久として扱うチームはレビューで溺れる。すべてを使い捨てとして扱うチームは不透明で高リスクのシステムを蓄積する。

高レバレッジのスキルは二つを正しく仕分けし、それから使い捨て側で自由に生成しながら耐久側で理解と変更の安全を保護するエージェント工場を走らせることだ。

出典：