AI-native MVP-мышление

1. Переход от legacy к MVP — та же инженерная картина

После блока про legacy, modernization и migrations MVP выглядит как прыжок в сторону. Будто вас учили бережно раскручивать старый мотор, а теперь предлагают собрать велосипед из коробки. Прыжка нет — это вторая половина той же инженерной картины.

Когда вы работаете с legacy, главная опасность — сломать то, что уже приносит ценность. Когда вы работаете с MVP, опасность зеркальная: принести слишком много ценности за один раз и умереть где-то между третьим экраном, пятой интеграцией и фразой «ну ещё чуть-чуть, и будет как у взрослых». В первом случае губит неосторожность, во втором — отсутствие тормозов. А инструменты те же: scope, non-goals, constraints, план проверки. Раньше они защищали существующий код — теперь вас, от соблазна построить небоскрёб там, где нужен киоск с терминалом оплаты.

Важно ещё раз зафиксировать: MVP — это не обязательный тип проекта, а способ думать о размере и ценности результата. Capstone — migration slice? Оптика не заставит делать лендинг, но заставит выбрать минимальный полезный pilot. DevOps automation? Не красивый интерфейс, а один повторяющийся сценарий с измеримой пользой. Team workflow design? Не «AI-платформа для всей компании», а «какой один workflow уже болит команде и как улучшить его одним working asset». Так что тема нужна даже тем, чей capstone — не MVP в чистом виде: она учит инженерной скромности. А скромность и довозит проект до защиты.

2. Четыре артефакта: prototype, MVP, demo, production

Путаница вокруг MVP обычно начинается не с кода, а со слов. Люди называют MVP любой черновик, demo — любое видео, prototype — любой экран с кнопкой. А слова дороги: назовёте production product словом MVP — потребуете неадекватной надёжности; назовёте так prototype — покажете заготовку без пользы и удивитесь холодности reviewer'а. Поэтому сначала полезно разложить четыре артефакта по полочкам, иначе scope поползёт уже на терминах.

Вот таблица, к которой удобно возвращаться весь этот уровень.

Здесь важно заметить одну тонкость. Demo — это не «ещё один тип продукта», а показовая сборка MVP. А demo без настоящего MVP обычно превращается в театральную постановку, красивую до первого неловкого клика.

Посмотрим на тот же Support Agent чуть подробнее — он проходит эти уровни по шагам: Python-скрипт с typical/needs-human — prototype; путь «входящий тикет → классификация → draft ответа → подтверждение оператором» — уже MVP; тот же путь на sample data, показанный reviewer'у за несколько минут, — demo. И вот тут приходит соблазн написать в README «корпоративная AI-платформа омниканальной поддержки». Не надо: учебный MVP не обязан притворяться SaaS-империей. Иначе маркетинг сломает инженерию раньше бага.

Для быстрой самопроверки можно держать перед глазами такой мини-шаблон:

prototype      → доказывает, что подход вообще работает
MVP            → даёт реальную пользу в одном core flow
demo           → показывает этот core flow внешнему человеку без шаманства
production     → берёт на себя надёжность, безопасность и сопровождение

Если ваш текущий проект нельзя уверенно поставить в одну из этих строк, значит, вы пока смешали несколько состояний сразу. А смешанные состояния в проектировании опасны почти как смешанные ветки в Git: кажется, всё держится, а потом начинается весёлое.

3. Граница между AI и инженерией в MVP

Где здесь AI? Если ответ «он сейчас сам всё соберёт» — проект одной ногой в болоте хаотичной генерации. Слово AI-native легко понять неправильно: не «всё делает AI», а то, что вы сознательно строите workflow, где AI помогает на каждом коротком участке. Но цель, границу первой версии, core flow, состав scope и способ доказать работоспособность определяете вы.

Именно здесь проходит водораздел между AI-native MVP и обычным хаотичным vibe coding. В хаотичном режиме человек пишет: «Claude, сделай мне AI-сервис поддержки магазина». Модель, как вежливый и слишком оптимистичный собеседник, начинает стараться. Через двадцать минут у вас планы на админку, роли, аналитику, интеграцию с CRM, авторизацию через magic link и лёгкая паника. В AI-native режиме первый ответ Claude другой:

Вы: Хочу сделать AI-сервис поддержки магазина.

Claude: Уточните, пожалуйста:
1. Кто конкретный пользователь первой версии?
2. Какую одну боль мы решаем?
3. Какой один сценарий должен работать на demo?
4. Что точно не входит в первую версию?

Вот такой Claude нам нравится. Не потому, что «менее умный», а потому, что не помогает сделать ошибку красивее.

Если говорить совсем практично, AI хорошо ускоряет четыре зоны:

Сжатие неопределённости — быстро превратить туманную идею в несколько проверяемых формулировок.

Черновая реализация — собрать первый скелет интерфейса, набросать структуру данных, подготовить sample data.

Документирование и упорядочивание — аккуратно описать core flow, ограничения, сценарий показа.

Быстрая локальная проверка — пройтись по логике, найти явные дыры, оформить smoke check.

Но AI не должен становиться тем, кто принимает за вас стратегические решения о размере проекта: энтузиазма у него много, а ответственности за ваш дедлайн — ноль. Это как спросить энергичного знакомого про планы на выходные и через пять минут оказаться в ремонте кухни, хотя хотели поменять лампочку.

Именно поэтому AI-native MVP всегда держится на двух опорах: скорости и дисциплине. Только скорость — всё раздувается. Только дисциплина без скорости — многонедельная архитектурная исповедь без живого результата. Баланс — скучное слово, зато отлично работает в проектах.

4. Быстрая итерация без инженерной амнезии

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

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

flowchart TD
    A[Одна пользовательская боль] --> B[Один core flow]
    B --> C[Быстрый черновик реализации]
    C --> D[Проверка на sample data]
    D --> E[Небольшая правка]
    E --> F[Demo-ready slice]

Здесь важно увидеть, что из схемы ничего не исчезло: в ней есть и формулировка боли, и core flow, и проверка, и исправление. Дисциплина никуда не делась — она просто стала компактной. Это и есть fast iteration with engineering discipline.

А чтобы не уехать в фантазию, сделайте self-check до кода — буквально пять строк.

# MVP self-check

Пользователь: оператор поддержки небольшого интернет-магазина
Одна боль: типовые тикеты съедают время, срочные refund-запросы теряются
Один core flow: ticket → classification → draft ответа → ручное подтверждение
Как проверим: 10 sample tickets, видим draft, видим блокировку refund > $100
Чего не обещаем: многоканальность, CRM, voice support, автосписания

Этот маленький блок почти магически полезен: не заполняется строка — проблема вскрылась. Нет пользователя — проект абстрактный. Нет одной боли — решаете всё сразу. Нечего вписать в «не обещаем» — scope уже ползёт по столу.

Отдельно подчеркну: быстрая итерация не отменяет verification. Полного enterprise-набора quality gates не нужно, но минимум обязателен: проект запускается, core flow проходится, sample data готовы, демо-сценарий воспроизводим. «Вроде работает, когда я нажал вот сюда, потом обновил страницу, потом не трогал ничего десять секунд» — это ещё не demo-ready, а честный черновик. Просто не выдавайте его за другое состояние.

Именно поэтому курс снова и снова возвращает вас к мысли про one core flow. Один рабочий сценарий почти всегда полезнее пяти фич, готовых «процентов на семьдесят, но идея же понятна». Идея-то понятна. Reviewer'у хочется, чтобы это работало.

5. AI Support Agent: правильный размер MVP

Чтобы всё это не осталось на уровне красивых слов, вернёмся к AI Support Agent for Online Store. Домен вам уже знаком по Commerce OS — а значит, можно сосредоточиться не на новой предметной области, а на правильном размере MVP.

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

AI-центр поддержки магазина:
- email, chat, voice
- CRM-интеграция
- автоответы
- аналитика операторов
- рекомендации по возвратам
- мультиязычность
- база знаний
- автозакрытие тикетов

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

AI Support Agent для оператора поддержки:

Оператор открывает inbox и видит входящий ticket.
Система показывает классификацию: typical / needs-human / refund-high-value.
Для typical ticket есть черновик ответа.
Для refund выше $100 автоматической отправки нет — нужен ручной шаг.

Вот это хороший размер. Один пользователь, одна боль, один связный сценарий от входа к результату — и встроенный guardrail: AI не решает там, где риск выше. В одном месте ускорение, в другом ограничение.

Почему этот пример особенно полезен для курса? Потому что он показывает главное: MVP — это не «урезанная версия всего продукта», а один осмысленный slice продукта. Не половина CRM, не четверть контакт-центра — один законченный путь, где уже есть и AI, и human-in-the-loop, и граница ответственности.

Здесь же очень хорошо видно, почему capstone не обязан быть production SaaS. Не нужны тысячи операторов, нагрузочное тестирование, дежурства и observability. Нужно показать честно: один сценарий реально помогает, воспроизводится, проверяется и не обещает того, чего нет. На учебном проекте это не «мало» — это разумное «достаточно».

Короткая формула для запоминания:

Когда вы начинаете мыслить проект именно так, туманная «AI-идея» превращается в нормальную инженерную задачу — без лишнего героизма и без надежды, что модель однажды ночью тихо соберёт за вас весь продукт. Практически: value proposition, пользователь, метрика, границы и demo-сценарий лучше сразу собрать в один spec-документ, а не размазывать по заметкам. Для чистого MVP это MVP_SPEC.md; если capstone другого типа, тот же каркас живёт в уже существующем SPEC.md.