00:00:00Все знают, что для работы с ИИ-агентами программирования нужен фреймворк, но мало у кого
00:00:04есть что-то простое, по-настоящему свое, что можно развивать со временем. Сейчас
00:00:09на GitHub полно перегруженных фреймворков. Все эти мультиагентные системы, которые
00:00:15создают люди... я уважаю их труд, но зачастую вам нужно что-то
00:00:19совсем простое, что просто выполнит задачу. Ведь я знаю, что у вас есть отличные идеи,
00:00:24которые хочется реализовать, и вы не хотите тратить на настройку рабочих процессов больше времени,
00:00:29чем на само программирование. И именно это я вам сейчас предложу. Это мой предельно простой фреймворк,
00:00:35который я использую каждый раз, когда начинаю новый проект с ИИ-агентом. Конечно,
00:00:40Brownfield-разработка, то есть работа с существующим кодом, немного отличается. Об этом будет другое видео. А здесь
00:00:45мы сосредоточимся на Greenfield — разработке с нуля. Нам нужен простой каркас, чтобы быстро включиться в работу,
00:00:50создавая что-то новое. Все, о чем я здесь расскажу, универсально.
00:00:56Эти принципы применимы независимо от того, какого ИИ-агента вы используете. Видео состоит из двух
00:01:00частей: я буду создавать проект в реальном времени и попутно все объяснять,
00:01:05чтобы это выглядело максимально наглядно. Сейчас в моей кодовой базе практически ничего нет,
00:01:11кроме слоя ИИ. Я перенес лишь несколько команд и навыков. Это мой стартовый набор
00:01:16для любого проекта. Мы будем создавать продукт с нуля,
00:01:21поэтому начнем с начального планирования — создания так называемого PRD. Это документ
00:01:27с описанием первоначального объема работ для создания MVP (минимально жизнеспособного продукта). Здесь
00:01:32предстоит много работы: нужно настроить слой ИИ, прежде чем переходить непосредственно к коду.
00:01:37Затем мы возьмем наш PRD, разобьем его на фазы и будем закрывать их
00:01:43с помощью PIV-циклов. Я объясню, что это такое, покажу на примере, а в процессе
00:01:47реализации я разберу четыре «золотых правила», которым нужно следовать всегда.
00:01:52Эти правила естественным образом впишутся в процесс создания PRD, слоя ИИ и
00:01:57работы в PIV-цикле. Например, управление контекстом.
00:02:03Контекст — это ваш самый ценный ресурс при работе с ИИ-помощниками. Это станет лейтмотивом всего видео.
00:02:08Также мы обсудим создание команд и навыков для всего подряд и подход к эволюции системы,
00:02:14потому что наша цель — создать надежную и
00:02:18воспроизводимую систему. Я буду акцентировать на этом внимание по ходу дела. Постараюсь затронуть
00:02:23все ключевые темы. Видео будет очень насыщенным. Итак,
00:02:28начнем с планирования и создания того, что я называю «слоем ИИ». Сейчас я объясню,
00:02:34что это, и мы построим его вместе. Слой ИИ — это все ресурсы в вашей кодовой базе,
00:02:39которые вы создали в качестве контекста для агента. Например, PRD — что мы строим?
00:02:45Глобальные правила — как мы это строим? Команды — чтобы у агента были
00:02:50готовые рабочие процессы. Сначала сфокусируемся на основной команде. А также субагенты — им можно
00:02:55делегировать исследования. Обычно я работаю со слоем ИИ так (и я подготовил для вас этот ресурс):
00:03:01у меня есть набор общих команд, которые я переношу в любой новый проект.
00:03:07Суть в том, что по мере роста кодовой базы я буду развивать и
00:03:13эти команды, делая их более эффективными и специфичными для конкретного кода.
00:03:18Именно это я вам и рекомендую. Можете использовать мой набор как отправную точку,
00:03:23ссылка на GitHub будет в описании. Смысл такой простоты в том, чтобы вы могли
00:03:27взять этот шаблон и легко адаптировать его под свои задачи и привычки. Именно
00:03:33поэтому я советую такой подход вместо сложных фреймворков вроде Beemad или GitHub Spec Kit.
00:03:38Они мощные, но их трудно сделать «своими». А я хочу, чтобы вы чувствовали контроль. Сейчас я покажу,
00:03:42как составить полный PRD. Определим начальные правила для кода,
00:03:48немного настроим нашу первую команду и по ходу дела обсудим субагентов.
00:03:52Я понимаю, что мы тратим много времени на планирование, еще не написав ни строчки
00:03:57реального кода в PIV-циклах, но это крайне важно. Планирование на старте
00:04:03может показаться медленным процессом, но если составить хороший план, прописать
00:04:07правила и PRD, то вся последующая разработка пойдет гораздо быстрее
00:04:13и надежнее. Начнем с PRD. Многие называют это спецификацией. По сути,
00:04:18это описание всего объема работ для создания первой версии приложения. После того
00:04:24как заложен хороший фундамент, процесс переходит в стадию Brownfield-разработки. Об этом
00:04:28будет мое следующее видео, так что не пропустите. Итак, что я сделаю в Claude Code
00:04:34в моем пустом проекте (где есть только слой ИИ): сначала я просто пообщаюсь с ним
00:04:40в свободном стиле. Расскажу о своей идее, мыслях по поводу стека технологий
00:04:45и архитектуры. Начинать лучше без жесткой структуры — так проще втянуться.
00:04:50А затем, когда наберется достаточно информации, мы используем этот диалог как контекст для создания
00:04:55структурированного PRD. У меня есть команда, которая поможет с этим. Я покажу ее,
00:05:01когда дойдем до дела, но сначала — сама идея. В качестве интересного
00:05:06примера для этого видео я хочу собрать аналог Linktree, но в формате self-hosted,
00:05:12где можно создать свою лендинг-страницу со списком ссылок и их организацией.
00:05:16Там должна быть аналитика, например, кликабельность (CTR) разных ссылок. Хочу сделать что-то подобное.
00:05:20Это отличный пример: задача не слишком тривиальная, чтобы ее можно было просто
00:05:24набросать по наитию (учитывая фишки, которые мы добавим), но и не слишком сложная,
00:05:29чтобы мы не застряли на полпути и успели что-то показать к концу видео.
00:05:33Для ввода данных я воспользуюсь инструментом преобразования речи в текст. Очень рекомендую
00:05:39что-то вроде Aqua Voice. Я пользуюсь им, но есть много хороших бесплатных опций с открытым кодом,
00:05:43например Whisper Flow или Epicenter Whispering. Голосовой ввод — это супер,
00:05:48потому что я точно никогда не смогу печатать со скоростью 226 слов в минуту. Поэтому
00:05:54я использую такой инструмент, чтобы просто выгрузить из головы все мысли по проекту. Это
00:05:59будет «сырой» поток мыслей, но я сделаю этот «брейн-дамп» прямо сейчас в эфире. Обратите
00:06:03внимание на то, о чем именно я прошу Claude Code, потому что это так же важно, как и сами
00:06:09идеи. Чуть позже я объясню почему. Кстати, вы можете проделать это
00:06:13с любым ИИ-помощником. Итак, поехали: «Я хочу создать конструктор страниц-визиток,
00:06:20типа Linktree. Пользователи регистрируются и создают свою
00:06:24посадочную страницу, указывают ссылки, могут менять их порядок. Мне нужно,
00:06:29чтобы была аналитика для отслеживания кликов по ссылкам и возможность настраивать
00:06:33тему оформления. По стеку: думаю использовать Next.js, Neon в качестве
00:06:37базы данных и Neon Authentication. Обязательно запусти субагента, чтобы изучить этот вопрос.
00:06:43По архитектуре у меня нет жестких требований, так что жду твоих рекомендаций,
00:06:48включая то, как лучше реализовать темы и управление ссылками. И еще,
00:06:55я хочу, чтобы ты выделил агента для поиска в сети лучших практик
00:07:00по созданию приложений типа Linktree. А затем вернись ко мне
00:07:04со списком вопросов, чтобы мы согласовали все детали того, что мы тут
00:07:10строим». Отлично. Отправляю запрос, транскрибация займет
00:07:14пару секунд. Готово. Процесс пошел. Самое важное,
00:07:20что я сделал — это в самом конце попросил ИИ задать мне кучу вопросов
00:07:25после завершения исследования. Это критический момент. Ваша главная цель
00:07:32при планировании с ИИ-агентами — свести к минимуму количество допущений,
00:07:37которые делает агент. Потому что, когда агент ошибается в коде,
00:07:42в половине случаев дело не в плохом коде, а в том, что вы просто не договорились,
00:07:48что именно нужно строить. Есть поговорка: одна строка плохого кода — это просто плохой код. Но
00:07:54одна строка в плохом плане — это сотня строк плохого кода. А одна ошибка в PRD
00:08:02может обернуться тысячью строк ненужного кода из-за разного понимания задачи. Я долго
00:08:08экспериментировал с тем, как уменьшить количество допущений,
00:08:13и метод, когда агент засыпает меня вопросами, сработал просто
00:08:17потрясающе. Особенно в Claude Code с его инструментом уточняющих вопросов,
00:08:23где он предлагает варианты ответов или дает вписать свой. Это очень эффективно. ИИ отлично
00:08:28продумывает граничные случаи и мелкие детали, о которых мы можем даже не догадываться.
00:08:33Нам самим трудно предугадать, где именно агент может пойти не в ту сторону. Так что это мощная штука.
00:08:38Еще один момент: как вы видите, сейчас запущены разные субагенты
00:08:42для исследований. Я обожаю использовать субагентов для планирования, создания PRD
00:08:48или даже для подготовки тех самых PIV-циклов, о которых мы поговорим позже. В случае
00:08:53с Claude Code мне не нужно создавать их вручную, так как функции поиска
00:08:59и исследования уже встроены. В других инструментах их, возможно, придется настраивать
00:09:04самостоятельно, поэтому я акцентирую на этом внимание. Но сейчас почти любой
00:09:08продвинутый агент поддерживает концепцию субагентов. Для ресерча это идеально. Основная причина —
00:09:14изоляция контекста. Повторюсь: мы должны беречь контекстное окно основного
00:09:20агента. Исследования — лучший кейс для субагентов,
00:09:26потому что в процессе поиска они просматривают массу информации. Они изучают кодовые базы,
00:09:32статьи в вебе, загружая десятки и сотни тысяч
00:09:36токенов. Но нам-то нужны только выводы — краткое резюме в конце,
00:09:41которое вернется в основной контекст. Так основной чат остается чистым. При этом я не советую
00:09:46использовать субагентов для самой реализации кода, так как там важен весь
00:09:51контекст редактируемых файлов. Иначе, по моему опыту, начинается много галлюцинаций.
00:09:57Именно поэтому в Claude Code нет встроенных агентов для написания кода — только для ресерча.
00:10:01Это мы и наблюдаем сейчас. Я дам процессу завершиться
00:10:06и вернусь, когда появятся вопросы. Итак, ресерч закончен,
00:10:12и у нас есть первый список вопросов. Думаю, вы оцените этот этап
00:10:17так же высоко, как и я, потому что сейчас мы проясняем массу моментов. Каждый ответ
00:10:22убирает очередное допущение из головы
00:10:26агента. Поскольку предлагаются варианты ответов и один из них обычно подходит, мы пройдем
00:10:31этот этап очень быстро. Зато будем уверены, что перед написанием кода
00:10:36все детали зафиксированы. Например: «Какой должна быть структура URL публичной страницы?»
00:10:41Мне нравится первый вариант — выбираю и идем дальше. «Сколько страниц
00:10:46может создать один пользователь?» Оставим одну страницу на пользователя. В некоторых вопросах
00:10:50я просто соглашусь с вариантами по умолчанию, но бывает, что ИИ в корне
00:10:54что-то недопонимает, и тогда я впишу свой ответ, чтобы все прояснить. Не знаю,
00:10:59будет ли такой пример прямо сейчас, но я просто
00:11:03отвечу на все вопросы и вернусь к вам. Необязательно смотреть, как я отвечаю
00:11:07на каждый из 20-25 вопросов — ИИ может копнуть довольно глубоко.
00:11:14Тут нужно немного терпения, но помните: каждый ответ
00:11:19страхует вас от сотен строк кривого кода. Вот, кстати, отличный пример, где я хочу
00:11:24уточнить деталь, отличную от предложенных. Это уже
00:11:30вторая порция вопросов от Claude. «Нужно ли добавить в редактор ссылок превью
00:11:35в виде экрана телефона?» Как в Lovable или Bolt, где справа видно результат,
00:11:39а слева — конструктор. Или сделать редактирование инлайновым? На самом деле я хочу
00:11:44оба варианта. Я могу написать об этом в чат. Он задаст остальные
00:11:49вопросы позже, а сейчас мы обсудим конкретно этот момент. Итак,
00:11:53пишу: «Я хочу инлайновый редактор, но с возможностью переключиться
00:11:58на превью. По сути, нужно три кнопки: только редактор,
00:12:03совмещенный режим и только превью». Отправляю, ИИ переварит это,
00:12:08задаст оставшиеся вопросы, и я продолжу. Итак, Claude закончил
00:12:13с вопросами — их было немало, но вы сами решаете, насколько глубоко заходить.
00:12:18Пора создавать PRD. По финальному резюме спецификации видно,
00:12:23что у ИИ теперь есть четкое понимание того, что именно мы строим,
00:12:28вплоть до места деплоя — я планирую использовать Vercel.
00:12:31Это фантастика. Кажется, неопределенности почти не осталось. Теперь
00:12:36я просто запускаю команду создания PRD. Сохраню его в .claude/prd.md. Вы можете
00:12:43сохранять где угодно и называть как угодно. Я использую команду,
00:12:47о которой говорил раньше, потому что, возвращаясь к нашим «золотым правилам»,
00:12:53одно из главных — автоматизировать всё. Если вы делаете что-то больше двух раз
00:12:59(а я начинал проекты не раз и не два), сделайте это командой. Или навыком —
00:13:03в последних версиях Claude Code команды и навыки объединили, но я все же разделяю их.
00:13:10Команды — это то, что вы вызываете сами, например, /commit. А навыки — это когда агент
00:13:15сам решает прочитать контекст, чтобы понять, как сделать что-то новое. Я создаю именно команду,
00:13:20потому что сам решаю: «Так, на этом этапе диалога я хочу запустить
00:13:27эту команду и получить структурированный PRD». Внутри команды я прописал четкую структуру,
00:13:32все нужные разделы. Так процесс становится воспроизводимым.
00:13:38Суть системы, которую я показываю: вы создаете рабочий метод и
00:13:42используете его снова и снова для новых функций и проектов. Итак,
00:13:48пишу /create_prd, запускаю и вернусь к вам, когда файл будет готов.
00:13:53Что ж, PRD готов, и он получился очень детальным. Это отлично,
00:14:00ведь мы не будем скармливать его агенту целиком для реализации. Вместо этого
00:14:04мы будем строить проект поэтапно, согласно этому PRD. Я не буду
00:14:09сейчас проверять каждое слово на камеру, это скучно, но отмечу,
00:14:14что прочитать его важно. Нужно убедиться, что вы с ИИ на одной волне, иначе
00:14:18позже полезут ошибки в коде. Первое, на что хочу обратить внимание:
00:14:22раздел MVP Scope. Здесь все наши ответы на вопросы обрели форму
00:14:29конкретных требований. Это важно, так как наш предыдущий разговор был лишь
00:14:34неструктурированным контекстом для создания PRD. В итоге останется только PRD.
00:14:40Поэтому всё важное из диалога должно попасть сюда. Также есть раздел
00:14:44Out of Scope — не менее важная часть: то, что мы НЕ будем делать сейчас. Есть полная
00:14:49структура директорий. ИИ уже понимает общее устройство кодовой базы,
00:14:53так как мы уже определились со стеком и архитектурой. Самый важный
00:14:58момент здесь — это фазы работы. Когда мы будем использовать
00:15:04нашу основную команду (о которой поговорим позже), мы сможем четко определять:
00:15:09что уже сделано, а что нужно делать дальше по плану PRD? Этот файл
00:15:13станет ключевым контекстом в начале каждого диалога при создании MVP. К слову,
00:15:19вот раздел, где я расписал фазы. Каждая из них — это отдельная
00:15:24итерация, один PIV-цикл. Сначала база, потом управление ссылками,
00:15:29затем темы. Мы будем планировать каждую фазу отдельно, чтобы
00:15:33не перегружать агента слишком большим объемом работы за раз. Итак,
00:15:38PRD готов, и это был самый большой кусок работы. Мы почти у цели. Следующий
00:15:43шаг — настройка правил. На старте они будут довольно простыми,
00:15:48потому что правила будут эволюционировать вместе с кодовой базой.
00:15:53Я использую Claude Code и ссылаюсь на файлы .agents и agents.md,
00:15:58так как это становится неким универсальным стандартом для глобальных правил.
00:16:04Суть в том, что все ограничения и конвенции, которым ИИ должен
00:16:10следовать всегда, идут в файл глобальных правил. Это такие вещи,
00:16:16как команды запуска приложения, стратегия тестирования или логирования. Что бы мы ни делали,
00:16:20агент всегда должен это видеть. Поэтому создадим сейчас хотя бы черновую версию,
00:16:25чтобы начать. Еще один компонент — папка reference. Для этого
00:16:30можно использовать навыки Claude Code, но папка более универсальна, так как часто
00:16:35нам нужен контекст только для определенных частей приложения. Например,
00:16:40руководство по созданию UI-компонентов нужно только при работе над фронтендом.
00:16:44Мы не валим всё в agents.md, потому что этот файл загружается в контекст
00:16:49при каждом диалоге. Помните: контекст — это святое. Нужно держать его лаконичным,
00:16:55просто указывая агенту на нужные файлы. Мы говорим ему: «Если работаешь
00:17:00над фронтендом — читай этот файл. Если над API — вот этот».
00:17:04По сути, это прогрессивное раскрытие. У нас есть разные уровни контекста,
00:17:09которые агент может открывать для себя со временем, чтобы загружать только то, что ему действительно нужно
00:17:14для текущей задачи. И для этого у меня есть еще одна команда. Опять же, «командифицируйте» все —
00:17:20как у меня есть любимый шаблон для PRD, так и для создания глобальных правил.
00:17:25Для начала мы изучим то, что уже есть в кодовой базе.
00:17:30Я сделал это так, чтобы метод работал и для существующих кодовых баз, и для новых. По сути,
00:17:35все, что он будет исследовать — это PRD. Он определит наш стек технологий, архитектуру,
00:17:38проведет веб-поиск стратегий тестирования и логирования, а затем объединит все это
00:17:43с моими указаниями для создания глобальных правил. У меня здесь есть четкая структура.
00:17:50Все будет основано на моем шаблоне. Я тоже быстро его покажу,
00:17:55потому что это шаблон, который я обожаю использовать для всех своих глобальных правил. Вы видите,
00:17:59что все пункты здесь важны для агента в любом случае: наш стек технологий,
00:18:04команды для запуска и тестирования, структура проекта. То есть, по сути, это индекс
00:18:08нашей кодовой базы, архитектура, паттерны кода, такие как конвенции именования, стратегии
00:18:13тестирования и валидации. В целом все довольно просто, но сначала мы создадим это,
00:18:17а затем я дам вам пару примеров справочных документов, таких как наш дополнительный контекст по запросу.
00:18:22Зайдем в Claude, и прямо в том же диалоге, где я создавал PRD,
00:18:27я просто введу «создать правила», потому что могу использовать весь этот разговор как контекст
00:18:33для помощи. Он сразу понимает: «Окей, вот наш PRD, вот наш стек технологий» и все в таком роде.
00:18:38Итак, команда создания правил завершена, и теперь у нас есть глобальные правила. Я их уже открыл.
00:18:43Тут все стандартно: стек технологий, команды (например, мы используем Drizzle ORM для базы данных),
00:18:47структура проекта, архитектура, паттерны кода.
00:18:52Ради краткости я не особо настраиваю их под себя и не добавляю много своих мыслей,
00:18:57но в зависимости от вашей технической подготовки, сейчас самое время убедиться,
00:19:03что ограничения, конвенции и паттерны кода действительно соответствуют тому, как вы хотите
00:19:07создавать свои кодовые базы. Вы можете потратить на это много времени, если хотите.
00:19:12Я же сосредоточусь на концепциях высокого уровня. Также мне нужно было провести веб-исследование
00:19:16лучших практик по созданию фронтенд-компонентов и API-эндпоинтов.
00:19:21И на основе этого я создал контекст по запросу. Опять же,
00:19:24при желании это могут быть навыки кодирования Claude. Вернемся к глобальным правилам,
00:19:29прокрутим вниз до раздела контекста по запросу — вот он. При работе над фронтенд-компонентами
00:19:34читай этот файл. При работе над API-маршрутами читай этот файл. То есть изначально загружается
00:19:40только claude.md, а остальное он решит подтянуть по мере необходимости. По моему опыту,
00:19:45он отлично справляется с ссылками на них, особенно если глобальные правила лаконичны. Смотрите,
00:19:50тут даже нет 240 строк — всего 233 строки в глобальных правилах. Зато у нас есть api.md и
00:19:58components.md. Они намного больше, потому что когда мы работаем над конкретной задачей,
00:20:03вполне допустимо подгрузить больше информации, чтобы у кодинг-агента были четкие инструкции.
00:20:08Снова обратимся к нашей диаграмме: правила — это *как* мы хотим строить систему.
00:20:14PRD — это *что именно* мы будем строить. И учитывая оба этих аспекта,
00:20:19последнее, о чем я хочу поговорить — это команды, особенно команда «prime».
00:20:23Затем мы перейдем к планированию первой фазы и написанию кода. На данный момент
00:20:29у нас готов начальный уровень ИИ: PRD, правила и те общие команды, которые я добавил
00:20:34и которые вы можете свободно использовать. Мы переходим к реализации, но есть нюанс.
00:20:39В начале каждого нового диалога с ИИ-помощником по программированию,
00:20:44нам нужно, чтобы он вошел в курс дела относительно кодовой базы. Что мы строим? Что дальше?
00:20:50Вот здесь и вступает в игру команда /prime. Мы будем запускать ее в начале
00:20:56каждой новой сессии. Это управляемый процесс исследования кодовой базы,
00:21:02помогающий агенту сформировать ментальную модель и подготовиться к внедрению следующей фичи.
00:21:06Мы заставим его прочитать документацию и изучить структуру. Для этого он может использовать субагентов.
00:21:11Проверка лога git — еще одна вещь, о которой я подробнее расскажу чуть позже,” —
00:21:15использование лога git как долгосрочной памяти. Так он видит эволюцию кодовой базы во времени,
00:21:21что поможет ему принимать решения о том, что строить дальше. После этой команды
00:21:26он выдаст нам свой отчет о понимании кодовой базы. Так мы сможем подтвердить,
00:21:31что он в курсе дел, и приступить к созданию следующей вещи. Не будем вдаваться
00:21:36в излишние детали команды prime, но мы выполняем операции с git, чтобы использовать историю.
00:21:40Затем мы читаем основные файлы и определяем все, на что нужно обратить особое внимание,
00:21:45например, основные точки входа в приложение. И этот итоговый отчет
00:21:49позволяет нам проверить его понимание. Мы можем со временем развивать это,
00:21:55подстраивая под конкретный проект. Приведу один маленький пример: для изучения основной
00:22:01документации я могу сказать: «Прочитай миграции Drizzle, чтобы понять схему базы данных».
00:22:08Автодополнение даже сработало — он точно понял, к чему я клоню. И когда вы начнете
00:22:12понимать, на чем именно должен фокусироваться агент в данной кодовой базе,
00:22:16например, на документации в папке reference, мы можем добавить это сюда.
00:22:20Теперь я перейду в Claude, но начну совершенно новый диалог,
00:22:25потому что сейчас мы приступим к нашему первому циклу PIV. Я объясню весь цикл чуть позже,
00:22:30но смотрите: я просто запускаю Prime. И это будет началом
00:22:34моего разговора, прежде чем я начну что-либо исследовать. В данном случае он поймет:
00:22:39«Окей, это новый проект. Давай проверим PRD». И он порекомендует:
00:22:44«Давай сначала сделаем первую фазу — создадим фундамент проекта».
00:22:49Prime завершен. Вот обзор проекта: конструктор страниц «ссылка в профиле». Текущее состояние —
00:22:54пустой репозиторий только с документацией. Я делал тестовую сборку ранее, поэтому он так пишет,
00:22:59но сейчас я все очистил. Затем он вытащил первую фазу «Фундамент»
00:23:04из нашего PRD. Именно это он рекомендует построить. И это как раз то,
00:23:10чего я добиваюсь. Я хочу, чтобы он брал фазы из PRD по одной. Так мы получаем
00:23:14гранулярную реализацию циклов PIV, к обсуждению которых мы сейчас и перейдем.
00:23:20PIV — это сокращение от Plan, Implement, Validate (Планируй, Реализуй, Проверяй). Мы берем
00:23:29сфокусированную задачу, обычно фазу из PRD, и проводим ее через этот процесс. Создаем структурный план
00:23:34того, за что собираемся взяться. Этот процесс на самом деле очень похож на
00:23:38создание PRD. Затем мы переходим к реализации. Наша цель здесь — делегировать
00:23:44все написание кода агенту, а после провести валидацию. Я вкратце опишу,
00:23:50как выглядит этот процесс, а затем мы увидим его в действии. Во-первых, на этапе
00:23:55планирования у нас есть два уровня: высокоуровневое планирование проекта (то, что
00:24:00мы уже сделали, создав PRD и правила) и планирование конкретной задачи.
00:24:07Как я уже упоминал, они похожи. Создание структурного плана во многом напоминает
00:24:13создание структурированного PRD. Главное отличие в том, что структурный план очень сфокусирован
00:24:19на отдельной фиче и всех задачах, связанных с ней. Теперь мы опускаемся до уровня
00:24:24кода. Мы уже не так высоко, но все равно начнем с очень неструктурированного
00:24:30разговора. Я называю это «вайб-планированием», где мы исследуем общие идеи.
00:24:35Какова архитектура того, что мы строим, запуск субагентов для анализа кодовой базы
00:24:40и документации, и просто выяснение конкретных задач, которые нужно выполнить для этой фичи.
00:24:44Мы ведем этот диалог (я покажу пример), а затем превращаем его
00:24:50в структурированный документ, как и в случае с PRD. Цель — создать детальный план
00:24:56действий для ИИ-помощника на основе нашего разговора. Разговор — это часть
00:25:02нашего контекста, но здесь есть очень специфические разделы, которые я хочу видеть в плане:
00:25:09цель и критерии успеха фичи, любая документация, на которую мы хотим сослаться
00:25:13(возможно, найденная субагентом), список задач, который может быть детализирован
00:25:18вплоть до создания и обновления конкретных файлов. И, пожалуй, самая важная часть
00:25:23всего плана — это стратегия валидации. Это похоже на разработку через тестирование (TDD),
00:25:27где мы хотим четко определить, как будем проверять фичу,
00:25:33еще до написания первой строки кода. Это заставляет и нас, и агента очень четко
00:25:38сформулировать критерии успеха. Итак, мы создаем структурный план и активно
00:25:45участвуем в этом, но затем делегируем все кодирование самому агенту. Это не просто
00:25:51«вайб-кодинг». Единственная причина, по которой я доверяю агенту, но проверяю его —
00:25:56в том, что реализация зажата между планированием и валидацией, где я полноценно участвую.
00:26:01Мы заставим агента проверять свою работу с помощью юнит-тестов, интеграционных
00:26:06и сквозных (E2E) тестов. Мы это увидим. Но затем я сам проведу ревью кода
00:26:11и вручную протестирую приложение. Я запущу его сам, пройду путь пользователя,
00:26:16чтобы убедиться, что все работает хорошо, прежде чем делать коммит
00:26:20и отправлять это в продакшен или на стейджинг. Важно то, что
00:26:26между планированием и реализацией я сбрасываю контекст. Это одно из золотых правил.
00:26:32Контекст драгоценен. У нас был долгий и подробный разговор о том, как внедрить фичу.
00:26:38И я хочу, чтобы структурный план, который я создал, содержал весь контекст,
00:26:44необходимый агенту для выполнения работы. Тогда я смогу начать «чистый» диалог,
00:26:50где план — единственное, что я отправляю, так как в нем уже есть все ссылки на документацию
00:26:55и полный список задач. Мы знаем, что делать и как проверять. Таким образом,
00:27:00мы можем просто отсечь лишнее и перейти к исполнению, сохраняя фокус. Мы не хотим,
00:27:06чтобы лишний контекст раздувал диалог, когда мы переходим к написанию самого кода.
00:27:12Что ж, давайте приступим к нашему первому циклу PIV. Это будет намного проще,
00:27:16чем вы думаете, потому что мы действительно пожинаем плоды планирования,
00:27:22сделанного заранее. Мы на одной волне с агентом и уверены, что он понимает,
00:27:27что именно мы хотим построить. Так что для каждой из этих фаз не потребуется много планирования,
00:27:31по крайней мере, поначалу. Возвращаемся сюда: мы закончили prime, мы на одной волне с агентом.
00:27:36Я дал ему простой промпт: «Да, фаза 1 выглядит отлично. Просто подтверди мне,
00:27:40что именно мы собираемся строить». Обычно в циклах PIV после первого раза все детальнее,
00:27:44например: «Давай изучим кодовую базу, чтобы понять, как именно это реализовать».
00:27:49Но здесь все просто. Выглядит хорошо. И теперь помните — «командифицируйте» все.
00:27:53Я хочу превратить этот разговор и идею первой фазы в структурный план
00:27:59со списком задач и валидацией. Для этого у меня есть еще одна команда /plan-feature.
00:28:04Я отправляю ее, и теперь планирование фичи, как и создание PRD, само по себе
00:28:10содержит концепцию структурного плана. Я покажу вам и эту команду.
00:28:17Откроем /plan-feature. Она принимает необязательный аргумент, где я могу указать,
00:28:23что именно хочу построить. В данном случае я использую историю диалога, так что он уже в курсе.
00:28:28Мы проходим через поэтапный процесс: понимание фичи, погружение в кодовую базу (что,
00:28:33опять же, больше применимо к будущим циклам PIV), большой объем исследований,
00:28:38подтягивание документации, чтобы перед исполнением у нас был богатый контекст. А вот
00:28:44перед вами шаблон. Мы описываем постановку проблемы, контекст или ссылки,
00:28:49план реализации со списком задач и, конечно,
00:28:55стратегию тестирования. Мы определяем валидацию заранее. После создания плана
00:29:00мы его, конечно, проверяем. Мы добиваемся максимальной конкретики: пошагово описываем,
00:29:05как именно нужно валидировать приложение. Я использую навык Vercel agent browser CLI,
00:29:11о котором я делал видео (ссылка будет здесь). Мы внедрим полную автоматизацию браузера.
00:29:17Агент сам поднимет бэкенд и фронтенд, запустит миграции базы данных,
00:29:21пройдет по шагам, создаст свое дерево ссылок и просто убедится,
00:29:26что все работает именно так, как ожидает пользователь. Звучит захватывающе,
00:29:31но валидация здесь будет очень подробной, чтобы к моменту передачи контроля обратно нам,
00:29:36мы были уверены в реализации. Мы все равно проведем свою проверку, но работы будет меньше.
00:29:42Наш план создан. Давайте взглянем. Я немного проверил его за кадром,
00:29:47покажу это чуть позже. Обычно приходится сделать несколько итераций,
00:29:52чтобы убедиться, что его понимание первой фазы совпадает с тем, что написано в PRD,
00:29:56и с тем, что вы реально хотите построить. Советую вам пройти по всем разделам.
00:30:01Вот наш план реализации со списком задач. Он очень детальный, и это хорошо.
00:30:05Когда мы фокусируемся на одной фиче, нужно быть конкретными. А вот наша пирамида валидации:
00:30:10проверка типов, линтинг и юнит-тестирование. Также мы очень детально описали
00:30:15E2E-тесты и все пользовательские сценарии, которые агент должен пройти.
00:30:20Так мы будем уверены в результате. Поначалу он справлялся с этим не очень хорошо,
00:30:24поэтому я добавил уточняющий промпт — просто как пример того, как можно
00:30:29дорабатывать и уточнять план перед отправкой на реализацию.
00:30:34И еще один важный момент (обещаю, скоро перейдем к коду), это действительно ценно.
00:30:38Обычно кодинг-агенты не очень ладят с переменными окружения. Они могут запутаться.
00:30:43Если не настроить их до начала реализации, агент может наделать мок-тестов и сказать,
00:30:48что все валидно, хотя это не так — и это очень раздражает. Поэтому,
00:30:53параллельно с планированием, я обычно создаю файл .env.example и заставляю его посмотреть туда.
00:30:57Так он узнает все нужные переменные окружения, а затем я настраиваю их и у себя.
00:31:03Конечно, я не покажу этот файл, так как там мои секреты для базы данных и прочего.
00:31:09Но раз все уже настроено, мы можем пролететь через всю реализацию, и он не просто
00:31:13напишет код, но и запустит миграции, поднимет бэкенд и фронтенд,
00:31:19использует Vercel agent browser CLI для тестов. И ему не придется прерываться,
00:31:23чтобы я прописал переменные окружения. Сцена подготовлена идеально, мы переходим
00:31:29к реализации, и я доволен планом. Теперь помните: сброс контекста, потому что он драгоценен.
00:31:34Я в совершенно новом окне контекста, где использую команду execute
00:31:40с единственным параметром — ссылкой на план. Это все, что ему теперь нужно для работы.
00:31:45Я прервусь и вернусь, когда он все закончит. Мы полностью делегируем написание кода агенту,
00:31:51 пожиная плоды усилий, вложенных в планирование. Каждый цикл PIV теперь
00:31:56будет проходить очень быстро благодаря проделанной работе. Итак, реализация завершена.
00:32:01По скриншотам видно, что он провел полные E2E-тесты. Можно быть вполне уверенным
00:32:06в результате, так как агент уже обо всем позаботился, но человеческая валидация все еще важна.
00:32:11Мы должны «доверять, но проверять». Ревью кода — процесс довольно кропотливый,
00:32:16поэтому сейчас я этого делать не буду, но если вы технически подкованы,
00:32:21это обязательно нужно делать. Но что я сделаю, так это протестирую приложение вживую вместе с вами.
00:32:26За кадром я только создал аккаунт, чтобы убедиться, что базовая аутентификация работает,
00:32:30но больше ничего не трогал. И посмотрите на это — это круто. Все уже выглядит очень мило.
00:32:35Я могу установить отображаемое имя, написать био, например: «Крутой ИИ-разработчик».
00:32:39Могу поставить URL аватара — я как раз загрузил картинку на Imgur. Выглядит отлично.
00:32:43Могу добавить ссылки, например, на YouTube: https [youtube.com/@colemedine](https://www.google.com/search?q=https://youtube.com/%40colemedine). Хорошо.
00:32:49Добавлю еще ссылку на LinkedIn. У меня сейчас нет под рукой точного URL, так что просто напишу
00:32:55linkedin.com, неважно. И добавлю еще одну — X.com. Очень круто.
00:32:59Я могу перетаскивать их, меняя порядок, и это сразу отображается в превью.
00:33:08Я могу смотреть только редактор или настраивать предпросмотр. Тема пока выглядит не очень —
00:33:11просто белая, но, по-моему, темы появятся в следующих фазах, а сейчас мы закладываем фундамент.
00:33:18Многое еще не идеально, но для отправной точки это выглядит чрезвычайно хорошо.
00:33:24Я нажимаю «Сохранить». Так, загрузим API-эндпоинты, это работает на localhost.
00:33:28Вот, изменения успешно сохранены. Могу обновить страницу, и все останется на месте.
00:33:32Это потрясающе. Все выглядит очень здорово. Теперь, когда у нас есть готовый фундамент,
00:33:37я хочу быстро поговорить о сообщении коммита. У меня есть еще одна команда /commit,
00:33:42она совсем простая. Вы можете сделать ее детальнее, но суть в том, чтобы дать агенту инструкции,
00:33:46как оформлять git-сообщения, потому что мы будем использовать их как долгосрочную память.
00:33:51Возвращаясь к диаграмме: ваша история коммитов — это ваша долгосрочная память.
00:33:57Если мы стандартизируем сообщения (для этого и нужна команда /commit),
00:34:01то агент во время фазы prime сможет изучить git log, чтобы увидеть историю недавних разработок,
00:34:06что подскажет ему следующие шаги и паттерны, которым нужно следовать. В этом сила коммитов.
00:34:11на диаграмму: это одно из «золотых правил». История коммитов — это ваша
00:34:17долгосрочная память. Если мы стандартизируем сообщения и используем команду /commit для
00:34:22многократного использования, то агент при подготовке сможет изучить лог Git, чтобы увидеть
00:34:28историю недавних разработок. Это подскажет ему следующие шаги и паттерны,
00:34:32которым нужно следовать. В этом и заключается сила таких сообщений. Я введу /commit,
00:34:38хотя мог бы запустить git commit сам — это просто, но так сообщения
00:34:43всегда будут единообразными. В данном случае коммитить нечего,
00:34:48так как я уже сделал это за кадром, но важно выполнять это после каждого
00:34:53этапа реализации. Еще один критически важный момент после того, как заложен
00:34:58фундамент проекта, — это настройка системы регрессионного тестирования. Нужно быть
00:35:04уверенными, что при прохождении будущих циклов PIV (когда мы раз за разом повторяем этот процесс
00:35:09для всех нужных функций), старый код не сломается. Эту тему я
00:35:14подробнее разберу в другом видео — все стратегии по внедрению подобной
00:35:19тестовой среды своими силами. По сути, вы говорите агенту: «То, что
00:35:25у нас есть — отлично, но я хочу, чтобы в Aqua Voice ты перечислил все
00:35:31проведенные сквозные тесты и оформил их в виде команды. Так я смогу запустить их позже,
00:35:36когда добавлю другие функции, и убедиться, что все созданное ранее по-прежнему
00:35:41работает». Как-то так. Опять же, не буду сейчас углубляться в детали.
00:35:46Настройка и создание тестовой среды занимают время, но именно так обеспечивается
00:35:50стабильность приложения при его дальнейшем расширении. Создание и поддержка
00:35:55такой системы требуют много усилий, так как ее нужно постоянно обновлять.
00:36:00Существуют готовые решения, которые берут это на себя, и они очень эффективны.
00:36:05Одно из них — QA tech. У них есть ИИ-агенты для тестирования, которые развиваются вместе с вашим кодом.
00:36:11По мере добавления новых функций они добавляют новые тест-кейсы, чтобы гарантировать,
00:36:16что ваше приложение работает исправно в процессе разработки. Я
00:36:22быстро покажу пример. Начать очень просто: заходите в QA tech,
00:36:26у них есть бесплатный тариф для пробы. Создаю проект,
00:36:30и затем просто вставляю URL, который нужно протестировать. Я взял это приложение,
00:36:35сделал коммит, запушил на GitHub и за минуту развернул на Vercel — это
00:36:40лучшее место для бесплатного хостинга, особенно для Next.js. Захожу в свой проект
00:36:45и вставляю этот URL. Потребуется немного времени на создание проекта и анализ
00:36:50вашего кода. После этого мы можем сказать: «Мне нужна хорошая настройка тестов для сайта.
00:36:55Помоги создать первые 3–5 тест-кейсов». Это похоже на работу в bolt.new или Lovable,
00:36:59где вы просто даете промпт для настройки тестового набора вашего
00:37:04проекта. Это то, что они рекомендуют для начала. Отправляю запрос.
00:37:08Это круто, потому что сервис буквально просканирует ваш сайт, пройдется по нему,
00:37:12при этом вам не нужно управлять инфраструктурой. Он анализирует сайт и предлагает
00:37:16тест-кейсы. Вернусь, когда он закончит. Пока идет процесс, хочу быстро показать,
00:37:21что он просканировал мой сайт всего за пару минут. И еще важный
00:37:25момент: автоматике нужен способ войти в систему под учетной записью.
00:37:29У них есть поле для ввода логина и пароля, которые будут храниться
00:37:34безопасно. У меня есть тестовый аккаунт, я введу данные и сохраню их. Сервис
00:37:38использует их, чтобы зайти на сайт, детально изучить его и понять все пути пользователя,
00:37:43которые мы хотим протестировать. И вот, он сгенерировал пачку тест-кейсов,
00:37:48мы можем зайти в любой из них и увидеть точный сценарий. Теперь
00:37:53у нас настроены тесты. ИИ-агенты QA tech будут со временем дорабатывать эти
00:37:59кейсы, чтобы они охватывали все изменения в коде. По мере добавления
00:38:04новых функций это становится мега-полезным. Опять же, мы можем создать свою
00:38:09систему команд для этого, но мне нравится платформа, которая делает все за меня.
00:38:14Там «под капотом» есть агенты, с которыми можно чатиться по вопросам тестирования,
00:38:19чтобы убедиться в полной проверке на регрессии. И если что-то
00:38:24сломается, я могу зайти и сказать: «Сейчас в приложении баг,
00:38:28создай тест, который должен провалиться. Я исправлю проблему, и тогда тест
00:38:33должен пройти». Это подводит нас к последнему золотому правилу: мышление в стиле эволюции системы.
00:38:40Когда мы сталкиваемся с багом в коде, важно не просто его исправить,
00:38:46но и подумать, что изменить в нашем ИИ-слое, чтобы это не повторилось. Возможно,
00:38:51нужно уточнить стайл-гайд и правила или создать новый контекст по запросу.
00:38:57Может, нужно добавить больше сквозных тестов в наши команды и рабочие процессы —
00:39:02сделать всё, чтобы избежать этой проблемы впредь. Также мы можем
00:39:06использовать QA tech или свою систему команд, чтобы добавить тест, гарантирующий,
00:39:12что этот баг больше не появится. Сила этого подхода, хоть он и требует
00:39:16времени, в том, что агент становится более надежным, развиваясь
00:39:21вместе с проектом. Мы ведем три процесса параллельно: создавая
00:39:26продукт, мы развиваем базу тестов, кодовую базу и ИИ-слой. Эффект от этого
00:39:32со временем растет в геометрической прогрессии. Вернемся в Cloud Code, покажу простой пример.
00:39:37За кадром я немного поработал над стилем сайта.
00:39:43Если вы вернетесь к началу видео, то увидите, что я забыл уточнить детали
00:39:47стиля — как именно должен выглядеть сайт. Cloud Code сделал все
00:39:51на свое усмотрение, и получилось не очень. Мне пришлось это исправлять. И
00:39:56вот что я могу сделать: «Слушай, мне сначала не понравился стиль фронтенда.
00:40:01В нашем ИИ-слое явно не хватает правил и контекста для
00:40:06руководства по стилю. Проведи мета-анализ: ничего не меняй в коде,
00:40:10но подумай, что нам добавить или обновить в правилах или контексте,
00:40:15чтобы стили были единообразными при создании аналитики и
00:40:20других страниц этого приложения в будущем».
00:40:25Важно, что я прошу его пока ничего не менять,
00:40:29так как я хочу полностью контролировать изменения в ИИ-слое, тогда как работу
00:40:34над кодом я стараюсь максимально делегировать агенту. Я прошу его рассуждать,
00:40:39но точечные изменения в настройки вношу сам. Как видите,
00:40:44он рекомендует создать файл style.md в папке reference — еще один
00:40:50элемент контекста по запросу. Он будет дополнять components.md. Тот файл
00:40:54отвечает за структуру, а style.md опишет визуальную часть: как работать
00:40:58с Tailwind CSS и, вероятно, Shadcn. Я не буду сейчас полностью
00:41:03это внедрять и всё исправлять, просто хотел показать на примере:
00:41:06любой баг или нестыковка в коде — это возможность
00:41:11улучшить ИИ-слой. Так мы всё больше синхронизируемся с нашим ИИ-кодером
00:41:16в рамках конкретного проекта по мере его развития.
00:41:20И это, друзья мои, самая эффективная часть процесса, я приберег лучшее
00:41:26напоследок. Вот и всё. Это действительно простой способ получать стабильные
00:41:32результаты от ИИ-агентов при запуске новых проектов. Ведь после
00:41:35эволюции системы мы возвращаемся в начало и идем на новые круги PIV,
00:41:40реализуя все фазы из PRD и добавляя функции, пока не получим
00:41:45минимально жизнеспособный продукт. Далее мы перейдем к «Brownfield» разработке
00:41:49(работе с существующим кодом), о чем будут мои следующие видео. Если вам
00:41:54это интересно и вы хотите изучить мою библиотеку команд и правил,
00:41:59увидеть реальную эволюцию системы и погрузиться в детали — обязательно
00:42:04зацените курс по агентному программированию в сообществе Dynamics. Ссылка будет
00:42:08в описании и в закрепленном комментарии. На этом у меня всё.
00:42:13Если видео было полезным и вы ждете продолжения про «Brownfield»
00:42:17разработку, буду благодарен за лайк и подписку. Увидимся
00:42:22в следующем видео.