Вайбкодинг: с чего начать, чтобы не бросить на полпути

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

Работает второй. Первый стоит с июля и не запущен.

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

Сразу скажу, кому пишу. Ты эксперт в своём деле: юрист, бухгалтер, врач, проектировщик. Ты не программист и становиться им не собираешься. Тебе нужен инструмент под свою работу, а не профессия.

Что такое вайбкодинг и откуда берётся ложное чувство скорости

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

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

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

Минусы вайбкодинга видно только на сложном проекте

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

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

Каждая правка ломает соседнее. В простом проекте связей мало. В сложном изменение в распознавании текста роняет расчёт, а тот роняет отчёт. Чинишь одно, получаешь два новых.

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

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

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

Кейс: бот, который встал. Реальные цифры

Я собирал телеграм-бота: дневник питания, распознавание еды по тексту, планы тренировок, ИИ-тренер. Звучит как понятная задача.

Вот что получилось на деле, цифры из самого проекта, не по памяти:

• 257 файлов с кодом, 41 163 строки
• 105 файлов тестов
• 19 таблиц в базе
• четыре базы данных со справочниками еды, около 15 мегабайт
• последний коммит 5 июля

А теперь вторая колонка тех же цифр, про людей:

• пользователей в базе: один, это я сам
• записей в дневнике питания: 17
• тренировок: 1
• событий всего: 736

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

Где именно встало: распознавание того, что человек написал про еду. «Две котлеты и рис» надо превратить в граммы, калории и белок. У каждого продукта свои меры: штуки, ложки, «полтарелки». Я закопался в это в июне и не вылез.

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

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

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

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

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

Инструмент тут ни при чём. Тот же инструмент на другом проекте работает отлично. Не тот проект был выбран первым.

Почему вайбкодинг сайта это правильный первый проект

Второй проект это сайт юридической практики. Тот же подход, тот же способ работы, но начат с другого конца.

Цифры для сравнения:

• 148 сохранённых версий с 12 июля по сегодняшний день, то есть работа не прерывалась
• 10 страниц для посетителей и 31 статья
• живёт в проде: домен, почта, задачи по расписанию, возможность откатиться на любую прошлую версию
• внутри работает разбор входящих заявок

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

Разница с ботом принципиальная. У сайта есть естественная точка запуска: он открылся, форма работает, заявка пришла на почту. Всё остальное это улучшения, которые можно делать бесконечно, но уже на живом.

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

Поэтому если начинаешь, начинай с того, что можно открыть.

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

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

Как его запускать, если в поиске тебя нет

Первый вопрос после запуска обычно такой: сайт есть, а люди откуда?

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

Поэтому трафик берётся не из поиска, а из регулярных публикаций. Схема простая и повторяемая: один материал разбирается на форматы и расходится по каналам, где твоя аудитория уже есть. Статья становится постом, пост становится коротким роликом, ролик уходит в несколько сетей сразу. Не «пишем куда придётся», а один поток, из которого каждый канал берёт своё.

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

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

Чем собирать: Claude Code и Codex

Теперь конкретно про инструменты, потому что вопрос «чем делать» встаёт первым.

Основную работу веди в Claude Code. Это инструмент, который держит весь проект целиком и работает по инструкции, которую ты один раз написал в файле. Для сайта под свои услуги этого хватает от первой страницы до выкладки в интернет: вёрстка, форма, почта, публикация.

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

Разделение появилось не из обзоров, а потому что я попробовал оба на одном проекте и оставил каждый там, где он сильнее. На сайте юридической практики это выглядит так: весь код и тексты через Claude Code, и рядом семь отдельных заданий для Codex на картинки.

Вайбкодинг для непрограммистов: последовательность, которая доводит до конца

Это не «поставь конструктор и готово». Это порядок, который я вывел на двух проектах.

Шаг 1. Выбери проект с естественным финишем. Спроси себя: как я пойму, что он готов? Если ответ «когда доделаю все функции», проект не годится для первого.

Шаг 2. Опиши результат словами, до всякого кода. Одна страница текста: что человек делает, что получает, куда приходит заявка. Это станет заданием.

Шаг 3. Заведи файл правил рядом с проектом. Туда пишешь, как что называется, какого стиля держаться, чего делать нельзя. Инструмент будет читать его каждый раз. Без этого он на десятый день начнёт противоречить сам себе.

Шаг 4. Собирай кусками, каждый из которых можно проверить. Не «сделай сайт», а «сделай страницу с формой», посмотрел, работает, дальше.

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

Шаг 6. Поставь систему контроля версий с первого дня. Это кнопка отмены для всего проекта: каждая сохранённая версия это точка, куда можно вернуться. Сломалось после правки, откатился, а не разбираешь руины.

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

Шаг 8. Записывай каждое решение в тот же файл правил. Через месяц ты не вспомнишь, почему сделал так. Инструмент тем более. Этот файл со временем и становится твоим агентом.

Шаги с третьего по восьмой это и есть разница между «поиграл и бросил» и «работает и не разваливается».

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

У меня рядом с проектом набралось восемьдесят семь файлов с инструкциями, правилами и отчётами, и инструмент их читает.

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

Чек-лист: стоит ли начинать именно этот проект

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

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

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

Последний пункт я в своё время провалил. Полтора месяца строил, а потом три месяца не мог заставить себя вернуться. Один пользователь в базе это не «пока мало», это диагноз, поставленный на старте.

Если коротко

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

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

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