0:00 Привет. И сегодня мы поговорим, как эффективнее работать с яагентами для того, чтобы они действительно приносили пользу или, как сейчас модно говорить, использовать вайпкодинг, потому что вайпкодинг сейчас уже стал некоторой негативной коннотацией, когда это какой-то говнокод, который пишет иагенты без всякого контроля. Хотя на самом деле агенты - это просто инструмент, который при правильном использовании может дать вам большой прирост в скорости, а также в качестве вашего кода. Но начну с того, что этот подход подойдёт не всем. Если вы только начинаете свой путь в разработке, ещё не знаете, как делать хорошо, как делать плохо, как правильно, как нет, как проектировать архитектуру, как строить ваши приложения, то м использование AI на этом этапе скорее будет вредить. Именно с этим связано, я
0:46 бы сказал, большинство проблем вайпкодинго, когда люди, как бы не умеющие самостоятельно писать код, начинают использовать вайп-кодинг для того, чтобы получить какой-то результат. Хотя на самом деле этот результат будет далёк от идеала, потому что по сути A-агенты - это некоторый джунир, которого, если вы не погрузите нормально в контекст, не дадите ему направление, не дадите хорошую архитектуру, даст достаточно плохие результаты. Поэтому мой первый совет будет: "Пожалуйста, не используйте агентов, если вы самостоятельно не можете написать то же самое". Если можете, тогда эгенты - это, по сути, ускорение. И дальше мы с вами поговорим вообще, какие инструменты есть, как правильно структурировать ваши запросы, как правильно писать документацию, зачем нужна документация, какие документы нужно скарвать ей агенту
1:32 для того, чтобы он максимально качественно выполнял ваши задачи. Перейдём теперь к разбору различных типов взаимодействия с AI в рамках кода. Перед тем, как переходить непосредственно к работе стильно это сделать, я хотел бы остановиться на трёх подходах работы с AI и кодом. В самом примитивном варианте вы можете, конечно, использовать чат GPT или что-то ещё для того, чтобы задать ему вопрос, например, как написать три в питом. И, соответственно, он вам даст ответ. Вам необходимо будет оттуда взять и скопировать данный код, после этого перенести его в ваше приложение. Плюс такого подхода в том, что вам приходится чуть глубже разбираться в том, что он написал, потому что вам это закопировать. Минус, конечно, это дополнительная ручная работа. Второй
2:18 подход, который до этого был достаточно популярен до того, как появились agentic AI - это автокомприс помощью AI. Вы начинаете писать код, и AI, конечно же, за вас начинает подбирать фактически то, что, скорее всего, вы хотели бы написать дальше. И для такого ускоренного вручного написания этого более чем достаточно. Он присутствует фактически в любых сейчас. И вы можете, конечно же, его использовать, если хотите ускорить. Ну и понятно. Третий подход я буду демонстрировать опять-таки на примере Vinurf - это, эээ, уже полноценный agentic AI, где вы просите его выполнить ту или иную задачу, а затем проверяете О-код. И вот тут как раз начинается самое интересное, потому что результат часто выполнения данного кода не, мягко
3:05 говоря, не самые оптимальный. Вам нужно будет переписывать. Даже есть сейчас вакансии фиксер вайпкодинга. после того, как кто-то навайткодил что-то не совсем какачественное. Поэтому моя задача в этом видео поговорить вам, как правильно работать сentic AI в рамках. Теперь поговорим о том, а, собственно, где мы можем использовать этот Gentic AI и какие инструменты сейчас доступны. Чтобы упростить, я бы разделил все возможности работы с е-агентами на три различные группы в зависимости от вашей цели и использования. Первое - это полноценный IDE. В большинстве своём это, конечно же, Fork Visual Studio CД, который содержит внутри и агент. При этом VSOD сама по себе теперь содержит вкладочку агентов с GitHub Палотом, которая будет
3:50 вам стоить 10 долларов в месяц. Есть также одно из популярных решений курсор. В частности, я его использую на постоянной основе. Он стоит 20 долларов в месяц с ограничениями по использованию. Ну и есть такие же вещи, как трай, которые фактически сейчас предоставляет как соло агента, так, собственно говоря, полноценное для редактирования forsда, который будет за вас писать часть кода. Инф, опять-таки, одна из тоже таких популярных и достаточно стареньких таких IDE относительно появления эагентов, которые как раз работает с эагентами. В целом разницы между ними с точки зрения работы м не сильно много. Где-то чуть удобнее UI, где-то подключены различные модели.
4:38 Большинство моделей опять-таки повторяются. У кого-то они чаще завозят новые, когда они появляются. У кого-то реже, у кого-то некоторые модели являются дополнительными оплаты, у кого-то меньше. Тут уже зависит от вас. IDE в целом хороша, когда вы хотите полноценную среду разработки, где вам необходимо будет не просто дать задачу и потом, соответственно, проконтролировать, но и дописать какой-то кусок кода, поправить Z AI, отревьють, что он сделал. И, конечно, так как это forquest код, вы можете настроить всё это под себя. Поэтому тут уже выбор за вами. Это может быть курсор, висfт или, собственно говоря, встроенный Visual Studio. Вторая часть, которую я выделил - это агенты VDCI, которые выполняют задачу за вас в
5:25 терминале. По сути, вы им указываете, что вы хотите сделать, и вот получаете какой-то результат. Здесь можно выделить антроopic, код, который в терминале запускается, и вы даёте задачи, получаете результат. недавно вышедшая GLI, который работает на базе модели Gamy, а также терминал warp, которого тоже недавно добавили Gentic AI. Здесь наверное удобно, когда вы в меньшей степени хотите погружаться в код, у вас не очень сложные задачи, которые вы хотите делегировать AI. И если вы работаете, например, в WiM, в нам в консольном терминале постоянно, и вам приходится, соответственно, чтобы не переключаться между терминалом и всем остальным, пожалуйста, открыли TMAX, в одной вкладке открыли Gни, который за вас пишет код, в другой Nailwim,
6:10 ревьюте, что он сделал. Ну и третья часть - это обычные сервисы типа V0, которые сделает вам а полноценные типы проекты с нуля, которые вы можете затем отредактировать либо скачать. Ну, соответственно, работу погрузить в репозиторий. Здесь, наверное, минус такого подхода в том, что вы изначально выполняете всё это в браузере. Это не ваша полноценная рабочая среда. И для там небольших проектов, где мы хотим сделать какую-нибудь маленькую приложуху с пятью полями, это подойдёт. Если разрабатывать уже более серьёзное программное обеспечение, то здесь уже маловероятно. Вам нужно либо IDE, который поддерживает AI, либо полноценный CLI, который будет выполнять это за вас терминаль. Дальше всё в видео я буду использовать курсор, потому что я
6:56 являюсь платным пользователем и курсором. Сразу скажу, что для большинства этих инструментов, для того, чтобы оплатить платную версию, конечно, вам понадобится не российская карта, если вы в России, поэтому здесь нужно находить обходы для того, чтобы их оплачивать. В бесплатных версиях у курсора есть TwoW Trial. Похожие бесплатные версии, соответственно, есть у других продуктов. Это можно протестировать, потому что для того, чтобы полноценно всё-таки использовать это, э, на ежедневной основе в вашей работе, здесь уже нужна какая-то платная версия. Проект, кстати, одна из самых дешёвых - это 10 баксов, как, собственно, Eкоilotт. Э, и здесь даётся неограниченное число премиум мерленных запросов и, соответственно, 600 быстрых запросов для ответа. О'кей. Разобравшись теперь, что мы можем использовать,
7:42 давайте непосредственно перейдём к работе с агентами. У нас в комментариях видео часто спрашивают, с чего начать обучение. Именно поэтому мы подготовили для вас совершенно бесплатные карты развития по различным направлениям, где вы можете посмотреть все технологии, которые вам нужны для того, чтобы освоить ту или иную дисциплину, а также последовательность прохождения и освоения материалов. Все карты доступны по ссылке в описании. А если вы ещё не определились с тем, что вы хотите, то у нас есть бесплатный курс Основы разработки, где вы сможете определиться с направлениями, а также пописать код вместе со мной на JavaScript. Ну и, конечно, есть у нас и другие бесплатные материалы, например, курс по Flexbox. Ссылка на всё это будет в описании. Вначале мы рассмотрим, кейс создания нового проекта. В целом подходы как для
8:28 нового, так и для проекта, который тоже существует схожи. Отличие только в том, что для вашего старого проекта вам нужно будет более детально прорабатывать документацию ужествующего кода для того, чтобы adentic было проще с вами работать. Ну а для нового проекта я возьму пример шортлинкера. Это приложение, которое позволяет сыгращать ссылки. И перед тем, как мне вообще переходить непосредственно к коду, мне нужно будет поработать немножко бизнес-аналитиком. Для этого подаёт опять-таки любой AI, кстати, даже встроенный в CLД тоже подойдёт. Вы можете выбрать режим ask, не модификация кода, и он за вас будет, э, делать документацию и рассуждать. Ваша же задача в первую очередь - это снабдить ваш AI детальным описанием
9:13 проекта. То, что делают абвецтский бизнес-аналитики. Вы можете написать вручную, можете использовать в нашем случае чат GPT. Я ему описываю сценарии, которые я хочу, чтобы реализовались мои приложения. Это будет API, создание аккаунта по восстановление и, соответственно, ввод и чтобы авторизоваться сервисе. Я хочу, чтобы пользователь может мог создать короткую ссылку, мог перейти по ней. Как только он переходит по ссылке, формируется статистика, и он может получить агрегированную статистику по всем своим ссылкам либо, соответственно, по конкретной ссылке в разрязе дня, недели и месяца. При этом, чем у вас сложнее проект, тем, понятно, будет сложнее документация. И чем детальнее вы её опишите, тем проще будет дальше в вашемке работать с вашем приложением. После того, как я отправляю это, в результате я получаю некоторую документацию, которую могу дальше
9:59 дорабатывать, попросить расширить. И в результате это первый документ, который пойдёт в наш проект для полноценной работы. Ставлю видео на паузу и вернёмся, когда будет уже готово. Итак, после итерации CHGBT получился вот такой небольшой документ по нашему новому сервису. Здесь указана общая информация, соответственно, базу URL. Мы изловим авторизацию, формат ответа, версионирования, использование таймзоны, как и работают часовые метки и домпотентность и ограничения на рейдлимит. Далее описывается формат ошибок, а также все основные сценарии. Это авторизация, какой метод пост на signup, что отправляем, что получаем. -э, соответственно, верификации имейла, вход, обновление токена, запрос на сброс
10:46 пароля, сброс пароля по ссылки из письма, ну и, соответственно, все вот эти части. Здесь у нас, по сути, описывается всё, что нам необходимо в нашем сервисе, но уже более детализированном виде. Это можно, конечно, сделать вручную, можно с помощью чат GPT. Также описываются форматы ответов для того, чтобы мы в дальнейшем могли их использовать. Ну и примерзапрос. В конце дополнительная информация про GT, импотентность, редиректы, трекинги, дедупликацию ботов, индексы базы данных, а также обзервалити нашего сервиса. При этом я предварительно создал уже проекты. Я обычно рекомендую создавать просто с помощью CL обычной кучи для вашего проекта. Мы будем писать этот сервис на Nest, поэтому это стартовый проект Nest, где есть отдельный пак Docs requirements, который как раз я передал
11:33 все наши требования. Понятно, чем больше сервис, тем больше у вас будет требований. И если их даже несколько, вы можете их группировать. Перейдём теперь ко второму документу, который нам нужен для нормальной работы с агентами. Второй документ, который полезно описать - это правила архитектуры, которые ограничивает, что можно использовать, что нельзя. Например, в данном случае я явно попросил использовать nesg z, соответственно, для валидации дтшек. Также я указал, что мы используем именно подход SEQRS, разделённые команды хендлера, query хендлеры, ну и такие кратку архитектуру модули, которые у нас сейчас есть. Благодаря этому подходу нам потом не нужно будет каждый раз ему говорить, что о нет, ты используй класс варидатор, не надо так переделывать. Здесь мы сразу описали, что мы требуем.
12:19 Фактически requirements - это бизнес-требования. Arc rolls - это некоторые правила архитектуры, которые он должен применять в своей работе. Здесь можете указать всё, что нужно, от необходимости использовать там стрикт-режим всегда там до тех ограничений структурных, которые вы хотите, чтобы придерживались. Если вам нужен, например, фронтend и какой-нибудь fch slessдизаignн, явно ему это укажите в архитектурных правилах. Так вы будете меньше его править в дальнейшем. Итак, у нас есть уже requirements, бизнес-трелебования, архитектурные правила. И теперь это всё нужно объединить в единую систему. Для того, чтобы курсор обязательно читал это в каждом контексте, нам необходимо создать ему курсор правила. Для этого мы открываем preference, открываем курсор Settings, переходим в Rules и создаём
13:06 новый Rules, New Project Rules. Называем его мои основные проектные правила. Allply true. То есть мы всегда хотим, чтобы он их применял независимо от нашего запроса. и описание основные правила и архитектуры сервиса. Здесь мы ему должны указать, что все правила архитектуры описаны в собачка. И здесь можно указать docs/chrules md. И дальше все бизнес-трелебования к сервису описаны в requirements rules. Давайте скопируем наименование и ставим сюда. Теперь при каждом запросе у вас будут применяться данные правила архитектуры и бизнес-требования. Но на
13:53 этом наша документация ещё не закончена, потому что после того, как мы дальём ев базу и основу, нам теперь нужно переходить к реализации. А чтобы эта реализация не была хаотичной, мы заставим её сделать план. Для этого мы создадим новый документ, который мы назовём Plan. Ну и realization plan MD. Этот план пока мы будем самостоятельно не будем заполнять. Задача первая, которую мы дадим курсору или любому другому enti взять план. Нужно посмотреть требования к проекту и составить детальный план реализации. Указав этапы реализации в документе план MD можно убрать первоглирующуюся. Теперь отправляем его. И теперь первая его задача просто
14:41 сделать нам документацию. Как мы видим, он изучает requirement и Arc rules, потому что мы ему явно в main MD, которая всегда исполняется, указали эти требования. И теперь он составляет себе план для реализации этих требований, проанализирует требования, настроить базовую инфраструктуру, реализовать модуль. Ну вот, соответственно, сейчас он редактирует, э, создаст планы реализации. Он зачем-то сразу решил: "А, пойду-ка я реализую, подожди, пожалуйста. Нам нужен сначала основной план реализации, чтобы мы его сначала согласовали и затем уже перешли к реализации. Потому что если мы его просто, да, даж на описанных там рекваременсах и аркрулах отправим реализовывать, получается не всегда самый оптимальный результат. Поэтому моя рекомендация всегда делать план. Если это, конечно, маленький какой-то фикс,
15:27 небольшая задача по доработке, можно, конечно, избавиться от плана, но при проектировании с нуля системы в обязательном порядке необходимо его составлять, делать план. Он, конечно, самостоятельно делает вот такие чек-листы, и это делает большинство сейчас и, но, соответственно, вот отлично. Теперь останавливаем его. Нам не нужна базовая конфигурация. Давайте посмотрим, что он сделал. Итак, ээ, основные принципы: этапы реализации, подготовка инфраструктуры, установка паспорт на GSOT eventies для клиента. О'кей. А, реализация модулятификации создание. То есть второй этап - это авторизация, сервисы, стратегии. Отлично. Дальше Mul Links, создание сущностей. Подходит реализация редиректа. Прекрасная реализация
16:13 трекинга кликов. И, наконец, реализация аналитики, которая, собственно говоря, будет это в конце. Дополнительные функции импотентность для проверки хранения ключей, возврат шйлимит, мониторинг локирования. О'кей, в принципе, нормально. Структуру модели он также описал. Вот это всё, кстати, надо будет перенести в четвёртый документ, о котором мы поговорим позже. Он предлагает, соответственно, а с команд qu handlers guardst. Прекрасно. И технические детали. база постгress, радис для ссылок и агрегаций, индексы, соответственно, я предлагаю Postgrгress для всего использовать. Не будем дополнительно затаскивать Ries. И здесь тогда нужно убрать IO Radies. Redс клиент нам не нужен будет. Подредактировали. Так, индексы. О'кей.
17:01 Производительность для популярных ссылок. Короче, избавляемся. Асинхронно обработка крипа. Бачиработки агрегации GVT Rateit. О'кей. Всё, план мы согласовали. Теперь можно переходить к реализации первого шага, но тоже с небольшой оговоркой. Кстати, не забывайте подписываться на наш Telegram. Мы там периодически публикуем интересные новости, обновления, промокоды, а также новые материалы. Кроме того, у нас есть там уютный чатик, где вы можете пообщаться и поговорить о том, что сейчас происходит в мире JavaScript и не только. Ссылка, как обычно, в описании. Теперь пришло время добавить четвёртый документ и исполнить первый этап нашего проекта. Для этого создаём новый документ, который бы назывался архитек,
17:46 если я правильно написал. Это слово - это архитектура. Задача этого документа- хранить всю нашу архитектуру и, что самое важное актуализировать. При изменении проекта нужно вносить описание архитектуры в документ Собачка докс. MD и использовать его в работе. Есть. Теперь наша подготовка полностью завершена, и мы можем начать собственно говоря писать нашу первую часть. Поэтому начни реализацию этапа один. В данном этапе, напомню, нам нужно будет сначала настроить базу данных, настроить вот этот. Как мы видим, он считал всё необходимое и добавил вот тут
18:32 несколько, соответственно, чек-листов. устанавливает зависимости, пазную инструктуру немножко опять сильно пришёл подготовка инструкструктуры проекта, да, он просто обновил, говорит, что он перешёл к подготовке структуры проекта. Соответственно, устанавливаем все необходимые зависимости backриpt паспортная JS. Единственное, что он почему-то взял класс validator transформе, хотя мы его явно просили использовать HDS, хотя он тут тоже есть. Н посмотрю, как он его будет использовать. И он установил всё необходимое, создал file, создал example с примером j application, декомпозирув это всё прекрасно. Что у нас ещё дальше? Мы можем как бы дальше проходиться по тому, что он уже сделал, принимать или
19:18 просматривать. Сделал договор compс для подъёма нашей тестовый погрос. Ну и, собственно, дальше добавился up контейнер для того, чтобы могли запустить, хотя это на самом деле не особо критично. Также double Wлфайл сборки не самые оптимальная, на восемнадцатой почему-то ноде, что, кстати, надо будет явно ему описать в Arc rules версии. Нам нужно сказать, что мы используем используем Note 20 Plus, чтобы он дальше не делал таких ошибок. Поэтому в любом случае, когда вы видите любую ошибку с точки зрения того, что он делает не совсем корректно, сразу фиксируйте это, добавляйте ему в правила архитектуры, и с этим вы больше не будете сталкиваться. Он добавил ещё несколько интерфейсов. Стандартные typйсы Sha команды результаты интерфейсы
20:06 query для того чтобы их структурировать. Ну о'кей. Добавил shared папочки guardх hand хендлеры, midлверы. Хотя, кстати, зачем непонятно. Лучше бы декомпозировать на отдельные модули. Ну и вот у нас есть модуль ауз кликов, конфигурации и аналитики. Собственно, то, что мы и просили. Ну, видимо, здесь будут какие-то shared команды для того, чтобы объединить моду. Вот таким образом мы с вами уже контролируем, что пишет в результате наш AI. Мы можем контролировать это с точки зрения архитектуры, требований, а также, так как он будет поддерживать нашу архитектуру в актуальном состоянии, он каждый раз будет возвращаться к правильному контексту. Даже если вы перезапустите будущий контекст, вы будете использовать другой силой утилиту, не проблема, он должно быть
20:54 документировано. Как мы видим, нужно самостоятельно добавлять даже instant structure setup дополнительным для того, чтобы добавить настройку архитектуры. Проверил, что наше приложение успешно собралось и выполнил, в принципе, первый этап, где он добавил все необходимые зависимости, подготовил doer compost для подъёма постгреса, а также добавил infrastructure setup информацию о нашей инфраструктуре. Вот общие компоненты, раздел на модули. Ну и, собственно, всё описал прекрасно. Первый этап выполнент. И дальше наша задача вот так по этапам идти, конечно же, проводить ревью. И об этом мы поговорим дальше. В целом ваша задача при таком подходе - это быть качественным ревюером. И большинство того, что вы будете делать - это ревью, писать исправление и дальше ревьюить.
21:39 Конечно, какие-то части, которые ему достаточно сложно будет написать, а проще проще написать вручную. Но в любом случае, например, вот здесь он сделал какой-то config, который обращается через process. Этот подход мне не очень нравится, поэтому что я могу попросить его добавить этот файл в контекст и сказать, что все конфигурации давай сделаем через Nests. Только через собачку он помн пишется NJS config и через for root для того, чтобы мы один раз настраивали конфигурацию, могли прокинуть через configвиice. Таким образом, всё, что нам не нравится, мы либо самостоятельно корректируем, либо, соответственно, просим его переделать нашу конфигурацию для того, чтобы у нас
22:26 было правильное использование того или иного подхода. Ну и у вас может возникнуть вопрос: а работает ли такой подход к написанию кода на больших существующих проектах? Тут ответ зависит от качества вашего проекта. Если ваш проект хорошо документирован, как, например, вот у нас есть проект, где есть опять-таки полностью описание архитектуры, описание базы данных, описание наших модулей, что они делают, информация общая по проекту и как она структурирована, то, в принципе, внедрение фич проходит достаточно безболезненно. Конечно, ему нужно периодически обучать, давать информацию о том, что у вас принято, что нет, но это работает. Если у вас очень огромный проект Legacy, который нигде не описан,
23:11 то, конечно, ваш вайп-кодинг ничему не поможет. И здесь уже нужно какие-то совсем локальные изменения делать, ну или писать руками. К тому же хочется отметить, что, э, на текущий момент развитие AI он больше пригонит для реализации небольших фич. Не стоит думать, что он за вас напишет там весь проект, сделает целиковый микросервис и ещё куча всего. Лучше всего декомпозировать задачу на этап, как мы с вами делали, и дальше его реализовывать. Благодаря этому вы можете чётко задать ему границы того, что ему нужно сделать, правила, по которым он должен сделать, и тогда он будет оперировать, в принципе, как такой крепкий джун, который знает у вас, что происходит на проекте. И тогда уже можно большую часть времени провести именно в кодрев, проверках и качестве. И
23:58 на практике, по крайней мере, у меня это достаточно сильно ускоряет процесс, чем каждый раз руками писать одно и то же, что я уже сотни раз писал. Но стоит отметить, что всё-таки это подходит только тем, кто уже прошёл этап становления как разработчик, тем, кто уже сам может проводить кодрев, тем, кто понимает, как правильно сделать архитектура, как нет. Иначе можно упереться в то, что у вас будет сомнительные решения, костыли и всё остальное, которые вам предложит Иа. Поэтому с этим нужно быть осторожным. Ну что ж, я надеюсь, что это видео было вам полезно. Если так, то, пожалуйста, напишите в комментариях, а вы используете агентов для того, чтобы писать код на вашей работе или пт проектов? Если да, напишите, какими пользуетесь. Ну и, конечно, если не смотрели предыдущее видео прося
24:44 выбработки, то где-то будет подсказка. А мы с вами увидимся через неделю. Yeah.
