Transcription
Я вложил тысячи часов в вайб-кодинг. Всё, от Lovable до Cursor до Claude Code, от базовых приложений до систем ИИ, которые я реально использую в реальном бизнесе. И за все эти проекты некоторые принципы стали 100% не подлежащими обсуждению. Если вы меня не знаете, меня зовут Шон. Я работаю со стартапами и своими собственными бизнесами, внедряя эти вещи каждый день. И моя цель на этом канале — предоставить вам реальные, практические знания о том, что работает, а что нет. Так что, если вы хотите создавать реальные приложения, автоматизации или рабочие процессы, которые работают, вот принципы, которым вам нужно следовать.
Итак, номер один: фиксируйте изменения так, будто от этого зависит ваше здравомыслие, потому что так оно и есть. Послушайте, вайб-кодинг может довольно быстро выйти из-под контроля. Внезапно, в одно мгновение, система выходит из строя и делает что-то, что полностью ломает важную часть того, что вы делали. И иногда она не откатывает эти изменения должным образом, что означает, что если у вас нет точки сохранения, вы будете полностью в беде.
Так что есть несколько полезных вещей, с чего начать. Прежде всего, всякий раз, когда вы начинаете работу над новой крупной функцией, вам нужно создать ветку для этой функции. Теперь команда, которая позволит вам это сделать, это `git checkout -b`. Мне нравится называть свои ветки, если я создаю функцию, `feature/` с названием функции. И если я нажму Enter, это создаст новую ветку под названием `feature/youtube-example` в данном случае. Теперь это здорово, потому что вы можете экспериментировать с чем угодно в своем проекте, не беспокоясь о том, что это испортит то, что у вас было в основной части вашего приложения.
Теперь представьте сценарий, когда три коммита назад мы внесли действительно важное исправление ошибки в нашу систему, но теперь эта ошибка снова появилась позже в приложении, и мы не помним точных шагов, которые система предприняла для ее исправления, и мы попадаем в этот замкнутый круг, пытаясь исправить эту проблему, и она не знает, как исправить ее на этот раз. Ну, теперь это не проблема, потому что мы можем поручить Claude или Cursor вернуться и выполнить `git diff`, что означает, что он может вернуться во времени и посмотреть на состояние этих файлов в двух разных приложениях и определить, что работало раньше, и что ему нужно изменить сейчас. Итак, это одно само по себе является полным спасением.
Но как нам избежать этой ситуации вообще, когда она даже возвращается и ломает то, что мы уже исправили в первую очередь? Ну, вот тут-то и вступает в игру наша следующая заповедь. Стать опытным пользователем файлов памяти. Итак, большинство современных кодинг-агентов на данный момент имеют систему для создания файлов памяти, на которые вы можете ссылаться каждый раз, когда делаете запрос к модели. Теперь, одной из частей этой сборки было то, что я использовал библиотеку под названием GraphQL для выполнения запросов с моего фронтенда на мой бэкенд. Единственная проблема заключалась в том, что по мере того, как мы строили и строили и строили поверх этой системы, она постоянно вносила это изменение всякий раз, когда хотела создать новый API-эндпоинт, где она не могла получить идентификатор пользователя, делающего запрос. Она не могла найти аутентифицированного пользователя, и поэтому она застревала в этом замкнутом круге, где она ломала фундаментально работающую функцию внутри приложения, не знала, как использовать функцию, которую я уже имел в своем распоряжении, чтобы она работала, а затем просто ломалась и ломалась и ломалась, и не знала, как решить проблему.
Итак, давайте посмотрим, как это выглядит на самом деле. В моем проекте у меня есть этот файл, который получает текущего пользователя и убеждается, что он аутентифицирован. Если пользователь не аутентифицирован, то все довольно просто. Он не может сделать желаемый запрос, верно? Так что мы убеждаемся, что только аутентифицированный или авторизованный пользователь может сделать этот запрос. Звучит довольно просто, но проблема в том, что всякий раз, когда мы создавали новый API-эндпоинт, которому нужно было использовать эту функцию, она ломалась, и она не знала, как использовать эту функцию. Итак, сначала она начинала с: "Эй, приложение на самом деле не собирается должным образом, и я не могу его использовать". Затем я заходил в Claude Code или Cursor и пытался отладить, что происходит. И решение заключалось не в исправлении ошибки. Это было фундаментальное изменение функции и того, как она работает, что ломало каждую другую часть моего приложения. И это стало огромной головной болью, и это стоило мне часов в моем процессе.
Итак, решение заключалось в том, чтобы исправить это, добавив память о том, как обрабатывать запросы GraphQL в будущем. Теперь есть несколько вещей, которые я добавил сюда, которые конкретно помогли. Номер один: всякий раз, когда фронтенд делает запрос на бэкенд, проверьте, существует ли уже существующий запрос для этого. Номер два: всякий раз, когда мы делаем запрос, убедитесь, что фронтенд мутирует должным образом и соответствует тому, что ожидает бэкенд. И номер три, тот, который действительно помог. Всякий раз, когда вы начинаете создавать новый эндпоинт, вы абсолютно должны ссылаться на похожие эндпоинты, чтобы понять шаблоны, которые уже работают в приложении. В тот момент, когда я добавил это в этот файл памяти, эта ошибка прекратилась. она больше никогда не совершала этой ошибки. И это очень важно, потому что, опять же, в тот момент, когда я добавил это в файл, я больше никогда не сталкивался с этой проблемой. Я тратил часы на отладку этой глупой аутентификации, когда хотел заниматься созданием всех крутых функций приложения, которые пользователь увидит и с которыми будет взаимодействовать.
Но это на самом деле подводит нас к следующей заповеди, которая является одной из самых важных, потому что мне пришлось осознать тот факт, что это вообще происходило. Итак, заповедь номер три: развитие интуиции относительно того, когда вам нужно действительно сидеть и смотреть на поток мыслей, исходящий из вашего кодинг-инструмента. Потому что вот в чем дело: вайб-кодинг не означает бездумность и просто принятие всего, что вылетает из системы. Вы должны выработать привычку мыслить как оркестратор, потому что знание того, что вы строите, выведет вас на следующий уровень и позволит вам превзойти 99% других вайб-кодеров. Я рассматриваю вайб-кодинг как одну из следующих великих эволюций обучения, потому что если вы внимательны, вы не просто избегаете этих разовых проблем, подобных той, которую я собираюсь вам показать, но вы начинаете накапливать знания и контекст о том, как на самом деле строить эти вещи. Что означает создание надежного решения для чего-то, что будет работать в реальном мире?
Итак, если мы вернемся к этому примеру создания обновления системы безопасности паролей, я думаю, что многие люди просто увидят этот вывод обо всем, что изменилось, и скажут: "Хорошо, круто. Переходим к следующему чату, верно?" И вы просто, вы сразу же отходите от этого. Вы не проходите и не фиксируете изменение. Вы просто говорите: "Эй, я перехожу к следующему". Но на самом деле вам нужно выработать привычку думать и читать фактические выводы этих вещей. Это займет у вас несколько дополнительных минут в вашем процессе, но вы начнете строить реальное понимание, и вы также поймаете вещи, которые он делает, которые вы не хотите, чтобы он делал.
Итак, опять же, в контексте реального мира, в той функции `get current user`, которую я вам показал, я читал выводы из Claude Code. И я заметил, что всякий раз, когда он проходил и говорил, что ему нужно изменить этот файл, который уже работал, всякий раз, когда он изменял эту функцию для того, что, по его мнению, ему нужно было сделать, вся аутентификация приложения ломалась. Меня выкидывало, все экраны, на которых я был. Мне приходилось как бы очищать все из системы и откатывать изменение. Это была полная головная боль. Но единственная причина, по которой я понял, что именно это постоянно ломало мое приложение, заключается в том, что я на самом деле читал выводы из системы, верно? Я читал цепочку мыслей о том, что, по его словам, ломалось, замечал, какой файл или какую функцию он постоянно пытался изменить, а затем говорил ему: "Не меняй это больше. Ты меня подводишь".
Это на самом деле еще одна причина, по которой режим планирования Claude Code или режим планирования любой модели является огромным улучшением, которое также стоит использовать, потому что он позволяет вам улавливать определенные вещи, подобные этой, прежде чем они вообще будут реализованы. Итак, если вы искренне хотите стать великим в этом деле, вы абсолютно должны начать делать это. Это действительно не подлежит обсуждению, потому что это не только помогает вам в данный момент, но и помогает вам создавать резервные рабочие процессы, автоматизации и системы для постоянного улучшения и улучшения и улучшения. Это одна из причин, по которой следующая заповедь — самодокументирующиеся циклы.
Итак, одна из худших вещей, которую вы можете сделать в своем проекте, — это построить что-то, о чем вы не знаете, что это такое, как оно работает, или обо всех файлах, которые на самом деле задействованы в работе этой функции. Потому что вот что происходит с этими инструментами, которые вы поймете, когда будете использовать их достаточно. Нередко они создают функции, но на самом деле не подключают всю расширенную функциональность, которую они сделали для этих функций. Так что иногда они создают что-то продвинутое, но не дотягивают или идут на уступки в фактической реализации. И единственная причина, по которой я это заметил, заключается в том, что я попросил систему задокументировать все файлы, которые использовались в созданной им функции, и как они связаны. И он, по сути, сказал мне в документации этой функции: "Да, мы создали все эти другие вещи, но они на самом деле еще не подключены. Хотите, чтобы я подключил их сейчас?"
Итак, у этого есть простой режим и продвинутый режим, которые вы можете реализовать. Если вы находитесь в таком инструменте, как Cursor, вы можете просто пройти сюда и дать ему эту инструкцию. Так вы можете сказать: "Посмотри на функцию онбординга пользователя и задокументируй, как она работает. Уровень детализации должен быть похож на тот, что найден в этом файле, где я уже сделал это с Claude Code". И я могу сказать: "Иди", и теперь он выйдет и создаст документацию функции вокруг этой функции онбординга. Теперь, если вы находитесь в таком инструменте, как Claude Code, например, вы можете использовать хуки или настроенного агента, единственная цель которого — пройти и документировать функции после создания новой функции. И вы можете фактически настроить его на вызов этой вещи вручную. Так что в тот момент, когда он завершает новую функцию, он проходит и документирует, как функция работает. В любом случае, будь то базовый режим или продвинутый режим, это то, что вы должны делать.
Давайте посмотрим, как выглядит этот файл. Итак, теперь мы видим, что у нас есть аналогичный уровень документации для нашего потока онбординга пользователя. Хорошо, теперь это другая модель. Это использует GPT-5, потому что я подумал, почему бы просто не использовать это прямо сейчас. Очевидно, это не так глубоко, но, эй, это не видео о недостатках GPT-5. Опять же, это одна из тех вещей, где вам нужно понять, что эти инструменты могут создавать так быстро, что они могут опередить вашу способность понимать и запоминать то, что строится. Правильно? Если вы на самом деле инженер-программист, который создавал все эти файлы и все эти функции вручную, вы будете помнить разные части кодовой базы, где находятся файлы, с чем они связаны, потому что вы были там, верно? Вы это сделали. Если мы этого не делаем, нам нужно убедиться, что у нас есть резервные системы, которые помогут нам запомнить разные вещи, которые мы строим, почему мы их строим и как они функционируют. Так что это помогает нам убедиться, что мы не строим кучи дерьма, которые на самом деле не работают так, как мы хотели.
Но говоря о кучах дерьма, следующая заповедь — осознание того, что в большинстве случаев эти модели на самом деле являются машинами для производства дерьма. Итак, когда ваш контекст становится большим, ваш проект становится большим, эти инструменты часто выходят из-под контроля. И поэтому часто проще на самом деле просто начать заново с новой задачей. И поэтому все, что нам нужно сделать, это скопировать этот ID. Мы можем вернуться сюда и просто сделать `git checkout`. Вставить этот ID. И теперь мы вернулись к тому моменту времени, когда эта вещь на самом деле была.
Итак, команда номер шесть, на мой взгляд, абсолютно не подлежит обсуждению для вайб-кодеров, особенно, особенно если вы не из мира разработки программного обеспечения. И это принятие трехэтапного цикла планирования, прежде чем вы напишете хоть строчку кода. Итак, большая часть вайб-кодинга начинается с очень простой идеи. Например, вы идете по своей повседневной жизни. Вы натыкаетесь на какую-то мысль или идею и говорите: "Черт, я мог бы создать приложение для этого. Другие люди наверняка заплатят за это, если бы я заплатил за это". Теперь это здорово. С этого начинаются многие великие вещи. Но этого недостаточно контекста, чтобы на самом деле что-то построить. Итак, мы хотим максимально раскрыть наш контекст, чтобы система могла взять план и на самом деле сделать что-то с ним, что соответствует нашим ожиданиям от того, что мы хотели в первую очередь.
Итак, у меня есть полное видео о моих пяти не подлежащих обсуждению промптах, которые должен использовать каждый вайб-кодер. Я дам ссылку на него где-то рядом с этим видео. Так что сейчас я хочу показать вам первые три промпта, потому что это конкретно мои промпты для планирования. Так что я использую их как агентов Claude Code, но вы можете использовать их и как промпты. Они также очень хорошо работают просто как промпты в любой системе. Итак, промпт номер один — это наш менеджер продукта, и это тот, с которого вы хотите начать. Здесь мы берем эту сырую идею, которую у вас есть о чем-то, и превращаем ее в структурированный план. Какие различные типы пользовательских персон могут на самом деле использовать эту вещь? Как они собираются ее использовать? Правильно? Как они взаимодействуют с приложением? И что мы помещаем в MVP по сравнению с тем, что попадает в бэклог функций, верно? Итак, нам нужно иметь действительно четкое понимание с самого начала того, что именно мы собираемся строить, потому что это будет передано в наш следующий промпт.
Теперь, опять же, я делал полные видео по этим темам, поэтому я не буду вдаваться в них слишком глубоко, но это действительно упражнение для мозгового штурма, где мы хотим создать краткое изложение, своего рода "лифтовую речь" о том, что это такое на самом деле, и основную проблему, которую оно на самом деле решит для людей. После того, как мы это сделали, мы хотим превратить все эти пользовательские истории или, как бы, идеи для функций, которые у нас есть, в конкретные спецификации функций. Я не хочу просто взять свою идею о том, что это приложение для рецептов, которое люди могут использовать с ИИ, а затем просто бросить это в Lovable и позволить ему что-то построить, верно? Я ничего из этого не получу, потому что оно не знает, чего я хотел в первую очередь. И поэтому в этом упражнении менеджера продукта мы раскрываем, что именно я собираюсь строить. И поэтому мы проходим через каждую отдельную функцию, которая задействована в этом, и убеждаемся, что она очень хорошо проработана.
Затем мы повторяем ту же фундаментальную предпосылку. Он фактически извлечет эти функции из результатов работы инженера по UX и знаний о том, какие эндпоинты бэкенда существуют. Так что эти первые три части этого цикла: менеджер продукта, инженер по UX и системный архитектор — практически не подлежат обсуждению. Так что мне все равно, используете ли вы Lovable или будущую итерацию Claude Code 99, вы должны внедрить процесс планирования. И, на мой взгляд, эти три этапа конкретно закладывают очень прочный фундамент для вашего успеха.
Итак, эти заповеди отличают тех, кто копается, от людей, которые могут на самом деле создавать реальные вещи с помощью этих инструментов. Так что освойте эти основы сейчас, чтобы вы могли быть в топ-1% людей, которые создают действительно крутые решения для реальных конкретных проблем.
Какая заповедь ударила вас сильнее всего? Дайте мне знать в комментариях ниже. Мне очень нравится читать комментарии, и это часто является топливом для будущих идей для видео. Так что дайте мне знать. Но на этом все для этого видео. Увидимся в следующем.