вайбкодинг с нуля за 17 минут. пример разработки реального проекта с ИИ transcript

Всем привет. Сегодня хотел рассказать о полноценном цикле вайп-кодинга реального приложения от самого нуля до реального результата. В этом видео вы увидите построение реального веб-приложения и пошаговое объяснение каждого пункта, который вы видите сейчас на экране. По факту то, что вы сейчас видите, уже есть построенный реальный цикл вайб-кодинга. А всё, что вам нужно - это просто применить все эти знания в, э, построении своих рабочих проектов. Давайте по порядку. А, итак, почему короткий промт у нас не работает? А, всё очень просто, потому что агент не понимает, что ему нужно сделать на самом деле. Он может принимать решение за вас, и он Но в результате вы получаете посредственность. Вы получаете то, чего, возможно, вы не хотели. Вы получаете баги, вы получаете ошибки в коде, вы получаете некрасивый визуал. Это всё то, что нам не нужно. А нужно нам непосредственно дать агенту знания о том, что мы хотим построить. И как мы это сделаем? Мы сделаем это с помощью опроса. То есть анатомия запроса. А как мы должны правильно строить промт? Что у нас должно быть в промте? У нас должна быть одна чёткая цель. К чему мы стремимся? Что мы строим? Зачем мы это строим? То есть какой результат мы хотим видеть и для кого этот результат. Критерии - это непосредственно важнейшая часть, потому что без них агент сам решает, как он закончил и когда он закончил. А с критериями он может валидировать собственную работу, и мы можем валидировать его работу. Границы - это то, что агент может трогать в проекте, что он должен трогать и чего он трогать категорически не может. Это то, что должен выстраивать каждый уважающийся вайпкозер в своём проекте. И проверка - это то, как агент проверяет свои Это то, как агент проверяет свою работу и то, как мы будем проверять его работу непосредственно. Так, давайте дальше. После того, как мы сформировали промт, полноценный запрос, мы проводим опрос. То есть, что это такое? Это когда агент задаёт вам уточняющие вопросы, потому что в любом случае ни один промт никогда не может затронуть все грани, все аспекты как бы в вашего потенциального будущего проекта. И для этого придумали опрос. Опрос - это функция, которая доступна в клодкоде по запросу. Либо же вы можете сами применить. Опрос - это функция, которая позволяет вашему промту обрастать мясом и многогранностью. То есть он перестаёт быть плоским, он обретает объём. И это очень важно в вайпкодинге любого проекта, потому что мы никогда не можем учесть все нюансы и все аспекты, которые потенциально могут затронуть наш проект. Поэтому опрос всегда очень важная часть при построении проекта с нуля. Далее, после того, как опрос был проведён, у нас сформировался один большой масштабный промт, который затрагивает все аспекты нашего будущего потенциального приложения. И что нам нужно сделать? Нам нужно составить план, то есть договориться с нашим агентом до кода, потому что план меняет всё. Потому что без плана всё, что мы делали до этого, может потерять смысл. Итак, как нам строить план? Из чего он состоит? План - это, в первую очередь, цель, это шаги. То, что мы уже до этого, то, что мы до этого сформировали в виде опроса, теперь мы формируем в виде шагов, точнее, формирует наш агент. Какие риски закладываются в разработку проекта и что сознательно мы откладываем на потом, какие-то, возможно, э не первостепенные задачи и так далее. Итак, после того, как план сформирован, мы должны сформировать спецификацию нашего проекта. Спецификация - это память, что где и как находится в вашем проекте, как что работает. Потому что без спецификации агент просто теряет суть вашего проекта, теряет смысл. Ему каждый раз приходится пересматривать каждый файл, каждый тест. И это очень-очень сильно забивает контекстное окно. Также агент из-за этого начинает галлюцинировать. Он перестаёт понимать суть задачи, которую он вообще выполняет. Спецификация не позволяет ему этого сделать. После того, как вы сформировали план, вы всегда должны сформировать спецификацию. Она является гарантом качества. Это документ, который меняется вместе с вашим проектом и показывает все изменения, учитывает их, чтобы агент не забывал, что вообще и как работает в проекте. Дальше у нас идёт Git. Тоже одна из важнейших частей в вайп-кодинге.

I - это довольно важная часть процесса разработки, которую многие откладывают почему-то и не хотят в ней разбираться. Хотя гит это ничего сложного в себе не несёт. Что по факту такое Git? Git - это система управления версиями проекта. То есть, когда вы создаёте рабочую папку э какого-либо своего проекта, он имеет сразу в себе меa ветку. То есть это основная версия вашего проекта. То, что будет видеть конечный пользователь, то, что будете видеть вы. И помимо основной версии вашего проекта, вы можете создавать дополнительные ветки, которые будут идти параллельно вашей основной версии проекта, которые не будут применяться, пока вы этого не захотите. Для этого и нужен нам непосредственно комит. То есть мы создаём отдельную ветку нашего проекта, работаем в ней, применяем в ней какие-либо изменения так, чтобы основная ветка проекта не пострадала или какую-то нерабочую, чтобы мы не загрузили в нашу рабочую версию проект, чтобы мы не загрузили в наш рабочий проект какой-то баг, какую-то, чтобы мы не загрузили в нашу рабочую версию проекта какой-то баг, а протестировали его в копии проекта и только после этого смёржили его в основную версию. То есть у нас есть определённый порядок работы. Мы создаём ответ ветки дополнительную копию проекта, работаем в ней. Далее смотрим div, что у нас поменялось, то есть тестируем наш проект. После чего мы можем сохранить нашу новую версию проекта, то есть Commit и Merch. Это два аспекта работы с Gitwork 3. Так, давайте поподробнее. То есть Git в работе с агентами выглядит так. У нас есть чистое дерево, у нас есть ветка, которую мы уделяем на задачу, у нас есть агент, который работает в этой ветке. Далее мы смотрим, что агент сделал в этой ветке. Проводим тесты и коммитим данную ветку. То есть она идёт параллельно параллельно нашему мейну. И для того, чтобы применить его в проект, мы должны закоммитить, то есть сохранить версию этой ветки и далее смёржить. Ш - это команда, которая применяет изменения из одной ветки в другую и объединяет их. То есть вот как это выглядит на практике. У нас есть папка проекта основная, и есть несколько копий проекта, в которые параллельно работают несколько агентов, которого у каждого есть своя копия, то есть GitWork 3. Они не правят одни файлы одновременно, не видят чужие, и благодаря Gitwork 3 агенты могут работать параллельно и не боятся за изменение одних и тех же файлов. Итак, давайте дальше. какой режим для какой режим выбрать для разработки. То есть это тоже немаловажная часть на самом деле, потому что если у нас, например, есть маленькая задача, суть которой понятна, например, изменить какой-то цвет на сайте лендинге или поменять какую-то одну кнопку в приложении или же исправить условно одну ошибку с авторизацией. То есть это маленькая понятная задача, для которой не требуется составления спецификации, не требуется составление огромного промта. Это мы всегда делаем с соловоркером. Он это сделает и быстрее, и качественнее, чем любой другой режим. Если задача является какой-то масштабной, мы не понимаем, как составить архитектуру этой задачи, а она является какой-то объёмной и требует подхода с разных сторон, мы можем использовать Fusion Mode. Что такое Fusion Mode, вкратце, я про него сниму отдельный ролик, но вообще Fusion - это объединение нескольких и моделей в одном. То есть у нас есть, допустим, Fable 5.1 GPT Astra, и мы объединяем результаты работы двух этих агентов, а, которые работают параллельно над одной и той же задачей. То есть мы объединяем их и на выходе получаем намного-нанамного продуманнее и качественнее результат, чем если бы каждая из них работала отдельно в соло. То есть для таких задач мы используем Fusion. Я, например, его использую очень часто для составления каких-то, опять же спецификаций или масштабных планов для своих дальнейших проектов, потому что он очень хорошо подходит к вопросу составления именно архитектуры со всех сторон, потому что, э, я использую лучшие модели для такого, и это непосредственно даёт очень хорошие плоды. Так далее. Если у нас же задача делится на независимые части в разных файлах, то мы можем использовать оркестратор. То есть, когда у нас есть полноценно составленный план, и мы понимаем конкретно, какие части в этом плане какой агент может выполнить, мы отдаём эту задачу оркестратору, который будет контролировать процесс и распределить задачу между воркерами. А если же задача, например, находится в одном каком-то месте, то есть мы делаем какую-то одну фичу, но она довольно масштабная, мы можем использовать роагентов, о котором я рассказывал в предыдущем видео. Можете, можете посмотреть на моём канале видео называется: "Что такое SWARМ, как с ним работать, там рассказал". Это режим а Роя, в котором агенты работают в одной ветке и работают над одной задачей. Вот тут опять же описано, можете посмотреть каждый из режимов, как они работают, какие у них есть минусы, плюсы и когда их использовать. Ну а теперь давайте перейдём к вайпкодингу полноценного реального проекта. Посмотрим, как это делается на практике, и применим каждый из шагов, о которых я рассказал в этом видео, на деле. Итак, я вот составил уже такой небольшой промт. А значит, сделать я хочу небольшое веб-приложение для фрилансера, где он сможет заполнить форму и получить коммерческое предложение, которое можно распечатать. То есть вот можете посмотреть, я отдам, значит, эту задачу фейблу пятому на хай эфферте. И давайте сразу включим для него режим опроса. Поехали. Сейчас, а, сейчас произойдёт вот что. А Fable прочитает промт и задаст нам несколько уточняющих вопросов. Итак, вот Fable закончил свою работу. Работал он, на самом деле, недолго. И сейчас мы сможем сформировать а наш масштабный пром. Давайте ответим на каждый из вопросов. Итак, я ответил на все вопросы. Сейчас у нас Fable сформирует наш промт, и мы перейдём к следующему шагу, планированию.

FA задал ещё нам уточнеющие вопросы. Давайте на них ответим. Так, Fable у нас закончил. Давайте теперь составим план. Напишем составь MDФай по опросу. Итак, вот теперь у нас план готов. Давайте скопируем его и непосредственно попросим а нашего агента составь спецификацию для по этому плану. Сейчас у нас получается составится спека в виде MD файла, которую мы уже в свою очередь отдадим оркестратору. Итак, агент у нас составил спецификацию. Вот можем её тут посмотреть в формате просмотра, изучить, что здесь написано. Но я в целом доверяю всему, что он пишет, так что, думаю, сейчас просто отдадим спект оркестратору. Так, давайте начнём на и выберем режим оркестратора. Дадим, наверное, кодексу GPT Astra на хайризонинге оркестрировать у нас. А как агентов мы выберем, наверное, opus на хай рининге и интегратор у нас тоже, наверное, будет клод OPUS high. То есть, что это у нас такое? планировщик. Это у нас есть непосредственный оркестратор, который сейчас распределит задачи между агентами и будет контролировать каждое выполнение, то есть составит критерии приёмки и будет наблюдать за тем, как они выполняют, и будет контролировать, как бы исполнять и будет контролировать, исправлять и направлять этих агентов, если будет нужно. А интегратор у нас - это непосредственно аа модель, которая объединит результаты всех трёх воркеров. То есть у нас каждый workркер будет работать в своей workт, а, в своей копии проекта. И интегратор нужен для того, чтобы, а, как бы объединить все изменения проекта, если там будут какие-то несостыковки, какие-то сломанные файлы, которые будут не стакаться друг с другом. Для этого у нас непосредственно есть отдельная модель, которая разрешает данные конфликты. Итак, давай напишем ему Итак, давайте напишем а нашему оркестратору. А, воплоти проект из MD. файла в жизнь. И всё. В целом отдаём наш средственный оркестратор. Он сейчас увидит, что у нас в этой же ветке есть а файл спецификации и распределит задачи между воркерами. Вот. То есть у нас он отображается в этой же ветке. Сейчас Astra прочитает файл и даст задание воркерам, распределит между ними обязанности, сформирует критерии приёмки и будет контролировать каждого воркера и его исполнение задачи. Итак, у нас GPT Astra сформировала наш план. Нам осталось его только утвердить. Она распределила, как она распределила, как вы видите, задачи между тремя воркерами, как раз-таки равносильно. Давайте его утвердим и посмотрим. Вот у нас появилось три рабочих клодворкера. Посмотрим, что они у нас сделают и за какое время. Итак, вот смотрите, у нас первый воркер закончил работу, написал, что он сделал, и мы можем, получается, сейчас применить его изменения в наш проект. Всё. И считается, что, видите, он сразу перестал гореть и сразу засчиталось, что он закончил свою работу. Также хотел показать вам, а вот тут прямо сейчас, а в, так сказать, живую оркестратор написал второму воркеру, что его работа не соответствует критериям, которые он задал. То есть вот видите, проверка на литу это называется. Вот. И теперь ждём, когда закончат оставшиеся воркеры свою работу. Итак, смотрите, у нас все воркеры закончили свою работу. Осталось применить их изменения. Давайте применим. И сейчас у нас, если есть какие-то конфликты, интегратор сработает. Если конфликтов никаких нет, то, ну, как видимо, конфликтов никаких, судя по всему, нет. Мы можем сразу, получается, закоммитить, то есть сохранить версию нашего проекта [фыркает] на текущем этапе. Давайте это и сделаем. Создадим комит и смёржим в основную ветку. Всё, теперь у нас, получается, все изменения применены в проекте. Как мы видим, вот есть сохранилась точка в истории. На графе это выглядит вот так. То есть у нас был была отдельная ветка разработки проекта, и теперь она слилась в аэ настоящее положение нашего приложения. А так, давайте попробуем запустить его непосредственно в превью. Итак, вот у нас запустилось приложение. Давайте его посмотрим в браузере. Вот так оно у нас выглядит. Светлая, тёмная тема. То есть у нас есть здесь исполнитель, телефон, email, сайт, реквизиты, клиент, предложения. И всё это формируется вот такое коммерческое предложение. И давайте я его сейчас заполню и вернусь к вам уже с конечным результатом. Так, итак, я заполнил. Вот у нас такое коммерческое предложение получилось. А давайте попробуем сохранить его. И оно действительно сохраняется у нас в PDF-формате. Может, давайте посмотрим. А, и да, вот оно у нас открывается. Всё работает. Всё, собственно говоря. Вот такое приложение мы с вами налайпкодили. Ничего особенного в нём нет. максимально простое, максимально понятное, но как пример, а, показательный именно пошаговой разработки проекта, а-э, с как минимум формирование МВП- это очень даже неплохо. Также хотел показать, есть такая функция в непосредственно де, в котором я работаю, а это дизайн mode. То есть вы можете редактировать, вот, указывать дизайн, отправлять какие-то правки по дизайну прямо, а, из preview. Вот тоже очень удобная функция. Мне очень нравится. На этом, дорогие друзья, мы подведём наш ролик к логическому завершению. Надеюсь, он был полезен, был понятен. Всем спасибо за просмотр. Переходите по ссылке в шапке профиля и скачивайте а данное приложение для вайп-кодинга, данное де. Пользуйтесь и применяйте в своих рабочих проектах. Стройте свой workflow и грамотно, правильно. И всем удачной разработки. Всем пока.