AI как design-критик: то, что не делает code-generator

AI хорошо известен в роли код-генератора. Скилл смотрит на спецификацию или промпт, выдаёт реализацию. Это полезно, но это не самое ценное, что AI делает в архитектурной работе.

Самая недооценённая роль — AI как design-критик: проверка дизайна до того, как написана хоть одна строка кода. Валидация спеки, разбор Event Storming-черновика, поиск противоречий в Ubiquitous Language, выявление агрегатов, перегруженных инвариантами. Тех вещей, на которых архитектор-человек спотыкается ровно потому, что читает спеку сверху вниз и не держит в голове все 16 разделов одновременно.

Что внутри (на 30 секунд):

Три роли AI: code-generator, code-reviewer, design-critic. Их часто путают, на деле это разные задачи и разные классы ошибок

9 категорий проверок дизайна: Tier consistency, Ubiquitous Language, Bounded Context, Aggregates, Actors/Roles, Commands, Domain Events, Failure Domains, Data Ownership, Acceptance Criteria, NFR

Скилл ucp-spec-review — парный к ucp-spec-design. Делает симметрию полной: для каждого design-скилла теперь есть симметричный review

Существующий сервис: скилл работает на спеке, восстановленной из реального состояния кода — не только на свежем драфте

Триггер появления — комментарий Senior architect под публикацией, что в индустрии этот класс работ AI выполняет лучше человека

Три роли AI в работе с кодом и архитектурой

Их часто сваливают в одну. Тем не менее это три отдельных класса задач, с разными требованиями, разными ошибками, разной точкой включения в процесс.

Code-generator

AI пишет код по описанию. Промпт — спецификация — реализация. Пример скиллов в нашей цепочке: ucp-pattern-design, ucp-api-design, ucp-ddd-tactical-design, ucp-bootstrap-design.

Что AI делает хорошо: воспроизводит идиоматический код по чётко заданным правилам. На Java/Spring со скиллами Use Case Pattern одинаковая задача даёт одинаковый код у разных разработчиков.

Что AI делает плохо без правил: «средний код из training data» — Spring Data JPA где надо jOOQ, контроллер с бизнес-логикой, отсутствие идемпотентности. Об этом — отдельная статья «AI пишет код. Зачем тогда методология?».

Code-reviewer

AI проверяет уже написанный код против правил. Промпт — diff (или весь файл) — список замечаний с цитированием правил. Пример скиллов: ucp-pattern-review, ucp-api-review, ucp-java-style-review, ucp-ddd-tactical-review, ucp-auth-review.

Что AI делает хорошо: проходит по чек-листу из десятков правил быстрее любого человека. Не устаёт. Не пропускает «вот это уже в третий раз». Цитирует код правила (R-7, JS-2.5, BR-C5) — замечание понятно автору.

Что AI делает плохо без контекста: не видит «вписывается ли это в архитектуру в целом», не оценивает компромиссы. Это работа человека, AI закрывает банальное, чтобы человек сосредоточился на нетривиальном.

Подробнее — «Как ревьюить код, который написал AI».

Design-critic

AI проверяет дизайн — спеку, Event Storming-черновик, Context Map — на противоречия, пропуски, несогласованность. До того, как написана строка кода. Это самая недооценённая роль.

Что AI делает уникально хорошо:

Кросс-секционные проверки. Человек читает спеку сверху вниз. Глоссарий в §2, команда в §7, event в §8, AC в §15 — между ними десятки страниц. Несовпадение «команда CancelOrder в §7 vs термин cancellation отсутствует в глоссарии» человек пропустит на 80% спек. AI проверяет все 16 разделов в одном проходе.
Дубликаты и синонимы в Ubiquitous Language. Order vs Purchase vs Sale для одной сущности. Архитектор замечает только когда уже сидит на ревью; AI ловит сразу.
Подсчёт инвариантов в агрегатах. Тут даже архитектор обычно не считает — а агрегат с 12 инвариантами почти всегда реальный split candidate.
Orphans. Событие без потребителя, актор без роли, BR без AC. Класс ошибок «что-то лишнее или что-то недостающее» — AI сильнее.

Чего AI не делает: не принимает архитектурное решение. Не выбирает между Saga и 2PC, между event-sourcing и snapshot. Это всё ещё человек.

9 категорий проверок: что валидирует `ucp-spec-review`

Скилл ucp-spec-review — парный к ucp-spec-design. Симметричная пара design ↔ critic, как у других скиллов методологии. На входе — спека (16 разделов или Tier A/B/C) или Event Storming-черновик, на выходе — список находок с кодами правил и приоритетами.

Категорий правил девять. Каждая отвечает на конкретный класс «что обычно ломается в спеке».

1. Tier consistency (`SR-T-*`)

Заявленный Tier и реальная глубина спеки совпадают. Спека «Order Service (Tier C)» без агрегатов — критический рассинхрон. Спека «Notification (Tier A)» с тремя агрегатами — переусложнение, перевести на Tier B.

2. Ubiquitous Language (`SR-UL-*`)

Каждый термин глоссария используется в других секциях. Один концепт — одно имя (нет Order / Purchase / Sale для одной сущности). Команды и события из §7-§8 используют термины глоссария, не выдуманы заново. Каждый термин имеет определение, не просто упомянут.

Это самая частая категория находок на свежих спеках. На Tier C-сервисе с 30+ терминами в глоссарии у людей не хватает рабочей памяти проверить все упоминания.

3. Bounded Context (`SR-BC-*`)

§1 имеет явный scope И not-scope. Каждая команда в §7 принадлежит этому контексту, не соседнему. Нет невидимого пересечения с соседями (Catalog upstream — а в §3 у нас Product как entity? Ошибка).

4. Aggregates / Domain Model (`SR-AG-*`, Tier C)

Каждый агрегат имеет ≤ 7 инвариантов (split candidate). Агрегат-корень явный, под-сущности внутри. Нет циклических ссылок. Value Objects иммутабельны. Identity-типы — OrderId, не Long.

5. Actors / Roles (`SR-AR-*`)

Каждый актор, упомянутый в §10 или §7 — есть в §5 ролей. Каждая роль имеет матрицу прав по §7 командам и §9 запросам. Каждая команда в §7 декларирует роли-инициаторы.

6. Commands (`SR-CM-*`)

У каждой команды: успешный результат, набор бизнес-ошибок (со ссылкой на §13), пред- и пост-условия. На Tier C — целевой агрегат. CQRS: команды не возвращают «толстые» read-DTO. Money-команды — обязательная идемпотентность.

7. Domain Events (`SR-EV-*`, Tier B+)

У каждого события минимум один потребитель (внутренний или внешний из §14). Имена — глаголы в прошедшем времени (OrderPaid, не PayOrder). retryable события требуют идемпотентного консьюмера. На Tier C — публикация через Outbox, не eventBus.publish() после save().

8. Failure Domains (`SR-FD-*`)

У каждого внешнего соседа — стратегия при отказе (плавная деградация / очередь / запасной путь / отказ). §16 НФТ говорит, где допустим eventual consistency, где обязателен strong. У внешних вызовов — таймаут или Circuit Breaker.

9. Data Ownership / NFR / Acceptance Criteria

Каждая сущность в §3 — ровно один владелец-сервис. PII-поля — явная политика хранения и удаления. Каждое бизнес-правило в §6 покрыто хотя бы одним AC в §15. Каждая команда — happy + error path AC. NFR — измеримые пороги, не «быстро» / «надёжно».

Триггер: реакция рынка

Этот скилл и эта статья появились не из плана, а из комментария под LinkedIn-публикацией про 7 шагов до AI. Senior architect в комментарии написал примерно так:

«AI хорошо работает именно на 0-шаге — валидировать Event Storming-черновик, искать пропущенных акторов, проверять Ubiquitous Language на согласованность. Это не "AI после спеки", а AI как design-критик. Часто полезнее, чем AI как кодогенератор.»

Точное наблюдение от практика. На него отвечать — мало; имеет смысл встроить в продукт. Через сутки появился ucp-spec-review.

Это и есть ценность открытого фидбека: рынок подсвечивает пробелы быстрее, чем команда сама их видит.

Существующий сервис: тот же скилл на восстановленной спеке

Возражение из того же комментария: бóльшая часть AI-кодинга — инкременты в существующих кодовых базах, не на чистом листе. Там 0-шаг другой:

Восстановить реальные границы — не из Confluence, а из ArchUnit-аудита графа зависимостей, Kafka-ивентов, общих таблиц БД. Реконструируем data ownership как есть.
Спека получается частичная — половина уже сделана, и часто плохо. Но даже частичную спеку можно прогнать через ucp-spec-review и получить список «что нужно дописать прямо сейчас, что можно отложить».
Решение по слоям — что трогаем по чистой границе как новый модуль, что пока работает по правилам существующей архитектуры.

ucp-spec-review работает в режиме es (Event Storming-черновик) или на частично заполненной спеке — пропускает категории правил, требующие полностью заполненных секций, и фокусируется на том, что есть.

Это превращает спека-аудит из «давайте перепишем всю документацию заново» (которое никто не делает) в «10 минут на скилл, получаем приоритизированный список — что критично, что подождёт».

Цепочка design ↔ critic ↔ code

Чтобы видно было, как это встаёт в общий процесс:

бизнес-описание / Event Storming-черновик
        ↓
ucp-spec-design   →  спека в docs/spec/  (16 разделов или Tier A/B/C)
        ↓
ucp-spec-review   →  список находок с кодами правил
        ↓
человек правит спеку (или re-run ucp-spec-design с поправками)
        ↓
ucp-spec-review (Fast)   →  0 Critical
        ↓
ucp-pattern-design / ucp-ddd-tactical-design / ucp-api-design
        ↓
код в repo
        ↓
ucp-pattern-review / ucp-api-review / ...   →  замечания на код
        ↓
PR-ревью человеком
        ↓
merge

Раньше переход «спека → код» был необратимым. Спека написана, код пишут по ней, через две недели обнаруживают дыру — переписывают код. Со скилл-парой spec-design ↔ spec-review дыры подсвечиваются до кодогенерации. Это и есть «AI как партнёр архитектора», а не «AI как пишущая машинка».

Где это применимо, где нет

Применимо:

Новый сервис с нуля — после ucp-spec-design запустите ucp-spec-review перед первой кодогенерацией.
Аудит существующего сервиса — у вас есть PDF-стандарт, который не исполняется. Импортируете спеку как markdown, прогоняете через ucp-spec-review — получаете срез её слабых мест.
Event Storming-черновик — после workshop-а, перед формализацией. Режим es подсветит пропущенных акторов и язык-несогласованности.
Регулярный design-аудит — раз в квартал прогон по всем спекам сервисов в монорепо. На больших командах это снимает «Confluence-протух».

Не применимо:

Очень тонкая спека (< 5 из 16 секций заполнено). Скилл вернёт «not enough material» — нечего проверять.
Принятие архитектурного решения — Saga vs 2PC, монолит vs микросервисы. Это работа человека или superpowers:brainstorming, не review-скилла.
Прозвон бизнес-логики на корректность — спека может быть чисто внутренне согласованной, но реализовать неверный бизнес-процесс. Это работа бизнес-аналитика и продакта.

Что дальше

Скиллы UCP — каталог и установка — как добавить ucp-spec-review в свой проект (после клона репо install.sh подхватывает его автоматически)
Use Case Pattern: пошаговый гид — как ucp-spec-review встаёт в цепочку «бизнес-описание → код»
Use Case спецификация: универсальный шаблон — формат, против которого валидирует скилл
Внедрение в команде — на странице услуг описан формат: 2–6 месяцев, методология + AI-скиллы + поддержка автора