Когда-то сервер был домашним питомцем.

Имя.

Особый конфиг в /etc, который никто не трогает с 1861 года.

— Этот не перезагружай. У него после ребута сеть иногда не поднимается.

Потом пришёл Ansible.

Сервер стал как UniSol.

Что-то сломалось — сделали нового.

Такого же.

С тем же состоянием.

Без многолетней археологии внутри.

Kubernetes пошёл дальше.

Pod down.

Up.

Поднялся следующий.

Нужно больше — стало больше.

Пользователь вообще ничего не заметил.

Каждый раз очередной слой инфраструктуры переставал быть чем-то, что нужно беречь годами.

Сейчас AI начинает делать то же самое с кодом.

Тут становится интересно.

Мы всё ещё во многом пишем программы так, будто этот код должен пережить Рагнарёк.

Аккуратно расширяем.

Рефакторим.

Ничего не ломаем.

Ну почти.

Храним архитектурные решения давно умерших задач.

Салфетки под стеклом.

Если реализацию можно получить заново за часы или минуты — ценность самой реализации меняется.

Есть входной контракт.

Есть выходной контракт.

Есть требования к поведению.

Контракт — это не обязательно API.

Это может быть внешний вид страницы.

Формат PDF.

Правила обработки данных.

Время ответа.

Поведение при ошибке.

Результат вычисления.

Что угодно, что можно достаточно точно проверить.

Что происходит внутри — уже вопрос реализации.

Появилась новая фича.

Можно три недели аккуратно встраивать её в код пятилетней давности.

Можно заново описать требования к модулю.

Переписать его.

В пятницу.

Прогнать контракты.

Заменить.

Вот здесь кодовая база начинает выглядеть совсем иначе.

Перестаёт быть активом, который необходимо сохранять любой ценой.

Становится расходником.

Текущим выражением задачи.

Сегодня задача выглядит так — код такой.

Завтра требования изменились — код другой.

Неожиданно расцветает новая добрая слабая связанность.

Уже по другой причине.

Модульность нужна не потому, что в книжке по архитектуре так написано.

Небольшой независимый модуль просто дешевле выбросить и написать заново.

Радиус поражения меньше.

Монолит в таком мире плох не потому, что в него мало кто умеет.

Если половину системы проще пересоздать, хочется иметь возможность пересоздать именно половину системы.

Не проводить археологическую экспедицию по двадцати годам зависимостей и для этого выводить архитектора с запоя.

Где-то здесь снова появляется BDD.

Возможно, уже в своей более буквальной форме.

«Бизнес» описывает, что система должна делать.

Не в виде:

— Сделайте нам удобнее.

В виде формальных декларативных требований.

Сценариев.

Ограничений.

Контрактов.

Критериев приёмки.

Реализация строится под них.

Потом требования меняются.

Реализация строится ещё раз.

Следующий слой тоже довольно очевиден.

Если AI может писать код по требованиям, зачем человеку вручную писать все требования?

Часть контракта можно получить из существующей системы.

Часть — из бизнес-правил.

Часть — из тестов.

Часть — из визуального эталона.

Часть — из наблюдаемого поведения.

Со временем AI начнёт генерировать не только реализацию.

Часть формального описания того, какой эта реализация должна быть.

Тогда главным артефактом разработки действительно может оказаться не код.

Контракт.

Цена токена на бирже.

Контракт на токены.

Код всегда можно переписать.

Сначала надо понять, что он вообще обязан делать.

NGU ждёт возле подъезда.

— Вы нарушили условия контракта.