Scrum, Kanban, XP, оценка, масштабирование — всё это отвечает на вопрос «как организовать работу людей». Есть и второй вопрос, которого в этих методологиях нет: что делать, когда заметную часть кода пишет AI-агент. Ему тоже нужны правила, только другие: контракт на задачу; исполняемый стандарт — правила, которые он применяет на каждом PR; общий словарь, чтобы человек и агент понимали задачу одинаково.
К этой мысли сайт подводит с двух сторон. Со стороны команды — статьи про модели разработки и процесс: там правила держат люди на встречах. Со стороны одного человека — статьи про продукт-инженера: там весь путь ведёт один, и держать правила в голове не выходит. Разберём, из каких свойств складывается методология, пригодная для работы с агентом, какие есть способы её держать и на чём построен этот сайт.
Методология — это не бюрократия, а способ назвать правило один раз. Пока оно живёт в голове, агент решает один и тот же вопрос по-разному в каждой задаче, и стыки расходятся.
Зачем вообще методология, если есть 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 не проверен» ловится на этапе инвариантов, ещё в спецификации, а не в проде — но только если инвариант вспомнили и записали. Спецификация ловит ровно то, что в неё внесли, и никакой механизм не напомнит сам о существовании пользователя; помогает привычка задавать по каждой карточке один и тот же набор вопросов: что должно существовать, что нельзя нарушить, что будет, если запрос придёт дважды. Ревью при этом никуда не девается — в UCP у каждого правила есть парный скилл ревью. Меняется другое: оно перестаёт начинаться со спора о том, как здесь принято, и занимается продуктом.
Цена честная: карточка — это страница текста, а не проект, плюс первоначальная настройка стандарта. Выгода: ревью сокращается, ошибки смещаются влево, стыки сходятся. При первом проекте методология ощущается как накладные расходы; при втором — как то, что сэкономило неделю.
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.
- Нарезка мимо. Один юз-кейс на весь модуль — не собрать и не проверить целиком. Карточка на каждый метод — накладные расходы больше самой работы. Единица работы — сквозной пользовательский сценарий от входа до ответа.
- Методология как ответ на вопрос «что делать». Если ты выбираешь методологию, потому что не знаешь, с чего начать — это не та причина. Методология не заменяет понимание задачи; она помогает держать правила, когда задача уже ясна. Сначала — проблема, потом — каркас вокруг неё.
Коротко
- Методология для агента отвечает не на вопрос «как организовать людей», а на вопрос «как назвать правило один раз», чтобы агент решал одинаковый вопрос одинаково в каждой задаче.
- Пригодность к работе с AI задают четыре свойства: явный контракт на задачу, исполняемые правила вместо документа, единый словарь и нарезка на проверяемые срезы; бренд вторичен.
- Spec-driven разработка, DDD со стандартами и ADR закрывают эти свойства по частям; Use Case Pattern связывает их в один каркас: карточка юз-кейса, правила
R-*, парный скилл ревью. - Спецификация ловит ровно то, что в неё записали: по каждой карточке задают один и тот же набор вопросов о том, что должно существовать, что нельзя нарушить и что будет при повторе запроса.
- Цена: страница карточки и первоначальная настройка стандарта; выгода видна со второго проекта, когда ревью перестаёт начинаться со спора о том, как здесь принято.
- Признак рабочей методологии не объём документации, а то, что агент реже переспрашивает и реже ошибается в одном и том же месте.
Что почитать дальше
- Use Case Pattern — обзор каркаса: карточки юз-кейсов, доменный слой и исполняемые правила в одной системе.
- Исполняемый стандарт — как правило с кодом
R-*применяется агентом на каждом PR и чем это отличается от гайда в документе. - Спецификация изменения — откуда берётся контракт на задачу и как он превращается в тест.
- Модели разработки — как те же вопросы о правилах решают команды людей: водопад, V-модель, итерации.