Идеи были хорошими. Экономика была плохой.
В software engineering полно идей, которые кажутся очевидно правильными в ту же секунду, когда ты их читаешь.
Разумеется, contracts должны определять, что функция имеет право принимать и возвращать. Разумеется, tests должны проверять properties, а не только несколько вручную выбранных примеров. Разумеется, команде стоит измерять, действительно ли tests ловят faults, а не считать coverage достаточной. Разумеется, архитектурные решения должны оставаться синхронизированными с кодом, которым они управляют.
Ничего из этого не было спорным. Проблема была экономической. Эти стратегии были дорогими ровно в том ресурсе, который большинству команд сложнее всего масштабировать: в специализированном внимании.
Годами сильные инженерные подходы попадали в один и тот же цикл. Команда внедряла практику. Качество росло. Потом приходила цена поддержки. Contracts начинали drift. Property tests переставали успевать за изменениями schema. Surviving mutants копились без triage. Архитектурные документы превращались в художественную литературу. Стратегия проваливалась не потому, что была неверной. Она проваливалась потому, что требовала постоянного уровня expertise, который обычная продуктовая команда не могла удерживать.
В этом и состоит настоящий контекст нынешнего AI-момента. Важный сдвиг не в том, что модели пишут код быстрее. Важный сдвиг в том, что они теперь могут взять на себя заметную часть specification и verification работы, которая раньше делала эти практики слишком дорогими.
Что действительно удерживало эти стратегии в нише
Проблема была не в compute. Дешевый compute давно доступен.
Проблема была и не только в tooling. Хорошие tools существовали для многих из этих подходов. Но все равно нужен был человек, который умеет формулировать правильные invariants, generators, contracts и boundary rules.
Настоящим bottleneck была expertise, которую трудно параллелить.
- Design by contract требовал engineers, способных писать и поддерживать preconditions, postconditions и invariants так, чтобы они оставались полезными после refactor.
- Property-based testing требовал людей, которые смотрят на function и думают категориями round trips, idempotence, error behavior и algebraic properties, а не только примеров.
- Mutation testing требовал triage surviving mutants, чтобы отличать реальные gaps от harmless equivalent mutants.
- Type-level correctness требовал уверенной работы с branded types, phantom types, typestates и даже formal verification tooling.
- Living specifications требовали постоянного перевода человеческих решений в enforceable architecture rules.
У каждой стратегии был свой maintenance tax. Комбинировать несколько было еще дороже, потому что нужен был glue между ними.
Поэтому так много идей, которые были “good on paper”, оставались внутри aerospace, finance, formal methods research или у необычно дисциплинированных infrastructure teams. Методы работали. Staffing model не работал.
Что меняет AI
AI не убирает engineering judgment. Он меняет, где именно этот judgment тратится.
Раньше senior engineer должен был вручную писать почти весь scaffolding. Теперь модель может набросать первый contract, предложить properties, собрать schema, предложить architecture rule и даже сделать первый regression test для surviving mutant. Человек проверяет domain correctness вместо того, чтобы начинать с пустого листа.
Это значит намного больше, чем может показаться.
Старый workflow был author-heavy. Новый workflow становится review-heavy.
Это означает:
- contracts дешевле внедрять
- property-based testing становится практичнее
- mutation testing становится полезнее в реальной работе
- architecture constraints легче реально enforce
Вот в чем настоящий экономический unlock. Речь не о замене engineers моделью. Речь о том, чтобы сделать доступными стратегии, которые раньше требовали specialist authorship.
Главное наблюдение: эти стратегии усиливают друг друга
Самое интересное не в каждой технике по отдельности.
Самое интересное в том, что AI делает доступным весь stack как систему.
Contract может стать источником для property test. Property test можно оценить через mutation testing. Schema может определить runtime boundary. ADR может превратиться в architecture rule. Branded type может сузить surface area еще до того, как сработает runtime check. Ценность не только в отдельных частях. Ценность в glue между ними.
До AI большинство команд едва могли оправдать хотя бы одну из таких стратегий. После AI уже реалистично комбинировать несколько, не превращая reliability work в отдельную программу специалистов.
Это не магия
При этом все еще можно сделать неправильно.
Если позволить AI генерировать code, contracts и tests без deterministic enforcement, получится просто еще большая куча правдоподобного текста. Цель не в том, чтобы модель «одобрила» codebase. Цель в том, чтобы использовать модель для создания artifacts, которые можно дешево и повторяемо проверять.
Поэтому выигрышный паттерн остается скучным:
- generate с помощью AI
- validate с помощью deterministic tools
- review changes на уровне specification
- заставлять CI быстро fail при нарушении правила
AI ценен здесь потому, что закрывает gap expertise, а не потому, что должен быть последним судьей.
Почему это важно именно сейчас
Команды уже используют AI, чтобы сжимать implementation time. Риск в том, что delivery speed растет быстрее, чем verification depth.
Если это произойдет, вы не получите более продуктивную engineering organization. Вы получите более быстрый путь к fragile systems.
Возможность состоит в том, чтобы использовать те же модели, которые ускоряют generation, для возрождения reliability practices, исторически слишком дорогих для большинства команд. Так скорость не превращается в operational debt.
Ближайшие годы вознаградят команды, которые рано поймут эту разницу. AI-assisted coding само по себе не стратегия. AI-assisted verification and enforcement уже стратегия.
Именно поэтому так много старых инженерных идей снова становятся важными: не потому, что они внезапно стали более правильными, а потому, что наконец стали экономически практичными.