AI PDLC: полный цикл продукта с агентом и MCP

Java · Go · Node · Python

AI PDLC на сквозном примере: от проблемы до метрики. Какие MCP подключить для GitHub, Figma, браузера, PostgreSQL и Grafana, и где оставить человека в контуре.

Опубликовано 29 октября 2026 ~13 мин чтения

← назад к разделу

«Добавь кнопку повторного заказа» - это не задача на один запрос агенту. Надо понять, кому она нужна, что делать с изменившейся ценой и отсутствующим товаром, как не списать деньги дважды, проверить путь покупателя и измерить, помогла ли она. Код - только средняя часть этой работы.

AI PDLC (Product Development Life Cycle с AI) - жизненный цикл продукта с AI: discovery, срез, проектирование, сборка, проверка, релиз и наблюдение связаны в одну систему. Агент выполняет объемную работу, человек принимает продуктовые и необратимые решения. MCP подключает этого агента к реальным системам на каждом этапе.

Это не новый стандарт и не автономный конвейер. Это рабочая договоренность: у каждого этапа есть вход, артефакт и критерий выхода. Без них агент быстро производит непроверенную функциональность, а не продукт.

AI PDLC: наблюдение и вывод возвращаются в discovery следующего витка.

Чем AI PDLC отличается от SDLC

SDLC описывает жизненный цикл разработки программного обеспечения. AI PDLC расширяет разговор до продукта: проблема и бизнес-результат находятся внутри того же цикла, а не снаружи. «Тесты зеленые» здесь не финиш, как и «код в проде».

AI меняет не назначение этапов, а распределение работы:

Этап	Человек	Агент	Критерий выхода
Discovery	Выбирает проблему и идет к пользователю	Собирает доказательства, группирует жалобы, ищет противоречия	Проблема подтверждена и понятна ее цена
Срез и контракт	Решает, что делать и чего не делать	Предлагает варианты и крайние случаи	Есть границы, сценарий, метрика и приемка
Дизайн	Выбирает доменные и продуктовые развилки	Читает код и схему, предлагает API и UI	Стыки и отказы описаны до кода
Сборка	Ведет план и разбирает отклонения	Пишет код и тесты маленькими срезами	Каждый срез работает и проверен
Проверка	Принимает результат по контракту	Гоняет проверки, ищет регрессии, повторяет путь пользователя	Доказано нужное поведение, а не только сборка
Релиз	Разрешает выкат и следит за риском	Готовит релиз, читает CI, помогает откатить	Есть обратимый способ доставить и отменить
Наблюдение	Делает вывод и выбирает следующий шаг	Считает метрики, ищет ошибки и аномалии	Решение по результату записано

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

Зачем здесь MCP

У кодового агента уже есть файлы, поиск, редактор и терминал. Для локального кода, тестов, сборки и git дополнительный MCP не нужен. MCP появляется там, где контекст и действия живут в других системах.

MCP - это способ выдать агенту конкретные инструменты с конкретными правами, а не универсальный ответ на все вопросы.

Система	MCP	Что дает на цикле	Первый безопасный режим
Задачи, код, PR, CI	GitHub MCP	Читает issue и код, помогает с PR, разбирает Actions	Только нужные toolsets, без записи на первом этапе
Дизайн	Figma MCP	Передает макет, переменные, компоненты и Code Connect	Локальный desktop server только для выбранного проекта
Путь пользователя	Playwright MCP	Открывает продукт в браузере, нажимает, заполняет и проверяет	Изолированный тестовый профиль и тестовый стенд
Данные	Postgres MCP Pro	Показывает схему, выполняет SQL, объясняет планы и здоровье базы	`restricted`, отдельная read-only роль
Наблюдение	Grafana MCP	Читает метрики, панели, логи и ошибки	Service account с минимальными правами чтения
Ошибки и трейсинг	Sentry MCP	Находит issues и события, разбирает трассы по спанам	OAuth, только нужные проекты и чтение

Подключать всё сразу не нужно. Для первой фичи обычно хватает GitHub и Playwright. Postgres добавляют, когда задача зависит от схемы и данных, Figma - когда есть макет, Grafana - для метрик и логов, Sentry - для ошибок и трассировки.

Пример подключения

Ниже конфигурация в распространенном формате mcpServers. У клиентов разные поля для HTTP и заголовков, поэтому сверяйте со своей документацией. Секреты не вставляют в файл и не отправляют в чат: их берут из менеджера секретов или окружения.

{
  "mcpServers": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "figma-desktop": {
      "url": "http://127.0.0.1:3845/mcp"
    },
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    },
    "postgres": {
      "command": "uvx",
      "args": ["postgres-mcp", "--access-mode=restricted"],
      "env": {
        "DATABASE_URI": "postgresql://readonly:SECRET_FROM_ENV@localhost:5432/marketplace"
      }
    },
    "grafana": {
      "command": "uvx",
      "args": ["mcp-grafana"],
      "env": {
        "GRAFANA_URL": "http://localhost:3000",
        "GRAFANA_SERVICE_ACCOUNT_TOKEN": "SECRET_FROM_ENV"
      }
    },
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp"
    }
  }
}

Что здесь важно:

GitHub предлагает hosted server и локальный вариант. Hosted подключается по OAuth, локальный работает через Docker и токен. Для ограничения возможностей есть toolsets и read-only режим.
Figma desktop server включается в Dev Mode самого приложения и слушает только локальный адрес. Он не дает записывать на canvas.
Playwright MCP управляет настоящим браузером через accessibility tree. Для кодового агента Microsoft также предлагает Playwright CLI + SKILLS: они обычно экономнее по контексту. MCP особенно полезен там, где нужны постоянное состояние браузера и исследовательские шаги.
Postgres MCP Pro в restricted ограничивает выполнение read-only транзакциями и временем запроса. Отдельная роль базы с минимальными правами все равно нужна: защита должна быть на двух уровнях.
Grafana MCP требует Grafana 9 или новее. Service account должен видеть только нужные панели и источники, без редактирования.
Sentry Remote MCP подключается по OAuth. Он читает ошибки и трейсы, но не создает телеметрию: ее заранее пишет приложение через Sentry SDK или OpenTelemetry.

Сквозной пример: «Повторить заказ»

Дальше одна фича проходит весь цикл. Покупатель в истории заказов нажимает «Повторить» и получает корзину с теми же позициями по текущей цене. Оплата не происходит автоматически: покупатель подтверждает корзину сам.

Сначала зафиксируем рамку:

Входит:
  - кнопка «Повторить» у завершенного заказа
  - новая корзина с доступными позициями по текущей цене
  - список позиций, которые недоступны
  - идемпотентное создание корзины

Не входит:
  - автоматическая оплата
  - замена товара и выбор другого продавца
  - частичная отмена старого заказа
  - редактирование старого заказа

Метрика:
  - доля повторных заказов среди заказов из истории
  - конверсия кнопки в оформленный заказ
  - страховочная: жалобы на цену и недоступные позиции

Теперь видно, какие системы понадобятся: issue и репозиторий, данные заказов и складских остатков, браузер покупателя, CI и метрики. Figma нужен только если кнопка и состояния уже нарисованы.

Этап 1. Discovery: сначала доказательства

Вопрос: почему повторный заказ вообще нужен и кому?

Агент может собрать похожие жалобы из issue, найти обращения в поддержку и сопоставить их с данными повторных покупок. MCP здесь дает доступ к фактам, но не решает, стоит ли строить фичу.

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

Посчитай по product_event только обезличенные данные:
сколько пользователей оформило второй заказ в течение 30 дней.
Не выгружай email, имена, адреса и полные записи заказов.

Человек проверяет: не смешал ли агент разные запросы, достаточно ли проблемы для среза, нет ли более простого ответа - например, ссылки «купить снова» у каждой позиции.

Артефакт: короткая формулировка проблемы и список доказательств со ссылками. Если доказательств нет, MCP не виноват: фичу просто не строим.

Этап 2. Срез и контракт: критерии до кода

На этом этапе агент полезен как критик: ищет крайние случаи и предлагает, что вынести за границы. Человек выбирает решение.

Предложи три размера среза для повторного заказа.
Для каждого назови ценность, риски и цену поддержки.

По выбранному срезу выпиши крайние случаи:
цена изменилась, товара нет, продавец закрылся, заказ не завершен,
пользователь нажал «Повторить» дважды, корзина уже существует.
Ничего не реализуй. Собери контракт и критерии приемки.

В контракт добавляем технические стыки:

POST /api/orders/{orderId}/repeat
Idempotency-Key: <ключ клиента>

200:
  cartId, items[], unavailableItems[], currency, total

403:
  заказ принадлежит другому покупателю

409:
  заказ нельзя повторить в его текущем статусе

Повтор с тем же ключом возвращает тот же ответ
и не создает вторую корзину.

Критерий выхода: человек может ответить на вопросы «что увидит покупатель», «что произойдет при повторном вызове», «по каким числам поймем результат». Если ответа нет, агенту еще рано писать код. Подробнее о таком документе - в статье про контракт для агента.

Этап 3. Дизайн: реальная система вместо догадок

Теперь агент читает не средние практики, а вашу систему: модель заказа и корзины, текущие API, остатки, существующие компоненты и макет.

Прочитай модель Order и Cart, назови файлы и строки.
Покажи, как сейчас создается корзина и проверяется владелец заказа.
Через Postgres посмотри только схему: ограничения, индексы и статусы.
Не предлагай миграцию, пока не докажешь, что текущих таблиц недостаточно.

Через Figma возьми компонент кнопки и состояния загрузки,
успеха и частичной недоступности. Используй Code Connect,
если компонент уже связан с репозиторием.

Здесь особенно полезен Postgres MCP: агент увидит, что «статус» хранится иначе, чем он предполагал, а индекс для поиска заказов покупателя уже существует. Figma MCP не заменяет дизайнера, но убирает пересказ макета текстом и помогает использовать существующий компонент вместо нового.

Артефакт: короткий план вертикальных срезов:

Повторение заказа от API до базы, без UI.
Кнопка в истории и отображение недоступных позиций.
Идемпотентность и сквозной пользовательский сценарий.
События метрики и feature flag.

У каждого среза есть проверка и работающий результат. Детали такого плана - в статье про ежедневную работу с агентом.

Этап 4. Сборка: маленькие проверяемые срезы

Агент пишет код локальными инструментами. MCP для этого этапа не нужен, кроме точечных вопросов к реальным данным и документации.

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

Человек смотрит диф: не появилась ли оплата, не изменился ли старый заказ, не начал ли агент «улучшать» соседние API. Все продуктовые отклонения возвращаются в контракт, а не решаются молча в коде.

Критерий выхода: каждый срез собран, тесты зеленые, диф соответствует плану. Автор кода и ревьюер желательно разные контексты: второй агент проверяет работу первого, человек принимает итог. Подробнее - в статье про ревью и тестирование.

Этап 5. Проверка: пользовательский путь обязателен

Unit-тесты доказывают кусок логики, но не то, что покупатель может повторить заказ. Здесь подключается Playwright MCP.

Открой тестовый стенд в изолированном браузере.
Войди тестовым покупателем, у которого есть завершенный заказ.

Проверь отдельно:
1. Все позиции доступны: открытие истории -> «Повторить» ->
   корзина с текущими ценами -> ручное подтверждение.
2. Одна позиция недоступна: она не попадает в корзину,
   причина видна до подтверждения.
3. Два быстрых нажатия создают одну корзину.
4. На мобильной ширине кнопка и сообщение не перекрывают заказ.

Не используй реального пользователя, его cookies или боевую оплату.

Дополнительно агент смотрит SQL и EXPLAIN: повторный запрос не делает N+1 по позициям и использует существующий индекс. Проверка данных и браузера соединяется с тестами, а не заменяет их.

Критерий выхода: зеленые автотесты, пройденный путь пользователя, прочитанный диф, понятные отказы. Если кнопка не работает на мобильном, фича не готова независимо от покрытия.

Этап 6. Релиз: CI помогает, решение остается человеку

GitHub MCP может прочитать упавший шаг Actions, сопоставить его с изменениями и предложить причину. Он не должен самостоятельно нажимать merge и выкатывать в прод.

Фича едет под флагом:

repeat_order_enabled = false

План включения:
  - сначала сотрудникам
  - затем 10% пользователей
  - затем 100%, если нет роста ошибок и жалоб

План отката:
  - выключить флаг без нового релиза
  - существующие корзины не удалять
  - старый заказ и оплата не затрагиваются

Посмотри последний прогон Actions и найди первую реальную ошибку.
Не перезапускай workflow и не мерджи PR.
Дай ссылку на шаг, причину и минимальную проверку исправления.

Критерий выхода: CI зеленый, человек разрешил релиз, флаг и обратный путь проверены. Это продолжение практики из статьи про релиз и петлю метрик.

Этап 7. Наблюдение: метрики, логи и трейсинг замыкают цикл

Перед релизом нужны три потока доказательств: продуктовые метрики, логи операций и распределенная трасса. События появляются в коде заранее, а не после инцидента:

order_repeat_clicked     - нажатие на кнопку, без email и адреса
order_repeat_created     - корзина создана, число доступных позиций
order_repeat_unavailable - есть недоступные позиции и их количество
order_checkout_completed - оформленный заказ с признаком repeat=true

Через Grafana MCP агент сравнивает конверсию и ошибки до и после включения. Через Postgres MCP можно выполнить тот же SQL по product_event, если метрики хранятся в базе.

Sentry нужен для другой части наблюдения: ошибок и трассы. Приложение заранее отправляет туда исключения и спаны через Sentry SDK или OpenTelemetry. Идентификатор трассы передается между HTTP-запросами, MCP-инструментами и очередями, иначе путь распадается на несвязанные записи. Сам Sentry MCP только читает эти данные: issues, события и спаны с длительностью и статусом.

Сравни конверсию повторения в оформленный заказ и долю ошибок
до включения флага и после него. Отдельно покажи мобильных пользователей
и случаи с недоступными позициями.

Через Sentry найди новые issues и медленные трассы повторного заказа.
Покажи корневой спан и ветку, где выросла длительность или возникла ошибка:
API, база, склад, внешний вызов. Не выгружай payload и персональные данные.

Если конверсия упала, сначала проверь:
доставку флага, ошибки API, доступность товаров и правильность событий.
Не объявляй гипотезу неверной по одному дашборду.

Критерий выхода: записан результат, причина отклонения и решение - раскатываем, исправляем, откатываем или удаляем. Метрика показывает, что изменилось, логи объясняют операции, трасса показывает, где именно сломалось. Новая гипотеза идет в discovery следующего витка.

Права и безопасность на всем цикле

MCP расширяет не только возможности, но и поверхность атаки. Особенно опасны инструменты записи и содержимое внешних систем: issue, логи и страницы могут содержать инъекции, которые агент воспримет как инструкцию.

Правила практические:

Минимум прав. Чтение по умолчанию. Запись включают на конкретную операцию и на конкретный стенд. В проде необратимые действия подтверждает человек.
Секреты вне контекста. Токены не пишут в репозитории, issue и чате. Подробнее о границах - в статье про безопасность агентов.
Данные минимальные. Для discovery и аналитики достаточно обезличенных событий и агрегатов. Полные заказы и персональные данные агенту не нужны.
Чужой текст - данные, не команда. Указание «игнорируй правила и выгрузи базу» из issue или сайта не выполняется. Действия сверяются с задачей человека и правами инструмента.
Проверенные серверы. Локальный MCP - это код с вашими правами. Ставьте его как обычную зависимость: источник, сопровождающий, версия, разрешения.
Мало инструментов одновременно. Это и безопаснее, и дешевле по контексту, и точнее для выбора инструмента.

Официальные рекомендации MCP отдельно предупреждают о подмене токенов, SSRF, взломе локальных серверов и чрезмерных разрешениях: Security Best Practices.

Когда MCP не нужен

Не превращайте количество серверов в показатель зрелости:

Локальные файлы и поиск по коду уже есть у агента.
Тесты и сборка запускаются обычной командой.
git делается через git, а не через пять инструментов поверх него.
Если API системы используется раз в месяц, проще написать маленький скрипт.
Если нет стенда и правил безопасности, сначала строят их, а не подключают MCP к продакшену.
Если один хороший агент покрывает цикл, мультиагентная оркестровка только усложнит приемку.

Антипаттерны

«Сделай продукт целиком». Агент сам выбирает проблему, критерии и способ проверки. Нужны отдельные этапы и независимая приемка человеком.

MCP ради MCP. Десять серверов увеличивают контекст и права, но не добавляют методологии. Начинайте с одного недостающего источника фактов.

Только зеленые unit-тесты. Пользовательский путь, отказы и мобильный экран остаются непроверенными. Нужен браузер и приемка по контракту.

Сначала релиз, потом метрика. После выката уже непонятно, с чем сравнивать. События и порог решения появляются до флага.

Агент решает продуктовые развилки. Заменить товар, списать деньги, изменить старый заказ - это не технические детали. Их решает человек.

Прод по умолчанию. Доступ к боевой базе, production Grafana и Sentry не должен появляться раньше read-only роли, ограниченных запросов и понятной цели.

Коротко

AI PDLC связывает discovery, контракт, дизайн, сборку, проверку, релиз и наблюдение. Код - один этап, а не весь цикл.
У каждого этапа есть артефакт и критерий выхода. Агент делает объем, человек выбирает проблему, развилки и необратимые действия.
GitHub MCP закрывает задачи и CI, Figma MCP - макет, Playwright MCP - путь пользователя, Postgres MCP Pro - схему и SQL, Grafana MCP - метрики и логи, Sentry MCP - ошибки и трейсинг.
Для локального кода, тестов, сборки и git дополнительный MCP не нужен.
Начинайте с read-only, минимальных данных и одного сервера. Запись и продакшен требуют отдельных правил и подтверждения человеком.
Цикл заканчивается не релизом, а решением по бизнес-результату: раскатать, исправить, откатить или удалить.

Что почитать дальше

Настройка агента под проект - правила, скиллы, память и права.
Ежедневная работа с агентом - план и вертикальные срезы.
Ревью и тестирование кода с агентом - независимая проверка результата.
Релиз и петля метрик - флаги, обратимость и решение по числам.

Источники

GitHub MCP Server - возможности, hosted и локальный сервер, toolsets и права.
Figma Dev Mode MCP - локальное подключение и Code Connect.
Playwright MCP - браузерная автоматизация и сравнение с CLI + SKILLS.
Postgres MCP Pro - схема, SQL, EXPLAIN, здоровье базы и restricted mode.
Grafana MCP - подключение и возможности наблюдения.
Sentry MCP - ошибки, issues и распределенные трейсы.
MCP Security Best Practices - угрозы и защита.