Transcription
В последнее время я активно занимаюсь Vibe-программированием, что по сути означает использование AI-агента для написания кода. Я практически не пишу код вручную, фактически вообще не пишу. И я собираюсь рассказать вам обо всем, что узнал по пути, чтобы максимально эффективно использовать этот метод. Давайте сразу перейдем к делу.
Итак, быстро о том, что я имею в виду под Vibe-программированием, или, собственно, агентным программированием, как хотите это называть: вы используете этот агент-ориентированный код в Cursor или Wind Surf. Вот он: «Agent, спроси и измени». Это не просто начало написания кода; вы нажимаете Tab, и он дописывает фрагмент кода за вас. Я буквально пытаюсь заставить ИИ написать целое приложение от начала до конца, поэтому это немного сложнее, и, безусловно, есть некоторые ограничения.
Во-первых, мой инструментарий: Cursor или Wind Surf. Я почти исключительно использовал модели Claude 3.7, в основном сосредотачиваясь на версии «thinking». Итак, я использую Claude 3.7 Sonic thinking. В Cursor и Wind Surf вы можете настроить любую модель, которую хотите. В настройках Cursor есть предопределенный список моделей на выбор, предоставляемых непосредственно Cursor или Wind Surf. Также можно добавить модели. Добавление пользовательских моделей не очень удобно: нужно указать ключ API OpenAI. Вы включаете его, добавляете ключ, и можете переопределить базовый URL. Это можно сделать только один раз, то есть вы можете иметь только один сервис API, не являющийся OpenAI, но это нормально. Я использую Grok, и вставил сюда свой ключ Grok. Grok отформатирован в соответствии со стандартом API OpenAI, поэтому он просто работает.
Какую бы модель вы ни выбрали, если вы используете ее с функцией агента, убедитесь, что она действительно хорошо поддерживает агентное поведение и вызов функций (function calling) и вызов инструментов (Tool calling). Большинство моделей этого не делают. Claude 3.7 thinking делает.
Поэтому я рекомендую сначала написать очень подробную спецификацию — это очень детальное объяснение того, что вы хотите создать. Я использую для этого Grok 3: «Напиши спецификацию для приложения, которое будет клоном Twitter. Будь максимально конкретным. Мы будем использовать Python для бэкенда». Нажимаю Enter, и я работаю с ИИ отдельно, чтобы помочь мне написать эту спецификацию. Как видите, он выписывает не только технические характеристики, но и то, как оно работает. Здесь даже написана схема базы данных — это действительно полный документ: API-endpoints и т.д. После завершения вы просто копируете все это и вставляете в Cursor.
Показываю, как это выглядит. В новом окне Cursor переходим в верхний правый угол и нажимаем кнопку переключения панели ИИ. Откроется окно чата. В последних версиях Cursor агент будет по умолчанию. У меня модель Claude 3.7 Sonic thinking. И вот важная часть: мы вставляем нашу спецификацию. Но прежде чем это сделать, еще один момент, который я выучил, особенно важный, когда кодовая база становится больше: используйте правила — правила Cursor или Wind Surf. Обе IDE поддерживают правила. Правила — это способ сообщить ИИ, агенту, как вы хотите писать код, какие технологии использовать, какие рабочие процессы применять. Это было для меня огромным открытием, потому что часто я пытался что-то построить, и он строил это, используя какую-то технологию, которой еще не было в моей спецификации, и это ломало другие вещи. Если была ошибка, и я пытался ее исправить, он пытался использовать другую технологию. Хороший пример: я хотел использовать SQL-базу данных для всего, но каждый раз, когда у меня возникала проблема с SQL-базой данных, агент пытался исправить ее, переключаясь на хранение JSON в файле. Это было очень раздражающе, потому что я думал, что все работает, а ничего не появлялось в базе данных.
Итак, возвращаясь к этому, вот мой настоящий проект. Я покажу вам, где находятся правила. В настройках Cursor переходим к правилам. Можно иметь правила для пользователя (для любого проекта), но мне нравится добавлять их к правилам проекта. Добавляем новое правило, и оно создает эту папку Cursor, а внутри нее — папку rules. Все эти файлы .md — это правила, и вы можете ссылаться на них как на системные сообщения для работы ИИ.
Спасибо спонсору этого сегмента, Mammoth! Лучший генеративный ИИ всего за 10 долларов в месяц! Это включает в себя лучшие большие языковые модели, такие как Claude, DeepSeek, GPT-4, Llama модели, Mistral, Gemini, Grok, а также модели рассуждения, такие как DeepSeek R1 и LLaMA 03 mini. За ту же цену вы также получаете лучшие модели генерации изображений: Midjourney, Flux Pro, ReCraft, DALL-E, Stable Diffusion — все в одном месте! Вы можете создавать пользовательские Amu, которые помогут вам в ваших проектах. Это своего рода агенты, вы предоставляете им весь свой контекст, и они будут знать, что вам нужно. Вы можете установить его на любое устройство: Apple, Android, Windows, Linux. Вы можете использовать однократный повторный запрос и многое другое! Обязательно проверьте Mammoth, они были отличным партнером для этого канала. Ссылки внизу.
Возвращаемся к видео. Покажу мои настройки кодирования. Это формат: естественно-языковое описание. Можно автоматически подключать разные файлы, но я этого не использовал. Предпочтения по шаблонам кодирования. Теперь пройдусь по каждому из них и объясню, почему я их добавил, потому что, надеюсь, это сэкономит вам много времени. Это отражает некоторые тенденции, которые есть у этих AI-агентов, которые не очень хорошо работают.
* Всегда предпочитайте простые решения. Это само собой разумеется.
* Избегайте дублирования кода. Проверяйте другие области кодовой базы, в которых уже может быть похожий код и функциональность. Я обнаружил, что при добавлении новой функциональности или попытке исправить старую функциональность он часто дублировал код, считая, что этого кода еще не существует. Теперь я явно говорю: убедитесь, что проверили везде, убедитесь, что этого кода еще не существует, и если существует, исправьте его, а не добавляйте новый рабочий код.
* Еще одна проблема: AI-агенты плохо понимали разницу между средами разработки (Dev), тестирования (Test) и продакшена (Prod). Это был для меня огромный урок. Я делал изменения, писал для них тесты, тесты влияли на среду разработки, среда продакшена пыталась использовать локальные данные, и это был просто бардак. Теперь я говорю: «Все, что вы делаете, вы учитываете: нам нужны отдельные среды разработки, тестирования и продакшена».
* Будьте осторожны, вносите только запрошенные изменения или изменения, в которых вы уверены и которые связаны с запрошенным изменением.
* Еще одна проблема: я запрашивал изменение, один маленький фрагмент кода, одну маленькую функциональность, и еще три другие вещи просто ломались без причины. Он пытался затронуть другие фрагменты кода. Поэтому я действительно подчеркиваю: сосредоточьтесь только на том, о чем я вас прошу. Снова: сосредоточьтесь только на том, о чем я прошу. Не вводите новые вещи.
* При исправлении ошибки или бага не вводите новый шаблон или технологию, не исчерпав все варианты для существующей реализации. А если вы все же это сделаете, обязательно удалите старую реализацию, чтобы у нас не было дублирующейся логики. Я обнаружил, что что-то делалось одним способом, не работало идеально, я говорил исправить это, а вместо того, чтобы исправить это, оно просто переписывало это по-другому, полностью считая это новым кодом.
* Поддерживайте кодовую базу чистой и упорядоченной. Я часто обнаруживал беспорядок в коде.
* Избегайте написания скриптов и файлов, если это возможно, особенно если скрипт, вероятно, будет выполнен только один раз. Я обнаружил, что когда агент что-то тестировал (например, один из API-endpoints или одна из страниц была сломана), он писал скрипт для тестирования, что нормально, но потом он просто оставлял скрипт в моей кодовой базе, и у меня было много разных одноразовых скриптов, которые, скорее всего, никогда больше не будут использоваться. Я хочу, чтобы он либо просто писал скрипт и выполнял его в строке, либо, когда он закончит со скриптом, просто удалял файл.
* Избегайте файлов более чем на 200-300 строк кода; делайте рефакторинг в этом случае. Это не всегда жесткое правило, но для ИИ, я думаю, оно уместно. Я часто находил файлы, которые были просто огромными, и я просил его сделать рефакторинг, и к тому времени, как я замечал это, рефакторинг ломал все тесты, и это занимало много времени. Просто опережайте события: как только кажется, что вы собираетесь превысить этот размер строки, сделайте рефакторинг кода.
* Я также обнаружил, что он создавал фиктивные данные (заглушки и макеты), что по сути означает наличие резервных, поддельных данных, но это не очень хорошо работает в средах разработки или продакшена. Допустим, я просил его собрать статью, и по какой-то причине сбор данных не удался. Он ловил ошибку и возвращался к использованию фиктивных данных, думая, что все работает, но это не работало. Это не то, чего я хотел. Я действительно хотел, чтобы он правильно собрал данные, поэтому он всегда использовал фиктивные данные, это было очень расстраивающе. Поэтому я явно сказал: «Не используйте фиктивные данные для разработки или продакшена, только в тестовых средах». И я как бы удвоил ставку и сказал это снова: «Никогда не добавляйте шаблоны заглушек или фиктивных данных в код, который влияет на среды разработки и продакшена».
* Я также обнаружил, что он перезаписывает мой файл .env, поэтому мне приходилось часто получать новые ключи API. Поэтому я просто сказал: «Не делай этого».
* Еще одно правило — мой стек. Я, возможно, мог бы быть более подробным, но это просто мой технический стек. Потому что опять же я обнаружил, что если SQL не работал, он просто переключался на использование хранилища JSON в файле, чего я не хотел. Поэтому я сказал: Python для бэкенда, HTML, JS для фронтенда, SQL-база данных, никогда не использовать хранилище файлов JSON, отдельные базы данных для разработки, тестирования и продакшена, и снова подчеркиваю это. ElasticSearch для поиска, используя хостинговую версию, потому что я говорил об ElasticSearch, и он думал: «Хорошо, вы хотите сделать это локально». Иногда он делал это с хостинговой версию, но я хотел только хостинговую версию. И Python-тесты. Я перейду к тестированию через минуту.
* Мои предпочтения в рабочем процессе кодирования. Немного дублирующейся информации, но, надеюсь, это просто даст ему больше руководства. Сосредоточьтесь на областях кода, относящихся к задаче. Не трогайте код, не связанный с задачей. Вы видите, что у меня было много проблем с этим. Пишите тщательные тесты для всей основной функциональности. Я делал это вручную: я просто заставлял его писать для меня код, а потом говорил: «Хорошо, теперь напиши для него тесты», и иногда я забывал. Теперь он должен просто писать тесты для всей основной функциональности.
* Избегайте внесения существенных изменений в шаблоны и архитектуру работы функции после того, как она показала свою работоспособность, если не указано явно. И снова я говорю: «Эй, исправь эту проблему», а чтобы исправить ее, он в основном отбрасывает исходный шаблон и переписывает его с нуля, используя какой-то другой шаблон или какую-то другую технологию, и я этого не хотел. Я хотел, чтобы он просто исправлял то, что у меня уже было.
* Всегда думайте о том, какие другие методы и области кода могут быть затронуты изменениями кода.
Вот такие правила. Вы можете добавить больше и давать ему столько инструкций, сколько сочтете нужным, потому что это будет очень полезно по мере продвижения.
Теперь у нас есть полная спецификация обратно в Grok. Я бы, очевидно, просмотрел ее, поработал бы над ней в Grok или любом другом ИИ, который вы хотите использовать, убедился бы, что это именно то, что вы хотите, внес бы соответствующие изменения, скопировал бы все, вставил бы сюда, и все готово. Я не буду повторять это, я просто сделаю это за один раз. Выделяю все, вставляю прямо в окно и говорю: «Построй это на основе этой спецификации». Посмотрим. Я не буду смотреть на это, давайте просто предположим, что все пойдет хорошо. Я покажу вам, как это выглядит через минуту, но позвольте мне просто показать вам еще несколько рекомендаций.
Возвращаемся к моему существующему коду. Одна вещь, которую вы заметите, и к которой вам следует привыкнуть, — это панель справа. Это весь контекст, который вы ему предоставляете. Это важно, потому что в какой-то момент его становится слишком много, и он начинает работать хуже. Поэтому вы должны знать, сколько контекста вы предоставляете, как долго длится разговор, прежде чем начать новый чат. И вы видите здесь, серым цветом: «Начните новый чат для лучших результатов». Это то, что вам придется выяснить, поиграв с этим. Если вы начинаете новый чат, вы теряете контекст. Вы можете перенести часть контекста в новое окно чата, но это раздражает. Вы хотите дать ему как можно больше контекста, но если вы дадите ему слишком много контекста, он начнет работать хуже. Поэтому обязательно поэкспериментируйте с этим.
Я начну новый чат. Нажму еще раз. Первое, что он делает, — вставляет предпочтения рабочего процесса, но я хочу, чтобы все мои правила были там каждый раз. Я нажимаю «Мой стек» и «Предпочтения по кодированию». Теперь у него есть контекст этих трех правил. Я на самом деле не знаю, делает ли он это автоматически, но, похоже, мне приходится вручную вставлять эти три файла, что, ну ладно.
Моя следующая рекомендация: будьте очень точны в своих запросах к агенту. Исправляйте мелкие вещи, добавляйте небольшие функции и тестируйте как можно больше. Заставьте его писать тесты. Тестирование — это отдельная тема. Я обнаружил, что лучше всего работает сквозное тестирование (end-to-end testing), тестирование, где он фактически щелкает и пытается делать то, что делал бы пользователь, а не модульные тесты, например. И помните, каждый раз, когда вы что-то пишете, вы запускаете тест. Если тест проходит, отлично. Если тест не проходит, заставьте его исправить тест. Но исправление теста — это интересная вещь. Вы должны внимательно следить за этим, потому что иногда он будет исправлять тесты таким образом, который повлияет на продакшен, таким образом, как вы думаете, что он должен работать, тогда как на самом деле правильный подход — просто исправить сбой теста. Поэтому вам нужно просто следить за этим. Вам не обязательно кодить это самостоятельно или вручную что-то корректировать, но убедитесь, что тест проходит, а затем используйте интеграционный тест для подтверждения или просто зайдите в приложение сами и протестируйте эту функциональность. Как видите, здесь у нас есть множество разных тестов, тесты для всего.
Еще одна рекомендация (немного скачу): используйте популярный стек. Если вы используете какую-то новую технологию, ИИ, вероятно, будет работать не так хорошо, потому что у него не так много опыта работы с этим языком программирования или стеком. Поэтому он просто не будет работать так же хорошо. Я бы выбрал действительно распространенные стеки. Мне нравится Python, HTML и JavaScript на фронтенде. Держите все очень просто. SQL для базы данных, ElasticSearch, если я делаю поиск. Выбирайте очень популярные технологические стеки, и у вас будет гораздо больше документации для исследования ИИ.
Покажу пример чата, как он на самом деле выглядит. Это старая функция, которую я создал: «Введите максимальную длину тега — 20 символов. Убедитесь, что у нас еще нет кода для этого. Напишите тест для этого после реализации». Я снова и снова подчеркиваю, как я хочу, чтобы он кодировал, это не повредит. Отправляете, и он начинает. Сначала он думает, и вы можете фактически прочитать ход его мыслей, что очень здорово. Затем у вас есть вызов инструментов (tool calling). Там, где вы видите «Перечисленный каталог», «Прочитать файлы», «Поиск файлов», у него есть множество доступных инструментов. Вы также можете использовать MCP-серверы, если хотите предоставить ему внешние инструменты. Это целая отдельная тема. Я на самом деле еще не использовал это ни в одном из своих кодов, но мне нужно еще с этим поэкспериментировать. Это будет в другом видео. Видите все это, вы можете просто щелкнуть и действительно понять, как агент работает с вашей кодовой базой. Прокручиваю вниз. Вот он, GPT, читает файл, читает файл, а затем говорит: «На основе моего анализа кодовой базы я нашел вот что». Говорит, что он собирается сделать, а затем начинает.
Есть три настройки для выполнения действий. Вы можете делать все вручную, это означает, что каждый раз, когда он будет вносить изменения или выполнять что-то, что может повлиять на ваши файлы, он будет спрашивать вас, и вы должны будете вручную утверждать все каждый раз. Я использую режим YOLO, и он буквально называется «YOLO» — это противоположность. Он просто автоматически выполняет все, и это, конечно, рискованно, потому что он будет пушить в GitHub, он будет разворачивать в продакшен. Если у вас действительно есть кодовая база уровня продакшена, и люди ее используют, я бы не рекомендовал этого. Но для Vibe-программирования чего-то с нуля — вперед. Есть также что-то среднее, я думаю, это называется «Авто», это просто означает, что он будет самостоятельно определять, какие из них он выполняет автоматически, а какие команды он попросит вас утвердить.
Он вносит некоторые изменения, вы видите, что он запускает эти тесты. Все тесты пройдены. Из всех моих тестов один тест не пройден, поэтому нам нужно исправить неудачный тест. Он смотрит, почему он не прошел, и начинает менять код. Видите, еще больше вещей о фиктивном репозитории. Я этого не выносил, это действительно сильно меня раздражало, поэтому я упоминал раза пять: не используйте вообще никаких фиктивных данных в разработке или продакшене.
Продолжаем. Все тесты пройдены, отлично. В конце он дал мне сводку обо всех внесенных изменениях, и я просто продолжил. Но помните, чем больше вы продолжаете, тем больше окно контекста становится перегруженным, и вы захотите начать новый чат так часто, как это имеет смысл. Я знаю, что это не очень четкое правило, но вам придется выяснить, что лучше для вас.
Я стал очень зависим от агентов, чтобы делать вещи. Я даже говорил: «Хорошо, закоммитить этот код, написать хорошее описание и развернуть его на Heroku», и он делал это, и у него действительно не было никаких проблем. Дело в том, что все это довольно медленно. Сейчас я чувствую себя немного избалованным, потому что я говорю, что все это медленно, но он пишет больше кода, чем я мог бы за гораздо более короткий промежуток времени. Но каждая команда, которую я отправлял, занимала от двух до 15 минут, чтобы завершить цикл итерации. Он тестировал вещи, пытался что-то сделать, запускал тест, тест не прошел, он исправлял его, проверял, что все работает. В этом смысле он немного медленный. Одно потенциальное решение — открыть разные окна Cursor и просто позволить ему работать над разными ветками, иметь как бы две ветки, работающие одновременно, и вы можете делать это много раз. Таким образом, у вас может быть много разных веток, над которыми вы работаете одновременно, а затем объединить их все в конце.
Иногда я переключаюсь между Claude 3.7 thinking и Claude 3.7 обычным, не «thinking». «Thinking» обычно работает лучше, он просто немного медленнее. Иногда я просто говорю: «Рефакторинг кода». Я даю ему какие-то инструкции, например: «Найди самые длинные файлы и сделай рефакторинг, но убедись, что это рефакторинг с низким риском», и я явно говорю ему об этом, и он просто делает код немного чище, немного более организованным, не меняя шаблоны в большинстве случаев, что меня не очень волновало, потому что это просто сломало бы слишком много вещей.
Я достиг точки, когда было очень трудно вносить какие-либо изменения. Я вносил изменения, и это занимало так много итераций, чтобы все правильно сделать, так много итераций, чтобы исправить ошибку. И я думаю, если бы я знал все это заранее, я бы смог продвинуться намного дальше. И я должен сказать, это становится довольно затягивающим. Я сижу, делаю что-то другое, напишу команду: «Построить эту функцию», отхожу и просто позволяю ему работать, возвращаюсь через 10 минут, чтобы увидеть, сработало оно или нет. Я бы повторял, отходил, возвращался. Это то, что вы можете делать почти асинхронно, то, где вы делаете что-то другое, и вы можете просто давать команду за командой.
Одна вещь, которая мне бы хотелось, — это чтобы это было доступно на моем телефоне. Replit имеет что-то подобное, но мне не нравится его агент кодирования, он просто немного сложнее в использовании. Я бы очень хотел, чтобы была полностью размещенная версия, которую я мог бы использовать на своем телефоне, где угодно, потому что легитимное программирование становится намного более осуществимым, когда вы используете такого агента. Просто набрать что-то на телефоне очень легко, вы можете следить за этим, вы можете повторять, и это не требует полного экрана, клавиатуры и мыши. Поэтому это открывает целый мир возможностей для мобильного программирования.
Еще несколько последних рекомендаций: часто коммитите, часто коммитите. Я не могу достаточно подчеркнуть это. Убедитесь, что каждое изменение, которое вы вносите, вы коммитите, потому что вы всегда можете откатить, если оно дойдет до состояния, которое просто невозможно исправить. И еще одна версия этого: вы можете фактически просмотреть историю чата, поэтому вы можете откатиться к предыдущим чатам. Если я просто нажму на этот, я добавил темный режим, прокручиваю в самый верх, и я могу просто сказать: «Восстановить контрольную точку», и он откатит для меня код. У вас не только есть Git для этого, но и встроенная система контроля версий через Cursor или Wind Surf.
Вот все лучшие практики, которые я узнал за примерно 100-150 часов Vibe-программирования разных приложений, игры. Это было очень весело, и я с нетерпением жду, когда эти инструменты улучшатся. Это худшее, что когда-либо будет, и все эти проблемы, которые вы испытываете сейчас, или которые я испытываю сейчас, будут только упрощаться в будущем. Наслаждайтесь Vibe-программированием. Вам действительно нужно очень мало знать о программировании, чтобы создать что-то невероятное. Я призываю вас создавать. Если вам понравилось это видео, пожалуйста, поставьте лайк и подпишитесь, и увидимся в следующем видео!