Запускаю context.lat: почему половина из 90 минут — не код
Каталог AI-инструментов context.lat я запустил за один стрим — 90 минут от чистого листа до рабочего сайта на своём домене. Код агент писал только последние 40 минут. Остальные 50 я думал, исследовал и планировал. И именно поэтому результат получился рабочим с первой попытки.
Боль: комьюнити без каталога
В Кружке вайбкодеров мы постоянно обсуждаем инструменты. Какую модель использовать? Какой MCP подключить? Что лучше для фронтенда — v0 или Lovable? Каждую неделю одни и те же вопросы.
Голосования в чате помогают на день. Через неделю результаты тонут в потоке сообщений. Нет единого места, где можно посмотреть: вот инструменты, вот модели, вот что комьюнити рекомендует.
Решил запустить такой каталог. Но не как обычно — не открывать редактор и просить агента “сделай сайт”. Хотел показать на стриме подход, который работает для любого проекта.
Методология: 80% до кода
Christopher Graves построил MVP за 90 минут и написал: “The secret is the foundation you build BEFORE AI starts coding”. Addy Osmani советует сначала работать в режиме “только чтение” — планируй, потом выполняй. 90% кода самого проекта Claude Code пишется Claude Code — но по спецификации, а не с нуля.
Справедливая критика вайбкодинга: он фокусируется на последнем этапе — генерации кода. А реальная работа — продуктовая проработка. Промпт “сделай каталог AI-инструментов” даст шаблонный результат. Промпт после 30 минут планирования — рабочий продукт.
ТИПИЧНЫЙ ПОДХОД МЕТОДОЛОГИЯ СТРИМА
────────────────── ──────────────────────────
"Сделай сайт" Проблема
│ │
▼ ▼
Шаблонный Deep Research
результат (данные, аналоги)
│ │
▼ ▼
Переделки Персоны + User Stories
переделки │
переделки ▼
│ PRD → Прототип (v0)
▼ │
Через неделю ▼
выкидываешь Агент пишет код
по спецификации
│
▼
Деплой. Работает.
Вот как это выглядело на практике.
Этап 1: Определение проблемы (0:00)
Не “хочу сайт”. А “какую проблему решаю и для кого”.
Я задал себе три вопроса. Кто будет пользоваться? Новички, которые не знают с чего начать. Опытные вайбкодеры, которые ищут конкретный инструмент. Преподаватели, которым нужен справочник для студентов. Что им нужно? Быстро найти инструмент под задачу, сравнить модели, понять что используют другие. Почему текущие решения не работают? Awesome-листы на GitHub — простыни ссылок без контекста. Чаты — информация теряется.
Шесть минут. Ни строчки кода. Зато ясно, что делать.
Этап 2: Данные и User Stories (6:05)
Запустил Deep Research для сбора данных. Какие каталоги AI-инструментов уже существуют? Чем отличаются? Что работает, что нет?
Параллельно описал три персоны: новичок Даша (не знает, что такое MCP), опытный Макс (ищет конкретный MCP-сервер для PostgreSQL), преподаватель Лена (собирает список инструментов для курса).
Из персон родились User Stories. “Как новичок, я хочу видеть категории инструментов, чтобы понять с чего начать”. “Как опытный пользователь, я хочу фильтровать по типу — модели, скиллы, MCP”. Конкретные сценарии, не абстрактные “пользователь хочет удобный интерфейс”.
Этап 3: Прототип в v0 (18:15)
Имея PRD и User Stories, я перешёл к прототипированию. Сравнил три инструмента: v0, Magic Patterns, Stitch.
Выбрал v0. Причина простая — он быстрее всех генерирует рабочий UI из текстового описания. Скормил ему PRD, получил визуальный прототип. Не код — именно прототип. Посмотрел, как выглядят карточки инструментов, навигация, фильтры.
Написал Claude Code на Opus 4.6:
Агент получил не “сделай сайт”, а конкретную спецификацию с визуальным референсом. Результат — соответствующий.
Этап 4: Hugo вместо Next.js (42:35)
Это было осознанное решение. v0 предлагал Next.js — стандартный выбор для React-проектов. Но мне не нужен React для каталога. Мне нужен SEO, простота и markdown.
Hugo — статический генератор. Каждый инструмент — markdown-файл с метаданными. Не нужна база данных. Не нужен сервер. Деплой на Vercel — бесплатно.
Каждый инструмент — отдельный markdown-файл. Агент разложил их по категориям: модели, скиллы, MCP, IDE.
Никакой базы данных. Любой может отправить Pull Request и добавить инструмент. Никаких миграций, никаких ORM. Контент живёт в репозитории рядом с кодом.
Подробнее писал про выбор простого стека в как сделать пайплайны надёжными — тот же принцип: чем меньше движущихся частей, тем надёжнее.
Этап 5: Параллельные агенты (54:45)
Здесь я использовал Agent Teams. Один агент собирал контент — описания инструментов, категории, теги. Второй настраивал инфраструктуру — Hugo-тему, шаблоны, деплой на Vercel.
Написал Claude Code на Opus 4.6:
GitHub Issues использовались как память агентов — каждая задача фиксировалась, статус обновлялся. Агенты не теряли контекст между шагами. Подробнее про этот паттерн писал в как ускорить разработку скиллами.
Этап 6: Деплой и запуск (1:06:55)
Агент настроил домен context.lat на Vercel, подключил GitHub-репозиторий. Каждый пуш — автоматический деплой.
Для проверки фронтенда использовал Playwright MCP — агент сам открывал сайт в браузере, проверял что страницы рендерятся, карточки отображаются, фильтры работают.
К отметке 1:19 — рабочий каталог на context.lat. Двадцать инструментов с описаниями, категориями и тегами.
Дизайн не важен (пока)
Отдельно про дизайн. Я не тратил время на шрифты, цвета и анимации. Намеренно.
На этапе без пользователей дизайн — пустая трата времени. Сначала проверяешь, нужен ли продукт. Потом красишь. Если каталог будут использовать — вложусь в дизайн. Если нет — сэкономил часы работы.
У меня есть рабочий шаблон от v0. Чистый, читаемый, функциональный. Этого достаточно для MVP.
Шаблон, а не с нуля
Ещё одно решение, которое сэкономило время. Я не создавал проект с нуля. Взял существующий Hugo-проект как шаблон — структуру директорий, конфиг Vercel, GitHub Actions. Адаптировал под каталог.
Начинать с нуля — долго. Работающий шаблон экономит первые 10 минут, которые обычно тратишь на бойлерплейт.
Что я понял
За 90 минут стрима я убедился: время на планирование окупается. По моему опыту, без PRD агент выдаёт шаблонный результат, который потом переписываешь дольше, чем длилось само планирование.
РАСПРЕДЕЛЕНИЕ ВРЕМЕНИ (90 мин)
═══════════════════════════════════════════════════
Планирование ██████████████████░░░░░░░░░░ 30 мин (33%)
Прототип + выбор ████████████░░░░░░░░░░░░░░░░ 20 мин (22%)
Код + деплой ████████████████████░░░░░░░░ 30 мин (33%)
Тестирование ████░░░░░░░░░░░░░░░░░░░░░░░░ 10 мин (12%)
Половина времени — до первой строчки кода. Именно поэтому результат рабочий, а не “переписать через неделю”.
Второе наблюдение: агенту нужен контекст, а не команда. “Сделай каталог” — плохой промпт. “Вот PRD, вот прототип, вот стек — сделай по спецификации” — хороший. Разница как между “нарисуй что-нибудь красивое” и “нарисуй логотип в синих тонах для образовательной платформы в минималистичном стиле”.
Третье: простой стек побеждает. Hugo + markdown + Vercel. Ни одной базы данных. Ни одного сервера. Деплой за секунды. Меньше движущихся частей — меньше проблем.
Формула
Если свести к формуле:
ПРОБЛЕМА → ДАННЫЕ → ПЕРСОНЫ → USER STORIES → PRD
│
ПРОТОТИП (v0/Lovable)
│
АГЕНТ ПИШЕТ ПО СПЕЦИФИКАЦИИ
│
ДЕПЛОЙ
Не начинай с кода. Начинай с вопроса “какую проблему решаю”.
Частые вопросы
Зачем PRD для pet-проекта? Это же не продакшен.
Полстраницы: проблема, аудитория, ключевые сценарии. Пять минут работы. На стриме я потратил шесть минут на определение проблемы — и агент с первой попытки сгенерировал рабочую структуру. Без этих шести минут получился бы очередной шаблонный landing.
Почему Hugo, а не Astro или Next.js?
Для каталога со статическим контентом Hugo — идеальный выбор. Генерация за миллисекунды, SEO из коробки, markdown как формат данных. Next.js имеет смысл, когда нужна интерактивность — авторизация, поиск с бэкендом, динамические страницы. Для MVP каталога это лишнее.
Можно ли пропустить прототип и сразу писать?
Можно. Но тогда прототипом станет первая версия кода. Переписывать код дольше, чем переделать макет в v0. Прототип — это способ проверить идею до того, как агент напишет сотню файлов.
90 минут — это реально или ускоренная запись?
Реальное время стрима. Без склеек, без подготовленного кода. Всё видно на записи — включая паузы на размышления и пару тупиков. Методология работает не потому что я быстрый, а потому что планирование убирает большую часть итераций.
Ссылки: context.lat | Стрим целиком
Подписаться на обновления — @sereja_tech