Через всю программу проходила одна и та же мысль, названная разными словами: агенту нужен контракт на задачу; нужен исполняемый стандарт — правила, которые он применяет на каждом PR; нужен общий язык, чтобы человек и AI понимали задачу одинаково. До сих пор мы намеренно не называли конкретную методологию — потому что принцип важнее бренда. Эта статья закрывает круг: вот из чего складывается такой принцип, вот способы его держать, и вот тот, на котором построен этот сайт.

Зачем вообще методология, если есть AI

Соблазн понятный: раз исполнитель такой сильный, дай ему задачу словами — разберётся. На маленьком куске так и есть. Но продукт-инженер ведёт весь путь один, и на дистанции неназванные правила расходятся: агент решает один и тот же вопрос по-разному в разных PR, стыки между кусками не сходятся, ревью каждый раз начинается с нуля.

Методология — это способ сделать правила явными и проверяемыми один раз, чтобы агент держал их сам, а ты думал о продукте. Не бюрократия ради бюрократии, а рычаг: чем мощнее исполнитель, тем дороже обходится каждое правило, которое живёт только в твоей голове.

Что делает методологию пригодной для AI

Не всякая методология одинаково ложится на работу с агентом. Работают те, у которых есть четыре свойства:

  • Явный контракт на задачу. Не «сделай хорошо», а проверяемое описание: что на входе, что на выходе, какие правила, как понять, что готово.
  • Исполняемые правила, а не PDF. Стандарт, который агент применяет на каждом PR, — а не гайд, который человек «должен помнить».
  • Единый словарь. Одни и те же имена у понятий в спецификации, в коде и в разговоре — чтобы человек и AI не переводили друг друга.
  • Нарезка на срезы. Единица работы, которую можно поставить, собрать и проверить целиком, а не «слой из всех фич разом».

Эти четыре свойства — не про конкретный бренд. По ним и стоит выбирать методологию.

Способы держать это

Подходов несколько, и они не исключают друг друга:

  • Spec-driven разработка — начинать с исполнимой спецификации, из неё выводить код и тесты.
  • DDD плюс явные стандарты — единый язык предметной области и кодированные правила стиля и архитектуры.
  • ADR — записи архитектурных решений: зафиксировать «почему так», чтобы выбор не переспрашивали.
  • Use Case Pattern — методология, которая связывает всё перечисленное в один каркас: спецификация по юз-кейсам, доменный слой, парные исполняемые правила. На ней построен этот сайт.

Use Case Pattern — тот, что учит этот сайт

Use Case Pattern (UCP) — методология, которую здесь преподают и по которой устроены стандарты и скиллы для агента. Коротко, что она даёт продукт-инженеру:

  • Контракт по юз-кейсам. Каждая команда или запрос описываются карточкой: актёр, вход, инвариант, критерии приёмки. Это и есть тот контракт, который ты ставишь агенту.
  • Исполняемый стандарт. Правила с кодами R-* и парный скилл, который агент применяет на каждом PR. Стандарт живёт не в памяти ревьюера, а в правиле.
  • Одно знание в двух формах. Каждый кусок существует дважды: статья тебе — чтобы понять; правило агенту — чтобы применять.

Обзор методологии — на странице Use Case Pattern. Вся программа продукт-инженера — это применение этой методологии одним человеком с AI: от проблемы до релиза и метрик.

Не единственный путь

UCP — не догма и не единственный правильный ответ. Если у тебя уже работает spec-driven поток или свой свод стандартов, четыре свойства из раздела выше важнее конкретного бренда. Выбирай под контекст: язык, команду, зрелость домена.

Этот сайт учит именно Use Case Pattern по двум причинам: она собирает все четыре свойства в один согласованный каркас, и к ней есть готовые исполняемые правила, которые агент применяет из коробки. Но ценность — в самой дисциплине явных контрактов и проверяемых правил, а не в названии.

Дальше