Я не разработчик, не знаю ни одного языка программирования и ни разу не писал настоящий код руками. В школе и универе изучал какие-то основы, но все уже безнадежно выветрилось. При этом за последний год я создал несколько пет-проектов, которые приносят мне деньги, и которыми пользуются тысячи людей.

Все благодаря слову, которое Collins Dictionary выбрали словом 2025 года, — вайбкодингу. Я выступаю как продакт — придумываю, что делать, ставлю задачи, контролирую качество. А всей технической частью занимаются нейросети: определяют стек технологий, пишут код, ищут и исправляют ошибки, разворачивают все на сервере.

При первых попытках вайбкодинга ИИ писал мне неработающий код, ломал уже работающие сервисы, безнадежно врал, удалял важные файлы и всячески саботировал работу. Не потому что он тупой, а потому что я не умел с ним работать.

Поэтому последний год я много общался с разработчиками, читал гайды, смотрел видео, общался с самими нейронками на тему «а как бы мне организовать все так, чтобы таких проблем больше не было». И собрал набор советов, который кажется очень важным для начинающих вайбкодеров.

Это статья для НЕразработчиков, которые хотят в паре с ИИ сделать себе полезный скрипт или пет-проект. Я постарался написать ее максимально просто, чтобы даже далекие от разработки люди понимали, что делать и куда копать.

Всего будет 12 советов.

А если вы разработчик, будет очень круто, если вы дополните статью своими советами. Ну или опровергнете какие-то мои.

1. Не пишите код в ChatGPT

Моя первая попытка вайбкодинга выглядела как-то так.

Я открываю ChatGPT, описываю ему идею — хочу сделать расширение для Гугл Хрома, оно должно находить все ссылки на открытой странице, проверять их и подсвечивать битые.

ChatGPT выдает мне какой-то код, я смотрю на него как баран и не понимаю, что делать дальше. ChatGPT пишет инструкцию, я не осиливаю сделать то, что там написано.

Тогда ChatGPT дает мне архив, я его распаковываю, загружаю в Хром, вижу, что ничего не работает, пишу об этом в чате.

ИИ что-то правит, отдает мне новый архив, я снова его распаковываю… Это неудобно!

Знакомые неразработчики, с которыми я общался, начинали примерно так же. Конечно, никто из них никакой рабочий сервис сделать так не смог, потому что бесконечно носить туда-сюда архивы — это очень фрустрирующий процесс.

К счастью, есть гораздо более удобные инструменты — агенты. Они не просто генерят код, который надо куда-то скопировать, они могут работать с вашими файлами на компьютере. Создать новую папку, установить нужные библиотеки, написать код, создать файлы, запустить что-то через терминал, подключиться к серверу и установить все на нем.

Короче, сделать всю работу «под ключ». От идеи до работающего сервиса, бота, приложения.

Вот как это выглядит —агент сам находит, где и что надо исправить, редактирует файлы, запускает команды, смотрит логи на сервере и так далее.

Вот популярные инструменты-агенты для вайбкодинга:

• Cursor

• Windsurf

• Codex от OpenAI

• Claude Code

• Google Antigravity

Самый популярный — Cursor. Долгое время я работал в нем, но потом по совету знакомых перешел на Claude Code. Сначала было непривычно, но он показался более продуманным и «умным» что ли. И тарификация более прозрачная.

Гайдов и видосов по Cursor в интернете бесчисленное множество, не буду их здесь дублировать. Просто посоветую никогда больше не пытаться написать код в обычном ChatGPT и аналогах, а использовать специально предназначенные для этого сервисы.

2. Используйте Github

Еще одна ситуация из моих первых попыток вайбкодинга.

Мы с нейронкой сделали хоть как-то работающий сервис — он действительно собирал все ссылки со страницы, проверял их и выдавал список битых. И вот я решил добавить небольшую функцию — выгрузку списка найденных ссылок в CSV-файл.

Cursor что-то там сделал — и сломалось ВСЕ. Расширение просто перестало работать.

Я пишу об этом в чате, Cursor выдает знаменитое: «Прости, сейчас я все исправлю!» — и ломает все еще больше, так что расширение даже открываться перестает.

Больше часа мы пытаемся все починить, ничего не получается, в итоге я психую, удаляю все файлы и трачу еще несколько часов, чтобы сделать сервис заново.

И это не такая уж и редкая ситуация, нейронки действительно могут что-то сломать или удалить важный файл без спроса.

Чтобы от этого подстраховаться, как раз нужен Github. Это сервис для хранения кода и всех историй его версий в облаке. Все разработчики им пользуются, и вам он пригодится.

Это как история версий в Гуглдоке. Даже если кто-то удалил часть текста, всегда можно открыть историю и откатиться к старой версии документа. Или как сохранения в играх, если вам угодно. Умер — загрузился и продолжил играть.

Хорошая новость — нейронки прекрасно умеют работать с Github. Просто напишите в Cursor что-то в духе «Я хочу подключить гитхаб к нашему проекту, напиши инструкцию, как это сделать».

Вручную вам надо только создать профиль на github.com — это бесплатно. Ну и дать нейронке доступ — она подробно распишет как, если вы попросите.

Все остальное может делать агент — создавать репозитории (папки проектов), сохранять код в облаке, загружать старые версии и так далее.

Главное не забывайте сохраняться после каждой выполненной задачи — это называется «коммит». Еще есть «пуш» — это когда мы кидаем все «сохранения» на сервер. То есть сначала все версии кода сохраняются у вас локально на компьютере (коммиты), а потом мы можете их разом запушить — и они будут храниться в облаке.

Нейронки все это знают и обычно не забывают делать коммиты и пуши, но на всякий случай будьте бдительны и напоминайте. ИИ что-то поменял — попросите его сразу закоммитить изменения.

Ну а когда нейронка что-то безнадежно сломала — попросите ее откатиться к предыдущей стабильной версии и попробовать еще раз.

На самом деле, функционал Github значительно шире, чем обычные сохранения. Например, он умеет автоматически обновлять код на сервере, хранить всякие API-ключи и пароли, с этим кодом может работать сразу несколько человек одновременно.

С этим тоже потом разберетесь, но начните хотя бы с коммитов и пушей.

3. Новая задача — новый чат

Наверняка вы слышали такое понятие, как «контекстное окно». Это, по сути, объем рабочей памяти нейросети. Чем окно больше — тем больше информации нейросеть может «удержать в голове».

У современных нейронок контекстные окна довольно большие, там помещаются сотни страниц текста и кода. Но они не бесконечные. И при активной работе заполняются довольно быстро.

Попросили агента отредактировать пару файлов — оба файла целиком попали в контекст. Попросили что-то загуглить — еще несколько веб-страниц попали в контекст. Вся история чата, все размышления агента, все скриншоты, которые вы ему присылаете, — все это тоже хранится в контексте.

Когда контекст свободен, нейросеть работает очень хорошо. Она четко следует инструкциям, редко ошибается и галлюцинирует.

Но чем больше информации загружено в контекст, тем больше начинается тупняка. Ваши инструкции и задачи просто теряются среди десятков страниц текста, кода и предыдущих задач, которыми нейронка забила свою память.

Поэтому ваша главная задача как вайбкодера — следить за контекстом и не вкидывать в агента никакую лишнюю информацию, которая отвлечет его от текущей задачи.

Представьте, что ставите задачу человеку, и помимо важных инструкций, присылаете ему кучу бесполезной информации: переписки трехлетней давности с другими людьми, какие-то несвязные обрывки текста, скриншоты уже решенных ошибок и куски кода, которые мы удалили позавчера.

Любой человек запутается в этом хламе. И нейронка тоже путается. Пожалейте ее и создавайте новый чат под каждую задачу.

У каждого нового чата свой контекст, между сессиями информация не перелетает. 

Сделали задачу, убедились, что все работает, — закрывайте чат и создавайте новый для следующей задачи. Даже если задача маленькая. Даже если контекст заполнился всего на 30%.

Так вы убережете себя от кучи глупых ошибок агентов.

Ну и постарайтесь не писать агентам всякую лишнюю информацию в духе: «да блин, ты тупая железяка, я тебя 10 раз просил это сделать, а ты все тупишь, как ты заколебал!»
Нейронка от этого лучше работать не станет, скорее наоборот. Ваш поток ругани забьет контекст, и она начнет ошибаться еще больше. Ругайтесь вслух, а агенту пишите только по делу.

4. Большие задачи разбивайте на маленькие

Этот совет логически вытекает из следующего. Чем менее заполнен контекст агента, тем лучше он работает и тем меньше ошибается. Но бывают масштабные задачи, которые затрагивают сразу много файлов, где надо написать сотни и тысячи строк кода.

Пока нейронка изучит все файлы и составит план действий, она уже забьет себе весь контекст. А мы не хотим, чтобы это произошло, мы хотим, чтобы она работала со свежей головой.

Поэтому большие задачи надо декомпозировать — разбивать на много маленьких. И каждую делать в отдельном чате со свежим контекстом.

Ну например, написание этой статьи — большая задача, тут много информации, удержать в голове все сразу сложно. Ее можно декомпозировать:

• Придумать, что это за статья, о чем и для кого

• Продумать структуру — какие советы вообще будут в статье

• Написать вступление

• Написать первый раздел

• Написать второй раздел

• Ну и так далее

Точно так же можно декомпозировать задачи по разработке. И это может сделать сама нейросеть. Так и пишите в чате: «Я хочу сделать вот это. Декомпозируй это на отдельные атомарные задачи и составь план решения каждой задачи»

Агент составит вам план — вы его сохраняете. Затем создаете новый чат, копируете туда первую задачу и просите агента сделать. Он делает, вы проверяете, что все нормально, коммитите изменения, закрываете чат. Создаете новый чат, копируете туда вторую задачу — и так далее.

Да, это сильно дольше, чем написать в чат «сделай по кайфу» и смотреть, как агент полчаса пишет тысячи строк кода, что-то запускает, меняет, еще пишет, очищает переполненный контекст, снова пишет.

Но обычно после такой автономной работы ваш проект ломается и перестает работать. А если двигаться маленькими шагами, агент будет сильно меньше ошибаться, потому что в его контексте будет только та информация, которая нужна для решения одной конкретной задачи, а не всех задач сразу.

Плюс если что-то сломается в процессе — нейронке будет проще найти проблему, ведь она внесла совсем небольшое изменение, а не переделала за один присест половину проекта.

5. Сначала планируйте — потом делайте

Все знают фразу: «Без ТЗ результат ХЗ».

И она как нельзя лучше применима к разработке, хоть с нейронками, хоть без. Если не продумать заранее, что вообще мы хотим сделать, как оно должно выглядеть и работать — то получится не целостное приложение, а неудобная мешанина из отдельных функций.

Но если опытный разработчик это понимает и может вовремя остановиться и подумать над логикой и структурой, то нейронка думать не станет. Она просто нафигачит как получится. Возможно, на первый взгляд оно даже будет работать, но внутри окажется столько багов и уязвимостей, что вы потом запаритесь их исправлять.

Поэтому любую работу я начинаю с режима планирования — такой есть и в Cursor, и в Claude Code. В Plan mode нейронка не может изменять файлы и писать код, она может только обсуждать с вами план действий.

Надо добавить какую-то функцию, поменять что-то в коде или исправить баг — я включаю Plan mode, описываю задачу и смотрю, что нейронка предложит.

Во-первых, сам по себе факт планирования существенно снижает количество ошибок агента. Он не мечется хаотично по разным задачам, снося куски кода то тут, то там, а следует намеченному плану.

Во-вторых, я не разработчик. Я не понимаю код. Я не могу посмотреть на код, который написал агент и увидеть в нем ошибку. Зато я могу понять план действий. Понять алгоритм, который предложила нейронка и подумать, насколько он вообще кажется логичным. Погуглить ее решение или обсудить с другой нейронкой в соседнем чате.

В конце-концов, могу попросить нейронку разжевать план «для дураков». Так и пишу: «я не разработчик и не понимаю, что ты предлагаешь. Напиши проще, что мы будем делать, зачем, почему это лучшее решение»

Иногда после таких объяснений я вижу явные дыры в логике нейронки. Иногда я вижу более простой способ что-то сделать — не на уровне кода, а на уровне алгоритма. Иногда я понимаю, что мы вообще идем не туда, закрываю чат, создаю новый и пытаюсь сформулировать задачу другими словами.

А иногда план кажется понятным и логичным — и я прошу агента его реализовать.

Еще прикольно просить Cursor или Claude покритиковать самого себя.

«Вот ты предложил план, давай подумаем, какие тут могут быть подводные камни, что может пойти не так. Что нам сделать, чтобы ничего не сломать? Действительно ли это лучший способ решить задачу? Какие еще есть варианты?»

Так агент планирует действия более вдумчиво и совершает меньше дурацких ошибок в духе «ой, я удалил функцию, которая, оказывается, была нужна».

6. Spec driven development

Прошлый раздел был про маленькие задачи. Составили план, сделали, забыли.

Но ведь бывают и большие задачи, которые ну никак не влезут в контекстное окно одного чатика. Их надо декомпозировать, а потом как-то связать все мелкие задачки друг с другом, спланировать все вместе, сделать, не потерять ничего в процессе.

Для больших задач мы составляем подробное техзадание. И не просто обсуждаем его в чате с нейронкой, а сохраняем в отдельный файл, чтобы ничего не потерялось.

• Что надо сделать

• Как это должно работать

• Какие инструменты нам понадобятся

• Какая информация нам потребуется

• Как должен выглядеть результат

• Из каких шагов состоит реализация

• Что надо сделать на каждом из шагов

• Как мы поймем, что все работает как надо

• Как ничего не сломать в процессе

Такое техзадание в разработке называется spec — от слова specification, спецификация.

По сути, это просто более продуманный и подробный план, такой же, как вы составляете с нейронкой в Plan Mode. Только хранится в отдельном файле.

И этот файл не теряется между сессиями, вы можете носить его в каждый новый чат и говорить: «Вот спецификация, работаем по ней. Мы уже сделали 1, 2, 3, теперь делаем 4. Изучи все и погнали делать»

Так как вы не разработчик, то даже не пытайтесь написать спек самостоятельно. Его должна составлять нейронка на основе ваших объяснений:

1. Вы объяснили простыми словами, что хотите сделать, попросили агента задать уточняющие вопросы

2. Он задал, вы на них поотвечали и попросили написать детальный спек

3. Агент написал спецификацию, показал вам

4. Вы поспрашивали все, что вам непонятно — в отличие от живых разработчиков, агент обладает железным терпением и готов бесконечно отвечать даже на самые идиотские вопросы

5. Внесли изменения, согласовали

6. У вас есть готовая спецификация, по которой нейронка будет писать код

Такой подход к разработке называется spec driven development. Когда я начал работать по нему, у меня значительно сократилось количество глупых ситуаций, когда нейронка что-то сделала, потом сломала, потом «ой-ой, щас поправлю» — и сломала еще сильнее.

Есть много готовых методологий и настроек для агентов, чтобы «обучить» такому подходу к работе. Например, вот — spec kit. Можно кинуть эту ссылку в Cursor или Claude Code, попросить все установить и объяснить вам простыми словами, как по этой методологии работать. 

Но я не стал так заморачиваться. Я вместе с агентом составил шаблон спека в удобном для меня формате — и на этапе планирования кидаю в чат этот шаблон и прошу его заполнить.

Это просто текстовый markdown-файл. Вот кусочек такого файла из моего проекта.

Здесь я хочу поменять в своем боте ChatGPT-mini на Claude Haiku.

Это общий файл, который описывает большую задачу целиком — что мы делаем, зачем, как должно работать, из каких шагов состоит.

У каждого шага тоже есть свой markdown-файл — там написан уже конкретный план для нейронки, что надо сделать, что и где изменить.

Дальше я просто открываю новый чат, кидаю туда спек и файл первой задачи — и прошу сделать. Потом новый чат и вторая задача, третья и так далее, пока все не будет готово.

Я прошу нейронку писать спеки и всю документацию на английском. Английский язык занимает чуть меньше места в контексте агента, то есть на больших задачах нейронка чуть меньше тупит. Плюс я лишний раз тренирую язык. Но это необязательно, можно и на русском все писать.

Повторюсь. Планирование — это критически важный шаг. Если вы не разработчик, вы просто не поймете, что сделала нейронка, насколько это адекватно, не сломала ли она что-то в процессе. А план можно разжевать максимально подробно, понять и согласовать все решения, увидеть потенциальные проблемы и так далее.

Плюс так вы будете потихоньку учиться. Несколько раз агент объяснит вам на пальцах, почему надо делать так, а не иначе, — вы запомните. Со временем сможете общаться с агентом на техническом языке, ставить ему более понятные задачи и более явно видеть потенциальные ошибки.

7. Ведите базу знаний проекта

Окей, мы разобрались, что не надо бесконечно терзать агента в одном единственном чате, потому что его контекст переполнится, и он начнет тупить.

Но появляется другая проблема. Каждый новый чат — это чистый лист. Агент ничего, буквально ничего, не знает о вас, ваших задачах, проекте и так далее.

Как будто у вас разработчик с амнезией — после каждой задачи прилетают люди в черном, стирают ему всю память, и ему надо заново разбираться, что мы тут делаем, как устроен проект, какие файлы тут есть и где они лежат.

Во-первых, это очень долго. Вы каждый раз ждете по 5-10 минут, пока Cursor разберется, что к чему.

Во-вторых, далеко не факт, что он разберется. Он может не найти какую-то функцию и придумать ее еще раз. Может еще раз совершить ошибку, которую совершали уже 10 раз до этого. Может удалить какой-то файл, потому что не понял, зачем он нужен.

Ну и в-третьих, все эти погружения в проект жрут огромное количество контекста. По сути, Cursor должен каждый раз изучить ВЕСЬ ваш код. Когда проект большой, в него физически не влезает столько информации, и контекст переполняется еще до начала работы.

На помощь приходит документация по проекту. Кто-то называет ее memory bank (внешняя память агента), кто-то — knowledge base (база знаний). Суть одна — мы пишем для агента систему инструкций, чтобы он при старте новой сессии мог быстро разобраться в проекте и не потерял ничего важного.

В каждом агенте для кодинга есть готовый простенький инструмент для организации базы знаний. В Cursor и Claude Code это команда /init. Она создает в папке проекта markdown-файл Cursor.md, Claude.md или что-то такое, смотря каким агентом пользуетесь. И в этом файле нейронка описывает ваш проект:

• Что мы делаем, зачем оно надо

• Как устроен проект, какая у него архитектура, стек технологий

• Что уже сделано, как оно работает

• Какие функции у нас есть и зачем

• Что хранится в каждом файле

• и так далее

Каждый раз, когда вы запускаете новый чат, в него автоматически закидывается этот файл с базовой информацией по проекту — и нейронка как бы проходит онбординг.

Для маленьких проектов этого более чем достаточно. Просто периодически запускайте команду /init, чтобы агент обновлял базу знаний. Ну или попросите явно в чате: «Это важно, добавь об этом заметку в Claude.md».

Еще раз, Cursor.md, Claude.md и прочие подобные файлы — это инструкции, которые всегда есть в контексте агента, они попадают туда автоматически при запуске агента.

С большими проектами проблема остается. Файл с базой знаний становится настолько огромным, что забивает контекст, и нейронка путается уже со старта новой сессии.

Например, нам надо просто поменять цвет кнопки в приложении, но нейронке в контекст попадает информация про всю бизнес-логику, размещение на сервере, базу данных, архитектуру, паттерны кода и так далее.

Звучит не очень.

Поэтому для больших проектов базу знаний лучше разбивать на несколько файлов. В одном у нас базовая информация о проекте, которая нужна в любом чате. В другом все про сервер — подключаем, когда работаем с сервером. В третьем — все про дизайн, подключаем, когда работаем с дизайном.

Например, у меня на проектах структура базы знаний такая:

• project — что мы вообще делаем, какую проблему решаем, для кого, какие основные функции

• architecture — стек технологий, структура папок, ключевые зависимости, внешние интеграции

• patterns — как писать код в этом проекте плюс общие правила, которые кочуют из проекта в проект

• features — список функций с приоритетами и статусами: готово, в работе, запланировано

• database — схема базы данных и вся информация по работе с ней

• deployment — на каком сервере работает проект, как туда попасть, как все устроено

• business-rules — разная важная логика, описание, как работают ключевые функции в проекте

• ux-guidelines — гайд по текстам в интерфейсе и дизайну

• git-workflow — как работаем с Github, общие правила на все проекты

• monitoring — как посмотреть статус сервера, где лежат логи и так далее

• roadmap — план развития проекта

А в Claude.md просто описана структура базы знаний, в какие файлы по каким вопросам ходить.

В итоге работа выглядит так:

1. Я создаю новый чат

2. В него автоматически попадает Claude.md, где написано «вот тут лежит документация по проекту, если будешь делать это, то прочитай этот файл, а если будешь делать это — то этот»

3. Агент получает от меня задачу

4. Понимает, какая информация ему нужна

5. Открывает соответствующий раздел базы знаний, онбордится и предлагает решение

8. Пусть агент проверяет сам себя

Я уже упоминал про это в разделе про Plan Mode, но расскажу еще раз.

Если вы не разработчик, вам тяжело понять, что нейронка накодила, как это оценить и проверить. Поэтому просите нейронку вам с этим помочь.

Получили план — попросите агента оценить план, подумать, действительно ли это лучшее решение. Пусть он опишет, какие есть подводные камни, какие проблемы могут возникнуть, какие есть риски, как еще можно решить эту задачу.

Составляете спек — пусть агент пропишет для каждой задачи критерии оценки и чек-лист для самопроверки. А после выполнения пройдется по чеклисту и проверит, что действительно сделал все, что хотел.

Это же работает и с готовым кодом. Я не могу его понять и оценить, но агент-то может! Поэтому после больших задач я открываю новый чат и прошу агента провести аудит кода: найти потенциальные проблемы и уязвимости, неиспользуемые функции, несоответствия нашим правилам, описанным в базе знаний, и так далее.

А дальше на основе аудита можно составить новое техзадание — и отправить агента исправлять все косяки. 

Плюс с таким подходом вы начинаете понемногу разбираться в том, что делаете, хаха. Агент пару раз сказал, что «нельзя хардкодить секреты, это очень важно, срочно переделываем», вы запомнили, и потом без всяких нейросетей сможете видеть проблемы в планах и спеках, которые показывает вам Cursor. 

9. Просите агента писать тесты

Типичная ситуация. У вас есть работающий сервис с живыми пользователями. Вы просите нейронку что-то в нем поменять. Нейронка меняет, и все на первый взгляд работает.

А через неделю оказывается, что в процессе изменений сломалась, например, оплата. А вы не заметили, потому что ну не будешь же проверять вручную каждую функцию после каждого изменения.

Вот эту проблему решают тесты.

Это такие маленькие программки, которые запускают какую-то функцию в вашем проекте и проверяют, что она работает как надо. Поменяли что-то, запустили тесты — все работает. Еще раз поменяли, запустили — одна функция сломалась, мы случайно задели кусок кода, которые за нее отвечал.

Вручную за всем этим не уследишь, особенно на больших проектах, где десятки, сотни и тысячи функций. А автоматические тесты можно хоть после каждой задачи запускать и проверять, что все ок.

И конечно же, агенты умеют писать тесты. Умеют, но ленятся и не пишут, если их явно не попросить. Поэтому при работе напоминайте им:

• Добавьте правило в базу знаний, что на каждую функцию надо написать тесты и запускать их после каждой задачи

• Напоминайте сделать тесты, когда составляете план выполнения задачи

• Добавьте правило в шаблон спека — мол, под каждую задачу пишем тест, и это надо запланировать еще на этапе ТЗ

Заодно можно попросить агента настроить Github, чтобы при каждом коммите (сохранении) все существующие тесты запускались автоматически. Нейронка может про них забыть, а Github уж точно не забудет. Еще и оповестит агента, что какой-то тест не прошел.

Со временем разберетесь, какие тесты бывают, но для начала — просто просите агента писать хоть какие-то. Это уже значительно повысит стабильность ваших проектов.

10. Просите агента писать логи

Опять же, типичная ситуация. Вы попросили нейронку что-то сделать, она сделала. Вы запускаете сервис, а он не работает.

Вы говорите об этом агенту — и он полчаса мечется по всем файлам, не понимая, что именно сломалось, и хаотично вносит рандомные изменения. И ломает все еще сильнее.

Чтобы такого не было, попросите нейронки логировать все важные функции. Грубо говоря, мы добавляем в код команды, которые пишут в специальный файл (лог) отчет о работе вашего приложения.

Нажали на кнопку — в логе появилась запись «кнопка нажалась, выполнилась вот такая функция, все успешно». Или «кнопка нажалась, но ничего не сработало, ошибка»

Когда что-то идет не так, агент просто открывает эти логи и сразу же понимает, что именно сломалось, где скрылся баг, какая именно функция не сработала как надо.

Иногда агенты добавляют логирование в код автоматически, но иногда об этом забывают. Поэтому просто попросите нейронку добавить в документацию и все спеки правило в духе «Логируй все важные функции».

И все, больше вам можно об этом не думать. Вы просто будете знать, что нейросеть исправно добавляет в код логирование, и в случае чего сможет быстро найти ошибку. Я, например, ни разу за полгода не смотрел логи сам. Я просто прошу Claude открыть логи и разобраться, в чем проблема.

11. Никогда не делитесь с нейронкой секретами

Секреты — это всякие пароли и API-ключи. С ними ваше приложение может подключиться к какому-то сервису и что-то там сделать.

Но если секрет попадет в руки мошенников, он сможет авторизоваться от вашего имени и создать много проблем.

Получит доступы от вашего сервера — сможет украсть весь код или сломать его, заразить вирусами. Получит ваш API-ключ — сможет использовать его от вашего имени для своих темных дел. Например, бесконтрольно тратить деньги с вашей карты, подключенной к стороннему сервису.

Короче, секреты на то и секреты, что никому не надо их показывать.

И проблема в том, что нейросеть может по дурости их слить куда-то, где до них доберутся мошенники. Например, вписать в незашифрованном виде прямо в код (это называется хардкод), а потом «случайно» изменить тип вашего репозитория с приватного на публичный.

Тут вам просто надо запомнить 2 правила:

1. Не пишите секреты в чате с нейронкой. Просите ее создать специальный файл .env — а уже в него вы вручную вставите свой пароль или API-ключ

2. Напишите в базе знаний, например, в Claude.md правила — никогда не просить секреты в чате, никогда не хардкодить их и не добавлять в логи, всегда добавлять .env в gitignore (этот файл не будет улетать в облако, останется только у вас на компьютере)

А когда разберетесь с GitHub чуть получше, попросите агента хранить все секреты в защищенном виде в GitHub Actions. Просто напишите в чате про это — нейронка расскажет, как это делать, и поможет все настроить.

12. Делайте команды для повторяющихся действий

Ну и последний совет — он не про надежность и не про качество работы, скорее про удобство и экономию времени.

В вайбкодинге, как и в любой другой работе, есть много шаблонных повторяющихся действий.

Создали чат → попросили агента почитать базу знаний → взяли шаблон спека → провели интервью → заполнили спеки → разбили его на задачи и так далее. И так каждый раз, для каждой новой функции, каждого изменения кода.

Раз на 5-й вас уже будет тошнить снова описывать нейронке одну и ту же задачу и давать ссылки на одни и те же файлы.

И это повод сохранить часто используемые инструкции. Чтобы не писать заново, а просто скопировать готовый промт — и все.

В Cursor, Claude Code и прочих подобных сервисов для этого есть команды. Пишете в чате /команда — и в контекст агента попадает заранее заготовленная инструкция.

Команда — это просто markdown-файл, который лежит в специальной папке. Можно создать их вручную, можно попросить агента в чате: «сделай команду такую-то, которая будет делать вот это и это»

Описали один раз, как правильно делать спек, создали команду /new-spec — и наслаждаетесь. И такие команды можно делать под любые повторяющиеся задачи: провести аудит кода, обновить документацию, декомпозировать спек на подзадачи, создать новый проект по шаблону и так далее.

У меня, например, есть команда /meta-context, которую я ввожу, когда хочу поправить какие-то команды, шаблоны и так далее. Она вгружает в агента информацию, что сейчас мы будем работать не над текущим проектом, а над глобальными настройками Claude Code, которые действуют на всех проектах сразу.

Работать можно и без этого, но с командами как-то поудобнее.

---

Можно написать еще много советов, но пожалуй хватит. Эти кажутся мне самыми важными. Если во всем этом разобраться и начать использовать все эти штуки — вайбкодинг превратится из магии в управляемый и понятный процесс.

Ну и еще один совет напоследок — задавайте вопросы нейронке по ходу работы.

Что-то пошло не так — спросите у агента, как не допустить подобные ошибки в будущем.

Сделали сложную задачу с первого раза — спросите, как экстраполировать этот опыт на остальную работу, что надо добавить в инструкции, чтобы все все так хорошо работало.

Увидели видео «Топ-7 лучших MCP для вашего Claude Code» — попросите агента объяснить, что это за MCP такие и зачем они нужны.

Так потихоньку и разберетесь во всем.

Ну и что за статья без ссылки на Телеграм-канал. У меня есть канал на 24к человек, где я рассказываю про бизнес, менеджмент, запуск и продвижение своих мини-проектов, нейросети и всякие другие штуки. Если вам такое интересно, заходите в гости.

Спасибо, что прочитали статью! Надеюсь, она поможет вам вайбкодить с чуть меньшей головной болью.