Ниже — мои рассуждения про будущее web‑разработки, но не в абстрактном смысле типа «что будет с React или с PHP», а в очень прикладном контексте: проектная разработка клиентских сайтов для веб‑студий и digital‑агентств.
Под «клиентскими сайтами» я имею в виду то, что составляет основу студийного портфеля: корпоративные сайты, витрины, каталоги, промо‑лендинги, спецпроекты и e‑commerce среднего уровня. Это проекты, которые живут в логике сроков и бюджета, развиваются итерациями и почти всегда упираются в контент/SEO, интеграции и поддержку «волнами».
Главный тезис, который я вижу всё отчётливее: ИИ делает дешёвым «сделать», но дорогим «поддерживать и не ломать». И именно поэтому ценность архитектурной ясности, доменных инвариантов и проверяемых контрактов будет расти, а не исчезать.
Вступление: почему «будущее web» — это про экономику изменений
Когда говорят «будущее web‑разработки», часто обсуждают тренды: SSR/edge, новые фреймворки, очередной виток low‑code/no‑code, новые CMS. Но реальный перелом последних лет — не про технологию как таковую, а про экономику производства артефактов.
ИИ радикально снизил стоимость генерации:
кода (включая рутину),
тестов (как минимум каркасов и сценариев),
текстов и контента,
интеграционной «обвязки»,
документации и примеров.
Скорость производства стала доступна гораздо большему числу команд. Скорость перестала быть редким преимуществом. Она стала базовой возможностью.
А вот что стало дефицитом — это:
согласованность,
предсказуемость,
проверяемость,
способность менять правила, не ломая систему.
В проектной разработке клиентских сайтов это ощущается особенно остро. Студии живут в режиме постоянных итераций: быстро старта��ули, быстро запустили рекламу, быстро сделали новый лендинг, быстро поменяли оффер, быстро прикрутили интеграцию. ИИ делает этот поток ещё более интенсивным. Но вместе с ускорением возрастает вероятность, что проект превращается в «набор быстро сделанных вещей», которые плохо стыкуются друг с другом.
Если упростить: будущее web‑разработки — это про то, как удерживать систему в целостности при высокой скорости изменений.
1. Что реально меняется из-за ИИ: производство артефактов становится массовым
Я бы выделил три практических эффекта, которые уже видно и которые будут усиливаться.
1) Код, тесты, тексты, шаблоны и интеграции генерируются быстрее
Это плюс: быстрее прототипировать, быстрее закрывать типовые задачи, быстрее выпускать итерации.
2) Риск расхождений и фрагментации растёт
Когда что‑то становится дешёвым, оно начинает производиться массово. Массовое производство без стандартов почти всегда порождает:
разные «варианты истины» в разных местах (тут одно правило, там другое),
дубли логики («быстрее скопировать, чем разобраться»),
несовместимые куски интеграций,
«скриптовый зоопарк» вокруг CMS или вокруг фреймворка.
ИИ усиливает эту тенденцию. Он ускоряет не только «хорошие практики», но и «плохие привычки». Если у команды нет рельс, по которым она ездит, ИИ не сделает дисциплину за неё.
3) Новый дефицит: единая модель, контракты, проверяемость
Самое ценное становится не «сгенерировать очередной компонент», а:
иметь единый язык (термины),
иметь место, где живут правила (инварианты),
иметь контракты на взаимодействия,
иметь проверки (тесты/CI), которые удерживают систему от расползания.
В студийной модели это ключ: клиенты будут просить чаще, быстрее и больше. И либо студия превращается в фабрику предсказуемых изменений, либо её скорость станет источником постоянной регрессии.
2. «Чистый код» как актив: доменные инварианты вместо вкусовщины
Про «чистый код» часто спорят как про эстетику. Я предлагаю смотреть прагматично: чистота кода — это снижение стоимости изменений.
В проектной разработке клиентских сайтов домен есть почти всегда, просто он не всегда осознан. Домен проявляется как набор правил:
как формируется оффер (в зависимости от сегмента),
как применяются акции и исключения,
как считается цена/стоимость/пакет,
какие статусы есть у заявки и что они значат,
какие поля обязательны и почему,
как синхронизируется каталог,
какие данные считаются «истиной» (CRM? CMS? учётка?).
Эти правила и есть инварианты: то, что должно оставаться истинным при любом количестве «быстрых правок».
Где нужен домен (и где точно не нужен)
Домен нужен, когда:
правила сложные и часто меняются,
интеграций много и они критичны,
ошибка стоит дорого,
поведение должно быть воспроизводимым,
команда сменяемая, проект долгоживущий.
Домен не нужен, когда сайт в основном контентный, а правила редкие и очевидные.
✅ Чек-лист: «Где нужен домен на клиентском сайте»
Используйте доменный слой (хотя бы минимальный), если есть 3+ пункта:
Правила меняются чаще, чем раз в квартал.
Есть несколько источников данных (CRM/ERP/каталоги/фиды/прайсы).
Ошибки дороги: деньги, репутация, юридические последствия.
Есть состояния и жизненный цикл (заявка/бронь/договор/статус).
Логика распределена между админкой, фронтом, интеграциями и её сложно объяснить.
Одно правило нужно в нескольких местах (сайт, ЛК, CRM, рассылки).
Есть персонализация/сегментация.
Нужны эксперименты (A/B) без риска «сломать базу».
Есть «исключения» и «кроме».
Команда меняется, проект живёт годами → нужен «якорь» знаний.
Как сделать «богатый слой» минимальным и окупаемым
Частая ошибка — пытаться «внедрить DDD» как большой рефакторинг. В студийной модели это редко окупается. Рабочая стратегия: маленький, но жёсткий доменный контур.
Что именно в доменном слое должно быть «чистым», чтобы стать активом для ИИ
Если говорить прикладно, ИИ «любит», когда доменный слой устроен так, что правда системы выражена явно, а не размазана по контроллерам, шаблонам, ORM и интеграционным скриптам. Тогда домен становится не просто кодом, а опорой, вокруг которой можно безопасно строить генерацию тестов, спеки, документации и экспериментов.
Вот набор свойств, которые превращают доменный слой в актив (и для команды, и для ИИ):
Явные типы и ограничения
Value Objects вместо «string/int везде». Деньги, даты, статусы, идентификаторы, сегменты, периоды акций — всё, что критично для правил, должно иметь тип и валидацию.
Смысл не в «красоте», а в том, что ИИ и человек одинаково хуже ошибаются, когда ошибка невозможна структурно.Инварианты в одном месте
Правила не должны жить одновременно в UI, в хендлерах, в ORM‑хуках и в «настройках модуля».
Инвариант должен быть закреплён в агрегате или доменном сервисе так, чтобы его можно было прочитать и проверить в тесте.Доменный язык вместо технического
Имена методов, команд и событий должны совпадать с бизнес‑терминами:ApplyPromotion,CalculateOffer,LeadQualified,BookingExpired.
Когда в домене появляютсяprocessData()иhandleRequest(), это почти всегда симптом: правила скрыты, а смысл потерян.Детерминированность и тестируемость
Там, где можно, доменная логика должна быть чистой и предсказуемой: одна и та же команда при одних и тех же входах даёт один и тот же результат.
Время, рандом, I/O, внешние API — выносятся наружу. Это упрощает тестирование и делает генерацию тестов/спеки гораздо надёжнее.Событийность там, где нужен след изменений
Доменные события — это «аудит смысла», а не просто лог.
Если вы фиксируетеOfferCalculated,PromotionApplied,LeadCreated, вы получаете объяснимость поведения: другим командам (и ИИ) проще строить документацию, тесты, сценарии и аналитические проверки, не читая весь код.
Если коротко: такой домен становится вашей «обучающей выборкой» — и для новых разработчиков, и для ваших AI‑инструментов. На грязном домене ИИ тоже может ускорять разработку, но он ускоряет и расхождения.
3. Spec/doc-driven в 2026+: спека как то, что «ест» ИИ
Раньше спеки часто были «документами для согласования». Сейчас они становятся производственным артефактом, потому что ИИ лучше всего работает, когда у него есть структурированный контекст.
Спека как интерфейс между бизнесом, командой и ИИ
Для студийного проекта часто достаточно, чтобы спека фиксировала:
термины,
сценарии,
входы/выходы,
ограничения (инварианты),
ошибки и крайние случаи,
примеры данных,
критерии приёмки.
Как спека превращается в тесты, моки, SDK, документацию
Если спека формализована (OpenAPI/JSON Schema/AsyncAPI или хотя бы строгая структура use‑cases), дальше появляется конвейер:
мок‑серверы,
SDK,
контрактные тесты,
документация.
Почему «бумажные спеки» умирают
В мире высокой скорости изменений «бумажная спека» неизбежно отстаёт. Остаётся устойчивый вариант: исполняемые артефакты, которые проверяются в CI.
4. Обратный вектор: code-first документация поверх доменной модели
Как извлекать из кода: термины, сценарии, ошибки, контракты
Если доменный контур сделан хотя бы минимально дисциплинированно (явные типы, явные ошибки, явные use‑cases), из него можно извлекать:
словарь терминов,
каталог use‑cases,
контракты API,
список доменных ошибок,
примеры входов/выходов.
Docs-as-code и CI: чтобы документация не врала
Документация должна быть частью репозитория и частью CI:
изменили правило → обновили док,
изменили контракт → CI проверил совместимость.
Контур: Model → Spec → Generation → Tests → Model
Смысл в замыкании цикла: спека не «висит рядом», она проверяется и возвращает обратную связь в модель. Это делает систему устойчивой при высокой скорости изменений.
Практика: как «навесить» spec/doc/test-генерацию на доменный код
Самая устойчивая схема в 2026+ выглядит так: мы не пишем спеки «отдельно», мы строим их вокруг доменной модели и use‑cases, и заставляем CI проверять, что спека и код не разошлись.
Минимально жизнеспособный стек дисциплин (без фанатизма), который реально окупается в проектной разработке клиентских сайтов:
Contract tests для API и интеграций
Вариантов два, и оба рабочие:
— schema‑level (OpenAPI/JSON Schema) + валидация входов/выходов в тестах;
— consumer/provider (где это оправдано), чтобы изменения не ломали клиентов/потребителей.
Смысл один: спека перестаёт быть «бумажной».Property‑based tests для инвариантов (точечно)
Не обязательно везде, но на узких местах (скидки, сегменты, расчёты, статусы) это мощный инструмент. Он ловит крайние случаи, о которых никто не вспомнил в постановке.
ИИ хорошо помогает генерировать заготовки таких тестов, если домен детерминирован и типизирован.Executable specifications (BDD/gherkin‑подобное) — только если реально исполняется в CI
Если BDD превращается в «красивый текст в Confluence», это мёртвая практика.
Если же сценарий реально исполняется (хотя бы частично) — он становится мостом между бизнесом и проверками.Автогенерация документации вокруг домена
Минимальный набор, который стоит генерировать/поддерживать как артефакты:
— Domain glossary: термины, состояния, события, ограничения;
— Use‑cases catalog: команды/запросы, входы/выходы, ошибки, side‑effects;
— Examples: пример входа → пример результата (как «живые примеры» для команды и ИИ).Жёсткое правило: генерация привязана к CI
Документация и спеки должны:
— генерироваться/проверяться в CI,
— падать сборкой при рассинхроне,
— храниться рядом с кодом (docs‑as‑code).
Иначе всё разойдётся с реальностью и станет токсичным.
В результате получается не «документация ради документации», а контур качества: домен → спека → тесты → CI → домен. И это именно тот контур, который делает ИИ полезным усилителем, а не генератором энтропии.
Далеко не всегда проект стартует с идеально оформленной спеки. Часто проект уже существует, и надо «поднять знание» из кода. Здесь работает подход code‑first документации: строим спецификацию и доки поверх существующей модели.
5. CMS-мир: что будет с клиентскими сайтами на CMS (Bitrix/WordPress/Drupal и т.п.)
Прогноз «CMS умрут» в студийной реальности обычно не подтверждается. CMS остаются и даже усиливаются, просто меняется их роль и цена ошибок.
Почему CMS не исчезнут
CMS — это организационная машина для контента. Роли, права, редакторы, медиабиблиотеки, публикации.
Большая часть клиентских сайтов — контент + витрина + интеграции «по краю». CMS заточены под «контент → SEO → лиды → итерации».
Экосистема — рычаг скорости. Плагины — риск, но и причина time‑to‑market.
Как ИИ усиливает CMS-разработку
ИИ усиливает скорость производства и вариативность:
генерация шаблонов/компонентов становится повседневностью,
контент и посадочные клепаются быстрее,
интеграционная «обвязка» дешевеет,
появляется шанс держать актуальную карту проекта и документацию.
Главная угроза CMS-мира: плагинность + неявные правила + сложные интеграции
CMS хорошо масштабируют контент, но плохо масштабируют доменные правила, когда те расползаются между:
настройками модулей,
шаблонами,
обработчиками событий,
интеграционными скриптами.
ИИ ускоряет рост этого «зоопарка», если нет границ.
Эволюция: монолитная CMS → headless/composable → «домен рядом»
Headless — инструмент по показаниям, а не мода. Когда headless оправдан:
контент нужен, но правила сложные и часто меняются,
несколько каналов потребления (сайт/ЛК/приложение),
интеграции критичны,
надо разделить ответственность между командами.
Практический компромисс: «домен рядом».
CMS остаётся контент‑ядром, а правила и инт��грации живут в отдельном слое.
5.5. Легаси на CMS: три уровня боли и разные способы лечения
В студийной реальности большинство проектов — легаси в той или иной степени. Поэтому вопрос «CMS vs фреймворк» часто звучит так: что делать с тем, что уже есть, чтобы оно не дорожало экспоненциально?
Я делю легаси CMS на три уровня.
Уровень 1: контентный легаси.
Контент и шаблоны устарели, структура тяжёлая, SEO сделано «как получится», но правил почти нет, интеграции простые.
Что делать:
модернизировать тему/шаблоны без вторжения в бизнес‑логику,
зафиксировать критичные страницы smoke‑регрессией,
навести порядок в структуре контента, урлах, мета‑тегах.
Уровень 2: легаси с расползшимися правилами.
Акции, сегменты, условия живут в настройках, шаблонах, обработчиках и JS одновременно.
Что делать:
перестать добавлять новые правила «в настройки» и «в шаблон»,
выделить единый контур правил (хотя бы модуль/библиотека),
переносить правила по одному: правило → тест → пример.
Уровень 3: легаси‑интеграционный монолит.
CMS стала центром синхронизаций: CRM, каталоги, фиды, платежи, аналитика. Обновления страшны, отладка тяжёлая, часть интеграций «падает молча».
Что делать:
применить Strangler Fig для интеграций: вынести их в отдельный интеграционный слой,
сделать контракты и наблюдаемость обязательными,
оставить CMS контентом и витриной, а не «мозгом».
5.6. Как преобразовывать легаси CMS под новый подход без переписывания
Самый рабочий путь — начать строить новый контур рядом и постепенно откусывать то, что действительно создаёт долг.
Инвентаризация правил (инвариантов). Список «что считается» и «почему так» (10–30 пунктов).
Карта источников истины. Где истина по цене/наличию/статусу/сегменту.
Контрактная обвязка интеграций. Схема + валидация + логирование + поведение при ошибках.
«Домен рядом» сначала в лёгкой форме. Модуль/библиотека внутри репозитория; сервис — по показаниям.
Переезд правил по одному. Каждое правило: тест + пример + мониторинг.
Орг‑правило: новые важные правила не внедрять в настройки CMS. Важное правило → в доменном контуре.
Приземление: DDD в Bitrix-модулях и интеграциях (и почему это удобный фундамент для AI-генерации)
Если приземлить всё это на контекст, где часть проектов делается на CMS‑уровне (в частности Bitrix), а часть — вокруг интеграций, то разделение Domain / Application / Infrastructure / Interface оказывается не «красивой архитектурой», а способом удерживать проект в состоянии, когда его можно менять без паники.
Что обычно даёт максимальный эффект:
Инварианты перестают «протекать» в компоненты и контроллеры
Компонент/контроллер на Bitrix (или любой другой CMS) становится UI‑слоем: он отображает и собирает ввод, но не решает бизнес‑вопросы.
Правила остаются в Domain — и начинают быть проверяемыми.Use‑cases становятся единственной точкой оркестрации
В Application‑слое живут сценарии: «создать заявку», «рассчитать оффер», «применить акцию», «синхронизировать каталог».
Это убирает хаос, когда один и тот же сценарий реализован «чуть‑чуть по‑разному» в пяти местах.Интеграции уходят в Infrastructure
Внешние API, очереди, Bitrix‑сущности (инфоблоки/HL‑блоки/ORM), файловые хранилища — всё это инфраструктура.
Домен не должен знать, как вы читаете данные из Bitrix, он должен знать, что это за данные и какие у них ограничения.Доменные события помогают объяснять поведение без чтения всей кодовой базы
События уровняLeadCreated,OfferCalculated,PromotionApplied,CatalogSyncedпревращают поведение системы в понятный журнал смысла.
Это полезно командам, QA, аналитикам — и полезно ИИ, когда вы строите генерацию тестов, доков и сценариев.Doc/spec/generation строится вокруг use‑case каталога и доменных типов
Когда use‑cases и доменные типы выражены явно, вы можете генерировать:
— словарь (термины/состояния/события),
— каталог сценариев (входы/выходы/ошибки),
— контракты интеграций,
— примеры и тест‑скелеты.
И это начинает работать как фабрика: изменения в правилах автоматически отражаются в проверках и документации через CI.
Смысл в том, что «чистый» доменный контур позволяет Bitrix‑проектам взрослеть: от «CMS‑монолита» к гибридной модели, где CMS остаётся сильной в контенте, а правила и интеграции становятся управляемыми активами.
6. Фреймворки: что будет с клиентскими сайтами на Laravel/Symfony/Node/Next/Nuxt
Фреймворки чаще выбирают там, где CMS уже не держит нагрузку сложности: по правилам, интеграциям, безопасности, производительности или управляемости изменений.
ИИ одновременно:
снижает цену входа (быстрее собрать «скелет»)
и повышает цену отсутствия дисциплины (энтропия наступает быстрее).
Где фреймворки выигрывают
Там, где у вас есть «правила», а не только «страницы». Инварианты легче держать в одном месте.
Там, где интеграции нужно сделать продуктом. Контракты, ретраи, идемпотентность, логирование, очереди.
Там, где эксплуатация и наблюдаемость — часть результата. «Почему лиды упали» — не вопрос «потом», это вопрос «сейчас».
ИИ и delivery: быстрее скелеты, выше риск энтропии
ИИ делает дешёвым «нагенерить» много всего. Но сопровождать придётся вам. Поэтому без guardrails скорость превращается в хаос.
✅ Чек‑лист guardrails для ИИ‑ускоренной разработки
Стандарты и границы:
1) структура слоёв и запрет «переливов» зависимостей;
2) правила нейминга и терминов (glossary);
2) единый стиль ошибок (доменные ≠ инфраструктурные ≠ UI).
Контракты и проверки:
4) контрактные тесты для API/интеграций;
5) golden/snapshot‑тесты для критических шаблонов;
6) тесты инвариантов (unit/property‑based там, где имеет смысл).
CI‑ворота:
7) статанализ + форматирование;
8) архитектурные правила зависимостей;
9) генерация/валидация спеки в CI;
10) генерация документации и запрет мержа, если доки отстали.
Операционная устойчивость:
11) observability baseline;
12) security baseline (зависимости, секреты, права, аудит).
6.5. Легаси на фреймворке: типовые симптомы, которые ИИ сделает хуже
У фреймворкового легаси другая природа: не «зоопарк плагинов», а зоопарк способов выразить одно и то же правило.
Симптомы:
правила размазаны по контроллерам, шаблонам, джобам и интеграциям,
разные форматы ошибок и результатов,
интеграции без контрактов («надеемся, что входные данные такие же»),
тестов мало, регрессия ручная,
копипаст — основной способ ускорения.
ИИ в этом контексте усиливает хаос: если нет стандартов, он будет генерировать «правдоподобный код», который закрепляет фрагментацию.
6.6. Как преобразовывать фреймворковое легаси без «большого рефакторинга»
Принцип: сначала вводим правила игры для нового кода, затем вытесняем старое «по краю».
Ввести архитектурные границы как правило разработки. Новая логика → use‑cases; правила → домен; интеграции → адаптеры; UI без бизнес‑решений.
Boy Scout Rule. Любое изменение слегка улучшает ближайшую грязь: вынесли правило, унифицировали ошибку, добавили тест, повесили лог.
Стандартизировать ошибки и результаты. Это дешёвый способ снизить энтропию.
Тесты инвариантов на самые дорогие правила. 10–20 тестов на деньги/лиды/частые изменения дают больше эффекта, чем «покрыть всё».
Наблюдаемость как страховка миграции. Логи и метрики до/после изменений.
Strangler Fig для больших зон. Строим новый контур рядом и переводим потоки по одному.
7. CMS vs Framework vs Hybrid: сравнение без религии
Суть выбора — не «что лучше», а какую цену вы будете платить за изменения через 6–18 месяцев.
CMS: скорость старта и контентная операционка.
Framework: контроль правил и интеграций при дисциплине.
Hybrid: контентная скорость + управляемый домен.
Таблица критериев (12 пунктов)
Критерий | CMS (Bitrix/WordPress/Drupal) | Framework (Laravel/Symfony/Nest + Next/Nuxt) | Hybrid (CMS + доменный/интеграционный слой рядом) |
|---|---|---|---|
Time‑to‑market | Максимально быстрый старт для типовых сайтов | Быстро при наличии стартеров; «с нуля» дольше | Средний: контент быстро, домен — по мере необходимости |
Стоимость старта | Обычно ниже (если не лезть в сложный домен) | Выше (архитектура, инфраструктура, тесты) | Средняя |
TCO 2–3 года | Может резко вырасти из‑за плагинов/хаоса | Предсказуемее при дисциплине | Часто лучший баланс |
Гибкость правил | Ограничена рамками CMS | Максимальная | Высокая |
Скорость изменения правил | Сначала быстро, потом падает | Стабильно высокая | Высокая |
Интеграции | Быстро «подключить», сложнее стабилизировать | Контроль и тестируемость | Часто лучший паттерн |
Тестируемость | Сильно зависит от культуры | Проще выстроить пирамиду | Контракты вокруг домена |
Безопасность/обновления | Риски экосистемы | Управляемо, но на вашей ответственности | Риски разделены |
SEO/контент | Сильная сторона | Нужно строить пайплайн | CMS закрывает контент |
Производительность | Можно, но упирается в платформу | Максимальный контроль | Оптимизация витрины + домен |
Масштаб команды | Быстро подключать, сложно держать стандарт | Требует стандартов | Разделение ответственности |
Поддержка волнами | Высокий bus‑factor без доков | Лучше при контрактах/CI | Часто оптимально |
Матч-кейсы выбора
Когда CMS
контент и SEO — основной двигатель,
правила простые и редкие,
клиент реально живёт в редакторе.
Когда Framework
сайт — система правил и интеграций,
ошибки дороги,
нужна наблюдаемость/безопасность/перформанс как часть результата.
Когда Hybrid
и контент важен, и правила становятся сложными,
нужен путь эволюции без «переписать всё».
ИИ не делает выбор проще. Он делает последствия выбора более резкими: скорость создания «кусочков» растёт, значит без ясной модели и контрактов проект быстрее становится либо управляемым активом, либо скриптовым зоопарком.
Выбор между CMS, фреймворком и гибридом сам по себе не решает проблему. Он лишь задаёт форму будущего долга: где именно будет копиться несогласованность — в плагинах и настройках, в разрозненных кусках кода или на стыке нескольких систем.
Дальше начинается инженерная часть, которая одинакова для любого выбора: нужно выстроить «рельсы», на которых можно быстро выпускать изменения и при этом удерживать целостность. Именно это и превращает скорость ИИ в преимущество, а не в ускоритель хаоса. Поэтому следующий шаг — не обсуждать технологии, а зафиксировать практический план, как студии за 12 месяцев поставить модель, контракты и проверки на поток.
8. Практический план на 12 месяцев для веб-студий и digital-агентств
Управленческая рамка на 5–10 лет
ИИ ускоряет производство кода, поэтому главным дефицитом становится не «написать», а удержать целостность. Целостность удерживают инварианты, контракты и проверяемая модель. Следовательно, инвестиция в доменный слой и автоматические проверки — это инвестиция в пропускную способность команды и безопасность изменений.
Практически это означает: если у студии есть модель, контракты и CI‑ворота, ИИ делает её быстрее и сильнее. Если этого нет — ИИ делает её быстрее… но менее управляемой.
Если свести задачу к одному показателю, я бы выбрал такой: снизить стоимость изменения правил (запрос → прод без паники и регрессии). Ниже — маршрут, который можно внедрять параллельно с боевой разработкой.
8.1. Два параллельных контура: New-Build и Legacy-Improve
В зрелой студии всегда два потока, и их важно не смешивать:
New‑Build (новые проекты): стандарты с первого дня, быстрый старт, предсказуемая структура.
Legacy‑Improve (существующие проекты): снижение стоимости изменения правил и регрессии без переписывания.
У них разные KPI. Для легаси KPI — не «сколько задач закрыли», а «насколько дешевле стало менять правила и насколько меньше стало аварий».
8.2. План на 12 месяцев: что именно внедрять и в каком порядке
🔵 Квартал 1 (0–3 месяца): поставить рельсы и зафиксировать базовую предсказуемость
Старт‑пакет проекта (starter kit).
Структура репозитория, базовые слои, соглашения, шаблон документации, минимальный набор инструментов качества.CI‑ворота как обязательный стандарт.
Линтер/типизация + базовые тесты инвариантов + проверка контрактов интеграций как «красная кнопка» качества.Мини‑глоссарий и use‑cases.
Небольшой, но обязательный: ключевые термины, 10–20 сценариев, набор ошибок/исключений. Это снижает энтропию ещё до того, как вы «внедряете DDD».
🔵 Квартал 2 (3–6 месяцев): спецификации и контракты как производственные артефакты
Контракты интеграций как правило: без контракта — не интеграция.
Выравнивание входов/выходов, ошибок и поведения при сбоях. Это обычно даёт самый быстрый эффект на легаси и на проектах «с интеграциями по краю».Docs‑as‑code с проверкой в CI.
Документация перестаёт «врать» — потому что её актуальность проверяется, а не надеется на дисциплину.Шаблон постановок задач «под ИИ».
Контекст, сценарии, инварианты, примеры, критерии приёмки. Это простое управленческое действие, которое резко повышает качество генерации и снижает «скриптовый зоопарк».
🔵 Квартал 3 (6–9 месяцев): доменный контур и контроль регрессии
Минимальный домен там, где живут правила.
Не «DDD везде», а 3–7 сущностей/типов/инвариантов, которые реально влияют на деньги/лиды/конверсию.Регрессия по критичным правилам.
Инварианты + контрактные тесты + немного e2e там, где иначе нельзя поймать поломку (например, лидогенерация, расчёт оффера, ключевые воронки).Observability baseline.
Логирование ключевых событий, корреляция запросов, алерты по сбоям интеграций. Без наблюдаемости легаси‑модернизация превращается в «мы надеемся, что стало лучше».
🔵 Квартал 4 (9–12 месяцев): масштабирование в «фабрику» без потери управляемости
Внутренние шаблоны и генераторы студии.
Собственный «framework практик»: стандартизированные заготовки, типовые интеграционные адаптеры, общие проверки, единый стиль ошибок.ADR как привычка.
Коротко фиксируем решения и последствия. Это снижает bus‑factor и упрощает масштабирование команды.Метрики как управленческий контур.
Lead time изменения правила, дефекты на релиз, стоимость регрессии, MTTR, доля покрытых контрактов — чтобы стало видно, что улучшения реально работают.
На этом месте обычно возникает практический вопрос студии: как внедрять эти изменения, если основная загрузка и деньги сидят в текущих проектах, а клиенты не готовы оплачивать «архитектуру» как абстракцию.
Ответ в том, что легаси‑модернизация должна стать не внутренним хобби команды, а понятным коммерческим продуктом. Тогда у студии появляется бюджет на стабилизацию, у клиента — ясный результат и измеримые эффекты, а у команды — возможность улучшать систему без остановки разработки.
Именно поэтому дальше логично выделить отдельный легаси‑плейбук: что можно сделать за ограниченное время, с предсказуемым объёмом работ, чтобы резко снизить риск регрессии и стоимость изменения правил.
8.3. Легаси-плейбук: пакет, который можно продавать клиенту
Легаси лучше превращать в продаваемую услугу, а не в «мы будем потихоньку улучшать».
Legacy Stabilization / Legacy Modernization Sprint
Аудит правил и источников истины (1–2 недели): список инвариантов, карта данных, карта интеграций.
Контракты и наблюдаемость интеграций (1–2 недели): схемы, валидация, логирование, алерты.
Минимальный доменный контур для 3–5 ключевых правил (2–4 недели): оффер/акции/сегменты/статусы.
Тесты инвариантов + минимальный e2e (1–2 недели): защита от «сломали и не заметили».
Docs‑as‑code: карта проекта и инструкция «как менять правила безопасно» (1 неделя).
Дорожная карта на 3–6 месяцев: что выносим дальше и почему.
Как не убить бизнес легаси‑рефакторингом
Не переписывать, а перехватывать потоки (strangler): переносим по одному, старое продолжает работать.
Каждое вынесенное правило = тест + мониторинг.
Сначала наблюдаемость, потом оптимизация.
Запрет на новые быстрые костыли без контракта/стандарта.
Definition of Done для легаси‑изменений: «перенесли → проверили → наблюдаем».
Метрики именно для легаси
lead time изменения правила,Метрики именно для легаси
стоимость регрессии (часы на фиксы после релиза),
дефекты интеграций и MTTR,
доля интеграций с контрактами (тренд),
доля критичных правил с тестами (тренд),
частота «горячих фиксов».
Минимальный пакет, который окупается почти всегда:
старт‑пакет + контракты интеграций + тесты инвариантов + docs‑as‑code + базовая наблюдаемость.
Этот план не про «идеальную архитектуру» и не про попытку перестроить все проекты под один шаблон. Он про другое: перевести студию в режим предсказуемых изменений, где новые проекты стартуют на рельсах, а легаси постепенно теряет способность генерировать аварии и регрессию.
Если это получается, дальше технологии становятся вторичны: CMS, фреймворк или гибрид — всё работает, пока есть ясная модель, контракты и проверяемость. В горизонте 5–10 лет именно эта связка и будет определять конкурентное преимущество: кто умеет менять правила быстро и безопасно, тот будет выигрывать в мире, где «сделать» становится всё дешевле.
9. Финал: мир 5–10 лет — доменная ясность как конкурентное преимущество
Если собрать всё в одну формулу: ИИ не отменяет инженерную ответственность. Он делает её дороже. Не потому что «станет сложнее код», а потому что скорость производства возрастает, а значит растёт и скорость накопления несогласованности.
В проектной разработке клиентских сайтов это выглядит так: клиенты будут хотеть чаще, быстрее и больше. И выигрывать будет не тот, кто «быстрее пишет код», а тот, кто быстрее и безопаснее меняет правила — без деградации качества и без постоянной регрессии.
Что станет главным активом студии/агентства в горизонте 5–10 лет:
Ясная модель (пусть минимальная), где правила выражены явно.
Инварианты живут в доменном контуре, а не в настройках, шаблонах и «кусочках логики».Контракты и исполняемые спецификации.
Спека — это не документ «для согласования», а часть производственного контура: тесты, моки, SDK, документация, CI‑проверки.Наблюдаемость и проверяемость поведения.
Чтобы изменения можно было проводить уверенно: видеть последствия, ловить сбои интеграций, отслеживать деградацию конверсии/сценариев.
Что изменится: инструменты вокруг будут всё сильнее автоматизировать генерацию кода/тестов/доков, извлечение спеки из модели и «производственные пайплайны» качества.
Что не изменится: необходимость выбирать границы, проектировать инварианты и отвечать за поведение системы. Это и останется ремеслом — и именно здесь студии смогут удерживать конкурентное преимущество, даже когда «писать код» станет ещё дешевле.
