アイデアは正しかった。経済性が悪かった。
ソフトウェアエンジニアリングには、読んだ瞬間に「これは正しい」と分かる考え方がたくさんあります。
function が受け取ってよい値と返してよい値を contracts で定義するのは当然です。tests が数個の例だけでなく properties を検証するのも当然です。coverage を見るだけで安心せず、tests が本当に faults を検出できるか測るのも当然です。architecture decisions がコードと同期しているべきなのも当然です。
問題は、そのどれもが間違っていたことではありません。問題は経済性でした。これらの戦略は、多くのチームが最も増やしづらい資源、つまり継続的な専門家の注意を大量に必要としました。
長い間、優れたエンジニアリング戦略は同じサイクルで失速してきました。導入直後は効果が出ます。品質も上がります。けれど維持コストが到来します。contracts は drift し、property tests は schema changes に追いつかず、surviving mutants は triage されずに積み上がり、architecture docs は現実を表さなくなります。戦略が失敗した理由は、考え方が間違っていたからではありません。継続的に必要な専門知を普通のプロダクトチームが維持できなかったからです。
だからこそ、今の AI の変化は重要です。大事なのは、models が code を速く書けることだけではありません。以前は高コストすぎた specification と verification の作業を、models がかなり吸収できるようになったことです。
何がこれらの戦略をニッチに留めていたのか
問題は計算資源ではありませんでした。安い計算資源はすでにありました。
工具だけの問題でもありませんでした。多くの分野では良い tools が存在していました。それでも、正しい invariants、generators、contracts、boundary rules を与えられる人が必要でした。
本当のボトルネックは、並列化しにくい専門知でした。
- Design by contract には、preconditions、postconditions、invariants を refactor 後も有効な形で保守できる engineers が必要でした。
- Property-based testing には、examples ではなく round trips、idempotence、error behavior、algebraic properties で考えられる人が必要でした。
- Mutation testing には、survivors が本物の test gap なのか equivalent mutants なのかを判断できる triage 能力が必要でした。
- Type-level correctness には、branded types、phantom types、typestates、あるいは形式検証ツールへの理解が必要でした。
- Living specifications には、人間の意思決定を executable な architecture rules に継続的に翻訳する作業が必要でした。
各戦略にはそれぞれ独自の維持税がありました。複数を組み合わせると、さらにその間をつなぐ接着剤も必要になります。
だから多くの「紙の上では立派に見える」手法は航空宇宙、金融、形式手法研究、あるいは非常に規律あるインフラチームに留まりました。方法論は機能したのです。機能しなかったのは人員体制でした。
AI は何を変えるのか
AI はエンジニアリング判断を不要にするわけではありません。判断を使う場所を変えます。
これまではシニアエンジニアが多くの足場を手で書く必要がありました。今は model が first draft の contract を書き、properties を提案し、schema を作り、architecture rule を下書きし、surviving mutant に対する regression test まで提案できます。人間は白紙から始める代わりに、ドメインの正しさを review できます。
この差はかなり大きいです。
以前の進め方は 記述負荷が高いでした。これからの進め方は レビュー負荷が高いになります。
その結果:
- contracts の導入コストが下がる
- property-based testing が現実的になる
- mutation testing が運用しやすくなる
- architecture constraints を実際に enforcement しやすくなる
ここが経済的な突破口です。engineers を model で置き換えることではありません。専門家による起草が必要だった戦略を、普通のプロダクトチームにとって実行可能にすることです。
重要なポイント: これらの戦略は組み合わせると強い
価値は単体の technique だけにあるわけではありません。
面白いのは、AI が stack 全体を手の届くものにすることです。
contract は property test の入力になります。property test は mutation testing で評価できます。schema は runtime boundary を定義できます。ADR は architecture rule に変えられます。branded type は runtime checks より前に surface area を狭められます。価値は個々の要素だけでなく、その間の接着剤にあります。
AI 以前は、多くのチームがそのうち一つを正当化するのがやっとでした。AI 以後は、複数を組み合わせても信頼性の仕事が専門家向けプログラムになりません。
これは魔法ではない
もちろん、やり方を間違えることもあります。
AI に code、contracts、tests を生成させても、後ろに deterministic enforcement がなければ、もっともらしい text の山が増えるだけです。goal は model に repository を承認させることではありません。goal は model を使って、安く、繰り返し検証できる artifacts を作ることです。
だから勝つパターンは今でも地味です。
- AI で generate する
- deterministic tools で validate する
- specification level で review する
- ルール違反は CI で即 failure にする
AI の価値は専門知の不足を埋めることにあります。最終判定者になることではありません。
なぜ今これが重要なのか
すでに多くのチームが AI で実装時間を縮めています。問題は、開発速度が 検証の深さより先に伸びることです。
そうなると、生産的な開発組織になるのではなく、脆いシステムに向かう速度が上がるだけです。
本当のチャンスは、generation を速くするのと同じ models を使って、これまで高価すぎた信頼性実践を復活させることです。そうすれば speed は運用負債に変わりません。
これから数年は、この違いを早く理解したチームが有利になります。AI-assisted coding だけでは戦略になりません。AI-assisted verification and enforcement が戦略です。
だからこそ、多くの古いエンジニアリングの考え方が再び重要になっています。新しく正しくなったからではなく、ようやく経済的に実行可能になったからです。