アイデアは正しかった。経済性が悪かった。
software engineering には、読んだ瞬間に「これは正しい」と分かる考え方がたくさんあります。
function が受け取ってよい値と返してよい値を contracts で定義するのは当然です。tests が数個の例だけでなく properties を検証するのも当然です。coverage を見るだけで安心せず、tests が本当に faults を検出できるか測るのも当然です。architecture decisions がコードと同期しているべきなのも当然です。
問題は、そのどれもが間違っていたことではありません。問題は経済性でした。これらの戦略は、多くのチームが最も増やしづらい資源、つまり specialist attention を大量に必要としました。
長い間、優れた engineering 戦略は同じサイクルで失速してきました。導入直後は効果が出ます。品質も上がります。けれど maintenance cost が到来します。contracts は drift し、property tests は schema changes に追いつかず、surviving mutants は triage されずに積み上がり、architecture docs は現実を表さなくなります。戦略が失敗した理由は、考え方が間違っていたからではありません。継続的に必要な expertise を普通の product team が維持できなかったからです。
だからこそ、今の AI の変化は重要です。大事なのは、models が code を速く書けることだけではありません。以前は高コストすぎた specification と verification の作業を、models がかなり吸収できるようになったことです。
何がこれらの戦略を niche に留めていたのか
問題は compute ではありませんでした。安い compute はすでにありました。
tooling だけの問題でもありませんでした。多くの分野では良い tools が存在していました。それでも、正しい invariants、generators、contracts、boundary rules を与えられる人が必要でした。
本当の bottleneck は、並列化しにくい expertise でした。
- 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、あるいは formal verification tooling への理解が必要でした。
- Living specifications には、人間の意思決定を executable な architecture rules に継続的に翻訳する作業が必要でした。
各戦略にはそれぞれ独自の maintenance tax がありました。複数を組み合わせると、さらにその間をつなぐ glue も必要になります。
だから多くの “good on paper” な手法は aerospace、finance、formal methods research、あるいは非常に disciplined な infrastructure teams に留まりました。方法論は機能したのです。機能しなかったのは staffing model でした。
AI は何を変えるのか
AI は engineering judgment を不要にするわけではありません。judgment を使う場所を変えます。
これまでは senior engineer が多くの scaffolding を手で書く必要がありました。今は model が first draft の contract を書き、properties を提案し、schema を作り、architecture rule を下書きし、surviving mutant に対する regression test まで提案できます。人間は blank page から始める代わりに、domain correctness を review できます。
この差はかなり大きいです。
以前の workflow は author-heavy でした。これからの workflow は review-heavy になります。
その結果:
- contracts の導入コストが下がる
- property-based testing が現実的になる
- mutation testing が運用しやすくなる
- architecture constraints を実際に enforcement しやすくなる
ここが経済的な unlock です。engineers を model で置き換えることではありません。specialist authorship が必要だった戦略を、普通の product team にとって実行可能にすることです。
重要なポイント: これらの戦略は組み合わせると強い
価値は単体の technique だけにあるわけではありません。
面白いのは、AI が stack 全体を手の届くものにすることです。
contract は property test の入力になります。property test は mutation testing で評価できます。schema は runtime boundary を定義できます。ADR は architecture rule に変えられます。branded type は runtime checks より前に surface area を狭められます。価値は個々の要素だけでなく、その間の glue にあります。
AI 以前は、多くのチームがそのうち一つを正当化するのがやっとでした。AI 以後は、複数を組み合わせても reliability work が specialist program になりません。
これは魔法ではない
もちろん、やり方を間違えることもあります。
AI に code、contracts、tests を生成させても、後ろに deterministic enforcement がなければ、もっともらしい text の山が増えるだけです。goal は model に repository を承認させることではありません。goal は model を使って、安く、繰り返し検証できる artifacts を作ることです。
だから勝つパターンは今でも地味です。
- AI で generate する
- deterministic tools で validate する
- specification level で review する
- ルール違反は CI で即 failure にする
AI の価値は expertise gap を埋めることにあります。最終判定者になることではありません。
なぜ今これが重要なのか
すでに多くのチームが AI で implementation time を縮めています。問題は、delivery speed が verification depth より先に伸びることです。
そうなると、生産的な engineering organization になるのではなく、fragile systems に向かう速度が上がるだけです。
本当のチャンスは、generation を速くするのと同じ models を使って、これまで高価すぎた reliability practices を復活させることです。そうすれば speed は operational debt に変わりません。
これから数年は、この違いを早く理解したチームが有利になります。AI-assisted coding だけでは戦略になりません。AI-assisted verification and enforcement が戦略です。
だからこそ、多くの古い engineering ideas が再び重要になっています。新しく正しくなったからではなく、ようやく経済的に実行可能になったからです。