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

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

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

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

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

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

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

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

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

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

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

Один пример на двух путях

Абстрактные свойства проще всего понять через сравнение — как одна и та же задача идёт с явным каркасом и без него.

Задача: эндпоинт POST /orders — создать заказ по id пользователя и списку товаров.

Без явной методологии. Агент получает: «Добавь ручку создания заказа». Пишет контроллер, сервис, репозиторий — структурно верно, но в первом PR забывает проверить, существует ли пользователь. NullPointerException ловится в проде. Во втором PR проверка есть, но написана иначе, чем в соседней части кода — стыки не совпадают. Ревью начинается с объяснений: «у нас вот так принято» — каждый раз заново, потому что правило живёт только в голове ревьюера. Ошибки всплывают поздно и стоят дороже.

С явной методологией (UCP как пример). Сначала карточка юз-кейса: актёр, вход (userId, items), инварианты (пользователь существует, список не пуст), критерии приёмки — одна страница текста. Агент получает её как контракт и применяет к ней исполняемый стандарт — правила с кодами R-* на каждом PR. Ошибка «userId не проверен» ловится на этапе инвариантов, ещё в спецификации, а не в проде. Повторное ревью не нужно — агент уже знает, как здесь принято.

Цена честная: 15–20 минут на карточку и первоначальная настройка стандарта. Выгода: ревью сокращается, ошибки смещаются влево, стыки сходятся. При первом проекте методология ощущается как накладные расходы; при втором — как то, что сэкономило неделю.

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

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

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

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

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

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

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

Что это значит на практике

Методология легко превращается в ритуал: карточки пишутся, правила кодируются, но ни агент, ни человек к ним не обращаются. Признак рабочей методологии — не объём документации, а то, что агент реже переспрашивает и реже ошибается в одном и том же месте.

Пять ошибок, которые превращают методологию в ритуал:

  • Берёшь без адаптации. Стандарт для Java-backend переносишь в Python-проект без правок — правила не ложатся на стек, агент ошибается в непривычных местах. Методология — это контракт под конкретный язык и домен, не универсальная заплатка.
  • Спека пишется после кода. «Задокументируем то, что есть» — общий язык не работает, потому что код уже принял решения вместо спецификации. Спека нужна до реализации не ради бюрократии, а чтобы поймать ошибки раньше, чем они зашиты в десяти файлах.
  • Правила живут только в документе. Гайд в CLAUDE.md, который никто не читает, — это не методология. Если агент не применяет правило автоматически на каждом PR, оно живёт только в голове человека. Это и есть разница между исполняемым стандартом и PDF.
  • Нарезка мимо. Один юз-кейс на весь модуль — не собрать и не проверить целиком. Карточка на каждый метод — накладные расходы больше самой работы. Единица работы — сквозной пользовательский сценарий от входа до ответа.
  • Методология как ответ на вопрос «что делать». Если ты выбираешь методологию, потому что не знаешь, с чего начать — это не та причина. Методология не заменяет понимание задачи; она помогает держать правила, когда задача уже ясна. Сначала — проблема, потом — каркас вокруг неё.

Дальше

Это финальная статья программы «Продукт-инженер». Ты прошёл весь путь: от формулировки проблемы и нарезки срезов — до кода, релиза и измерения бизнес-результата. Следующий шаг — практика с конкретным каркасом: Use Case Pattern как один из вариантов, который связывает явные контракты, исполняемые правила и единый язык в готовую систему.