كيف بنى مدير منتج من دون خلفية تقنية مشروعين تجريبيين خلال أسبوع باستخدام Claude وKiro

Продакт-менеджер без практического опыта разработки описал кейс, в котором за одну неделю собрал и выкатил два рабочих пилота с помощью Claude, Kiro, Figma Make и mcp-серверов. История интересна не только самим результатом, но и тем, как меняется порог входа для запуска первых версий продукта без полноценной инженерной команды.

Из чего стек В основе флоу — разделение ролей между несколькими AI-инструментами.

Claude Sonnet 4.5 автор использовал для discovery: туда загружались аудитория, боли, jobs-to-be-done, ограничения и бизнес-ценность. На выходе получались аналитика, контент и промты для следующих этапов. Figma Make отвечал за генерацию фронтенда, а Kiro от Amazon — за сборку, архитектурные решения и деплой. В качестве инфраструктуры использовались Supabase для базы данных, GitHub Pages для хостинга и mcp-серверы для контекста и тестов.

• Claude Sonnet 4.5 — discovery, аналитика, контент и системный промт Figma Make — генерация фронтенда для пилотной версии Kiro — сборка проекта, фиксация решений и деплой Supabase и GitHub Pages — база данных и публикация Context7 и Playwright через mcp — память между сессиями и базовые e2e-проверки Такой набор интересен тем, что в нём нет попытки заставить один инструмент делать всё сразу. Автор распределил задачи по сильным сторонам сервисов и тем самым снизил количество ручных правок. По его оценке, только на этапе аналитики и дизайна удалось сэкономить около 40 часов — именно за счёт того, что артефакты из discovery почти без потерь переходили в генерацию интерфейса и дальше в сборку.

Флоу по шагам Процесс начинался не с кода, а с постановки задачи.

Для каждого продукта создавался отдельный ассистент в Claude, которому передавали весь контекст: кто пользователь, какую проблему решает сервис, что считается ценностью и какие ограничения нельзя нарушать. После этого материалы переносились в Figma Make, где генерировался фронтенд без ручной доводки. В кейсе речь шла о двух проектах: личном сайте по продуктовому консалтингу и бесплатном agile-инструменте, который автор рассматривает как раннюю альтернативу Jira для стартапов.

Следующий шаг — передача фронтенда и аналитики в Kiro. Автор выделяет именно этот инструмент как центр всего пайплайна, потому что Kiro сначала формулирует решения письменно, а затем реализует их, не прыгая сразу в код. После этого подключались три mcp-сервера: Context7 для удержания контекста между сессиями, Supabase MCP для схемы базы и миграций, Playwright MCP для проверки критических пользовательских сценариев.

Финальный этап выглядел максимально прикладно: регистрация в GitHub и Supabase, создание базы, деплой на GitHub Pages и инструкция по привязке домена.

Где узкие места

Главное ограничение автор формулирует прямо: такой флоу хорошо подходит для пилотов и mvp, но не снимает вопросы качества на пути к полноценному production. Если продукт рассчитан на высокую нагрузку, сложные интеграции или длинную поддержку, архитектуру всё равно нужно перепроверять человеком. Особенно это касается решений, которые Kiro может принять автоматически: в статье отмечено, что часть из них выглядит спорно без базового технического ревью. То же касается контекстных окон: Context7 помогает не терять нить проекта, но не делает проблему памяти полностью исчезнувшей.

«Вайб-кодинг — не замена разработчикам.»

Отдельный риск связан с тестированием. Playwright MCP, по наблюдению автора, уверенно закрывает happy path, то есть базовые сценарии, но не избавляет от необходимости отдельно проверять edge cases. Поэтому описанный стек выглядит как инструмент быстрого старта, а не как готовый рецепт для зрелой команды. Его сильная сторона — скорость проверки гипотезы и предсказуемый процесс для нетехнического продакта; слабая — необходимость вовремя подключить инженера, когда пилот начинает превращаться в настоящий продукт.

Что это значит

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