Vibe-coding: метод, при котором код пишется для кайфа

TL;DR

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

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

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

В тексте: почему обычный кодинг по плану медленный и скучный, что такое vibe-coding на конкретных примерах, как определить ощущение перед началом работы, практический пайплайн от чистого файла до готовой фичи, как скармливать ощущение в Claude и Cursor чтобы AI кодил в нужной эстетике, и когда метод не работает, это важно, потому что серебряной пули нет.

Проблема обычного кодинга по плану

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

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

Многие пытаются решить эту проблему через дисциплину. Учатся планировать лучше, рисуют диаграммы, делают proof of concept перед основным кодом. Не помогает. Корень не в плане, а в самом подходе «двигаюсь по списку».

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

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

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

Что такое vibe-coding на конкретных примерах

Vibe-coding отвечает на эти три провала одним движением. Не по списку. Определяешь ощущение, которое должен давать готовый код, и кодишь в это ощущение.

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

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

Пример из практики. Клиент к LLM для рабочего проекта. Стандартный подход дал бы класс LLMClient с методами generate, stream, embed, плюс конфиг, плюс обработка ошибок. Получилось бы строк 400 нормального python-кода, всё функционально. Но выбрано ощущение «прозрачность, никакой магии, читается как короткая записка». Код пишется с этим в голове.

Получается 80 строк. Одна функция call(prompt, model, stream) и одна функция embed(text, model). Никаких классов, никаких конфигов, всё параметры в функциях. Когда смотришь на сам код, он действительно читается как короткая записка. Экономия на этом одном модуле около 5 часов, плюс через месяц при добавлении новой модели правка вносится за 15 минут вместо двух часов.

Ещё пример. Скрипт для бэкапа базы данных. Стандартный план: парсинг конфига, проверка дискового места, дамп, упаковка, отправка в S3, логирование. Выбрано ощущение «надёжность, как швейцарский нож». Это значит каждый шаг должен быть очевидным, отказывать с понятной ошибкой и иметь чёткий retry. Код получается строже обычного, но через полгода эксплуатации не падает ни разу, а конкуренты с теми же требованиями переписывают по три раза.

Как определить ощущение перед началом работы

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

Сначала задаёшь себе три вопроса. Первый, как код должен ощущаться при чтении через полгода. Лёгким? Строгим? Изящным? Минималистичным? Это первое прилагательное. Второй, какое главное качество для пользователя или другого разработчика. Скорость? Надёжность? Гибкость? Это второе прилагательное. Третий, что должно отсутствовать. Магии? Зависимостей? Лишних абстракций? Это запрет.

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

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

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

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

Практический пайплайн от файла до фичи

Как выглядит рабочий день в режиме vibe-coding. Конкретно по шагам.

Шаг первый. Открываешь новый файл. Сразу пишешь в верх комментарий с ощущением. Например: «# vibe: прозрачность, минимум зависимостей, читается за минуту». Это первая строка любого нового файла.

Шаг второй. Ниже комментарием же пишешь архитектурную визию. Не код, а описание того, как примерно будут выглядеть функции и потоки данных. Прямо в комментариях. Свободно, как записка себе. Что-то вроде «загрузка JSON, валидация через pydantic, обогащение из кеша, отправка в очередь». Это занимает пять минут.

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

Шаг четвёртый. Каждые 50-100 строк остановка, читаешь что получилось. Не отлаживаешь, а именно читаешь как чужой код. Если читается тяжело или не попадает в выбранную эстетику, переписываешь прямо сейчас, без жалости. Не дотягиваешь, а целиком сносишь проблемный кусок.

Шаг пятый. Когда модуль готов, ещё раз сверяешься с ощущением сверху файла. Если попадает, оставляешь. Если нет, либо переписываешь, либо меняешь формулу ощущения (бывает, что в процессе становится ясно: изначально сформулировано неверно). Это занимает минут десять.

Итоговая разница с обычным подходом такая. Обычный подход, 3 часа линейного кодинга, плюс 2 часа на починку багов, плюс 1 час на «потом отрефакторить, надо подчистить». Итого 6 часов. Vibe-coding, 2 часа кодинга с переделками по пути, плюс 30 минут на финальную сверку. Итого 2.5 часа. На 1000 строках экономия выходит как раз около 4 часов.

AI как инструмент vibe-coding

Здесь самое интересное. Vibe-coding отлично ложится на работу с Claude, Cursor, GitHub Copilot и подобными AI-помощниками. Они понимают эстетику лучше, чем кажется.

Делается так. В начале сессии в Claude или Cursor пишется системный промпт типа «ты пишешь код в стиле: лёгкость, скорость, никаких классов, минимум зависимостей. Каждая функция короткая, без боковых эффектов. Любую сложность ты упрощаешь до базовых операций. Если можно без библиотеки, делаешь без библиотеки». Это и есть формула ощущения, превращённая в роль.

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

Это даёт две вещи. Первое, AI работает в нужной эстетике, и проект не превращается в стилевой винегрет. Второе, экономия времени на ручных переделках. Раньше код от Claude приходилось полчаса причёсывать под свой стиль. Сейчас полчаса не нужны.

Конкретный приём. Перед началом проекта создаётся в репозитории файл VIBE.md, куда выписывается формула ощущения, три примера кода в этой эстетике из этого же проекта, и пять правил «не делай так». Этот файл скармливается в контекст Claude через .clauderc или просто как первое сообщение в сессии. AI работает в стиле всё время. На больших проектах это экономит часы каждую неделю.

Когда vibe-coding не работает

Метод не серебряная пуля. Есть три ситуации, где к нему лучше не прибегать.

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

Вторая, жёсткие регулируемые домены. Платёжные системы, медицинское ПО, банковские интеграции. Там нужны конкретные стандарты, аудит, проверяемые сертификаты. Ощущение «изящность» там нерелевантно, нужно следовать букве. Vibe-coding можно применять локально на отдельных утилитах, но не на основной логике.

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

Во всех остальных случаях, стартапы на ранней стадии, личные проекты, прототипы, R&D, скрипты автоматизации, библиотеки с одним автором, метод работает прекрасно.

Результаты в цифрах после полугода практики

Подытожим. За шесть месяцев замеров написано четыре крупных модуля и около двадцати мелких в режиме vibe-coding. Время фиксировалось в каждом проекте.

Средняя экономия времени, 4 часа на 1000 строк. Это устойчивая цифра, плюс-минус полчаса. На малых модулях экономия меньше в абсолюте, но в процентах та же, около 40% быстрее обычного.

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

Удовольствие от работы выросло субъективно сильно. Кодинг перестаёт откладываться на вторую половину дня. Раньше день начинался с почты и встреч, а код шёл после обеда через силу. Сейчас за код садятся первым делом, потому что от него прёт.

Главный вывод. Кодинг как ремесло можно превратить в кодинг как искусство, не теряя в скорости и качестве. Достаточно сменить точку отсчёта, вместо плана выбрать ощущение и писать в него. Если у тебя выгорание от рутинных задач или результаты по качеству съезжают, попробуй, метод недорогой во входе.

FAQ

Это не просто рефакторинг под красоту?

Нет. Рефакторинг, это улучшение готового кода. Vibe-coding, это способ писать код изначально под выбранную эстетику. Это разные процессы. Рефакторинг приходит после, vibe-coding идёт во время.

Что если ощущение неправильное и понимание приходит в середине?

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

Подходит ли для junior-разработчиков?

Частично. Junior часто ещё не наработал чувство эстетики кода, ему сложно сформулировать ощущение. Лучше начать с парного программирования с senior, который объяснит свою формулу. Через 2-3 проекта junior уже сможет работать самостоятельно.

Как продать метод тимлиду или менеджеру?

Не продавать как метод. Продавать как результат: меньше багов, меньше времени, больше удовольствия от работы. Дальше показывать на маленьком модуле, что выходит чище. Тимлиды любят чистоту.

Работает ли для других языков кроме python?

Метод проверен на python, go, typescript и rust. Работает везде. Ощущение, это про эстетику кода, а не про конкретные конструкции языка.

📌 Dzen (~900 слов)

Vibe-coding: как перестать писать код по плану и начать ловить кайф

Vibe-coding, способ писать код, при котором каждый рабочий день приносит удовольствие, а не выматывает. Идея простая, вместо плана функций выбираешь ощущение, которое должен давать готовый код, и пишешь под него. Звучит абстрактно, но на практике даёт конкретные цифры: 4 часа экономии на 1000 строк и на 30% меньше багов.

Разберём как до этого доходят, в чём суть и как применять.

Почему обычный кодинг по плану утомляет

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

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

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

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

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

Что такое vibe-coding и как это работает

Vibe-coding отвечает на эти три провала одним движением. Не по списку. Выбираешь ощущение, которое должен давать готовый код.

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

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

Пример. Клиент к LLM. Стандартный подход дал бы класс с методами generate, stream, embed, плюс конфиг, плюс обработка ошибок. Получилось бы строк 400. Выбрано ощущение «прозрачность, никакой магии, читается как короткая записка». Получается 80 строк, две функции call и embed, никаких классов. Через месяц при добавлении новой модели правка за 15 минут вместо двух часов.

Как определить ощущение перед началом

Это ключевой шаг. Делается так: задаёшь себе три вопроса.

Первый, как код должен ощущаться при чтении через полгода. Лёгким, строгим, изящным, минималистичным? Это первое прилагательное. Второй, какое главное качество для пользователя. Скорость, надёжность, гибкость? Это второе прилагательное. Третий, что должно отсутствовать. Магия, зависимости, лишние абстракции? Это запрет.

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

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

Рабочий пайплайн

Открываешь новый файл. Первая строка, комментарий с формулой ощущения. Вторая часть комментария, архитектурная визия в свободной форме. Не код, а описание потоков данных. Что-то вроде «загрузка JSON, валидация через pydantic, обогащение из кеша, отправка в очередь». Пять минут.

Дальше начинается код из этой визии. Не как обычно «функция роутера, потом валидация», а как поток, в том порядке, в каком сам код хочет вылиться. Каждые 50-100 строк остановка и чтение того, что получилось. Если читается тяжело или не попадает в эстетику, переписываешь сразу, без жалости.

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

AI в режиме vibe-coding

Vibe-coding отлично ложится на работу с Claude и Cursor. Пишется системный промпт типа «ты пишешь код в стиле: лёгкость, скорость, никаких классов, минимум зависимостей. Любую сложность упрощаешь до базовых операций. Если можно без библиотеки, делаешь без библиотеки».

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

В репозитории создаётся файл VIBE.md с формулой, тремя примерами кода в этой эстетике и пятью правилами «не делай так». Скармливается в контекст Claude. AI работает в стиле всё время. На больших проектах экономит часы каждую неделю.

Когда метод не работает

Три ситуации, где vibe-coding не применяют.

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

Вторая, жёсткие регулируемые домены. Платёжные системы, медицина, банки. Там нужны стандарты и аудит, ощущение нерелевантно.

Третья, команда из 10 человек без общего стиля. Каждый придёт со своим ощущением, проект развалится на десять эстетик. Метод работает в одиночку или в команде до трёх человек.

В остальных случаях работает.

Цифры после полугода

За шесть месяцев замеров написано четыре крупных модуля и двадцать мелких в режиме vibe-coding. Время фиксировалось.

Средняя экономия, 4 часа на 1000 строк. Устойчивая цифра, плюс-минус полчаса. В процентах около 40% быстрее обычного.

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

Удовольствие от работы выросло субъективно сильно. Кодинг перестаёт откладываться на вторую половину дня. За код садишься первым делом, потому что от него прёт. Если у тебя выгорание от рутины или качество съезжает, попробуй, метод недорогой во входе.

📲 TG (600-900 символов)

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

По цифрам на полугодовой практике: экономия около 4 часов на 1000 строк, багов на эксплуатации меньше примерно на 30%. Работает в одиночку и в командах до трёх человек, не работает в legacy на 200 тысяч строк и в регулируемых доменах. Отлично ложится на Claude и Cursor: системный промпт с формулой превращает AI в кодера в твоей эстетике.