Кейс: код стартапа не превращается в legacy
Стартап 4-8 разработчиков, MVP с быстрой эволюцией требований. Внедрили UCP с правильным Tier по модулям и AI-скиллы для review с первого дня. Через 1.5 года код адаптируется без переписывания.
Контекст
Ранний этап стартапа, 4–8 разработчиков. MVP уже релизнут, бизнес активно ищет Product-Market Fit — требования меняются от спринта к спринту. Код в основном на Java/Spring, базовый CRUD с бизнес-логикой в сервисах.
Проблема — типичная
История знакома любому, кто работал в стартапе:
- Первые полгода — «надо быстрее, потом разрулим»
- К году накопился такой технический долг, что любое изменение требует переписывания половины смежного кода
- Команда боится трогать ключевые модули — слишком много «магии»
- Junior-ы росли в этом коде и научились писать так же → проблема воспроизводится
- Когда планируют pivot, оценивают как «полугодовое переписывание» — не верят, что текущая база переживёт
В стартапе это смертельно: скорость замедляется, но при этом никаких инвестиций в архитектуру — не было ресурса.
Что внедрили
1. Use Case Pattern с правильным Tier по модулям
Не «всё на Hexagonal для красоты», а:
- Ядро бизнеса (заказы, платежи, ключевая логика) — Tier B/C: UseCase Pattern + домен
- Справочники, CRUD-админки, отчёты — Tier A: тонкая слоистая архитектура без боли
- Внешние интеграции — порты + адаптеры, чтобы менять провайдеров не переписывая ядро
Это сильно дешевле, чем «всё на Tier C для единообразия» — и сильно надёжнее, чем «всё на Tier A потому что MVP».
2. AI-скиллы для review с первого дня
ucp-pattern-review, ucp-api-review, ucp-java-style-review подключены в CI и в локальной IDE через Claude Code. Каждая PR проходит через скиллы автоматически, замечания цитируют правила.
Critical: скиллы стартуют рано, ещё пока кодовая база небольшая. Подключить позже — больно: тысячи замечаний на десятки тысяч строк кода.
3. Спецификация-как-код для ключевых модулей
Не для всего сразу, а для тех модулей, где изменения дороги или требуется онбординг новых разработчиков. Спека лежит в репо, изменения в одном PR с кодом.
Результат
- Через 1.5 года кодовая база остаётся читаемой. Junior-разработчик въезжает за неделю по спеке + примеру.
- Бизнес-pivot не требует переписывания фундамента — меняются UseCase-ы внутри устоявшихся слоёв, инфраструктура и порты остаются.
- Tech-debt не накапливается экспоненциально — раз в квартал делается «архитектурная уборка», не «полугодовая стройка».
- Найм проще — на собеседовании можно показать чистый код и спецификации, это притягивает senior-ов, которые иначе не пошли бы в стартап.
Что было сложно
Главная сложность — дисциплина на старте, когда «всё горит». Команда искушалась срезать углы. Помог принцип «один пример на нашем коде» — на одном модуле прошли весь цикл от спеки до AI-review, разработчики увидели результат своими глазами, дальше уже сами хотели расширять.