2 февраля 2025 года Андрей Карпаты (Andrej Karpathy), исследователь в области ИИ и один из основателей OpenAI, написал в X пост, который дал название целому явлению. Он описал новый способ программирования: полностью отдаться «вайбу», диктовать задачи нейросети голосом, почти не касаясь клавиатуры, принимать все ее правки и забыть, что код вообще существует. В том же посте он сам оговорился, что для одноразовых проектов на выходные это «не так уж плохо», и признался, что больше не читает диффы — списки изменений в коде.
Слово прижилось. Теперь «вайб-кодингом» называют почти любую разработку, где код пишет нейросеть по описанию на обычном языке. И для бизнеса это действительно открыло новые возможности: собрать лендинг, внутренний инструмент или прототип можно без команды разработчиков. Но оговорка Карпаты про проекты на выходные никуда не делась. Разберу, что бизнес может собрать сам и где без разработчика проекту трудно дойти до запуска.
Что такое вайб-кодинг
Вайб-кодинг — это когда вы описываете словами, что хотите получить, а нейросеть пишет код. Вы смотрите на результат, говорите, что поправить, и так по кругу. В код при этом можно не заглядывать: оцениваете то, что видите на экране.
Для этого используют чаты вроде ChatGPT или Claude, ИИ-агентов для кода и специальные сервисы, которые собирают приложение по описанию и сразу показывают результат.
Сильная сторона подхода — скорость первой версии. То, что раньше требовало заметной работы разработчика, теперь собирается гораздо быстрее. Слабая — все, что происходит после первой версии. Когда вы не читаете код, вы не знаете, как устроено то, что получилось, и каждая следующая правка может сломать что-то в неожиданном месте.
На практике сессия вайб-кодинга выглядит так. Вы пишете: «Сделай страницу с формой записи на консультацию». Нейросеть выдает код, вы открываете результат и видите, что кнопка не того цвета, а поле телефона принимает буквы. Пишете об этом, получаете исправленную версию, снова смотрите. Через несколько кругов страница выглядит так, как нужно. Что именно изменилось в коде за эти круги, вы не знаете, и в этом вся суть подхода. И его главный риск.
Важно и то, что нейросеть почти никогда не отказывается. Попросите добавить оплату, личный кабинет или интеграцию с CRM, и она напишет код. Вопрос не в том, напишет ли, а в том, будет ли этот код надежным, когда им начнут пользоваться настоящие клиенты.
Вайб-кодинг и вайб-блок Тильды — не одно и то же
У Tilda есть вайб-блок: блок в библиотеке, который генерирует свое содержимое с помощью ИИ по запросу в чате. Результат можно дорабатывать — менять контент, стиль или код, а также конвертировать в Zero Block (функция в бета-тестировании). Это инструмент внутри конструктора: он создает отдельный блок на странице Tilda, а хостинг, формы и остальная инфраструктура остаются за платформой. Вайб-кодинг в широком смысле — это разработка целого сайта или приложения, где все эти вопросы приходится решать самостоятельно. Сама я вайб-блоки не использую: для разработчика это легкий путь, но для клиента — мина под дальнейшее обслуживание сайта, ведь он и его менеджеры получают в редакторе непонятное содержимое. Мой принцип — чтобы страница в редакторе, в Zero Block, выглядела максимально так же, как опубликованная, и ее можно было понятно править. К тому же функция пока в режиме тестирования: сама Tilda предупреждает, что для правки кода вайб-блока нужны базовые знания HTML, CSS и JavaScript, поддержка по коду не консультирует, а конвертация в Zero Block в бета-версии.
Что бизнес может собрать сам
Лендинг
Одностраничный сайт — самый понятный вариант. Структура простая, логики мало, результат легко проверить глазами. Нейросеть соберет страницу с блоками, текстами и адаптивной версткой, а дальше нужно разместить ее на хостинге и подключить форму.
Где подстерегают проблемы: форма, которая выглядит рабочей, но никуда не отправляет заявки; страница, которая хорошо смотрится на компьютере и ломается на телефоне; тексты, где нейросеть добавила обещания, которых вы не давали. Все это решаемо, если проверять.
Разумный порядок для лендинга такой: сначала структура и тексты, которые вы проверили сами, потом код, потом проверка на телефоне, потом размещение и тестовая заявка. Если на каком-то шаге становится понятно, что задача сложнее, чем казалось, — например, нужна запись с выбором времени или оплата, — это хороший момент остановиться и подумать, не взять ли конструктор или разработчика.
Внутренний инструмент
Самая удачная область для вайб-кодинга в бизнесе — инструменты для себя. Калькулятор для менеджеров, таблица учета заявок с удобным интерфейсом, генератор коммерческих предложений по шаблону, простая панель с ключевыми показателями из таблицы.
Почему это удачная область: пользователи — свои сотрудники, которые сообщат об ошибке; данные часто не выходят за пределы компании; если что-то сломается, это неприятно, но не критично для клиентов. И главное: такие задачи часто годами не доходят до разработчиков, потому что слишком мелкие. Вайб-кодинг позволяет решить их самостоятельно.
Одна оговорка: «внутренний» не значит «без персональных данных». Если в вашей таблице заявок есть имена и телефоны клиентов, то и внутренний инструмент работает с персональными данными. Тогда стоит подумать, где он размещен, кто к нему имеет доступ и не окажется ли он случайно открыт для всех по ссылке.
Прототип сервиса
Прототип — это рабочая модель идеи, которую можно показать клиентам, партнерам или разработчикам. Не для запуска, а для проверки: нужно ли это людям, как они пользуются, что непонятно.
Для прототипа вайб-кодинг подходит идеально: скорость важнее качества кода, а выбросить и переделать не жалко. Прототип мини-приложения, личного кабинета, каталога можно собрать и проверить на живых людях до того, как вкладываться в полноценную разработку.
Где нужен разработчик
Данные клиентов и доступы
Как только в проекте появляются данные клиентов — имена, телефоны, адреса, история заказов, — ошибка перестает быть мелкой. Утечка данных из-за неправильной настройки, доступ к чужому личному кабинету, пароли в открытом виде в коде — нейросеть может допустить любую из этих ошибок, и в вайб-кодинге их некому заметить.
Сюда же относятся доступы: ключи к сервисам, пароли от баз данных, токены. Нейросеть может вписать их прямо в код, который потом окажется в открытом доступе. Разработчик знает, где такие вещи хранить и как проверить, что они не утекли.
Оплата и интеграции
Прием платежей, связь с CRM, обмен данными со службой доставки, отправка чеков — каждая такая интеграция имеет свои правила, ограничения и способы сломаться. Ошибка в оплате означает потерянные деньги или недовольных клиентов. Ошибка в интеграции — потерянные заявки или неверные данные в другой системе.
Нейросеть напишет код интеграции по документации, но проверить, что он правильно обрабатывает ошибки, повторы и пограничные случаи, без понимания кода сложно.
Изменения через полгода
Самое недооцененное. Первая версия работает, все довольны. Через полгода нужно добавить функцию, поменять логику, обновить устаревшую библиотеку. И выясняется, что никто не знает, как устроен код. Нейросеть, которой вы описываете новую задачу, тоже этого не знает: она видит код впервые и может предложить изменение, которое сломает что-то в другом месте.
Чем дольше проект живет и чем больше в нем правок, тем сильнее это проявляется. Код, который никто не читал, со временем становится кодом, который никто не может безопасно изменить.
| Задача | Самому | С разработчиком | Почему |
|---|---|---|---|
| Лендинг без сложных форм | Да | По желанию | Мало логики, легко проверить |
| Внутренний калькулятор или таблица | Да | По желанию | Свои пользователи, данные внутри |
| Прототип для проверки идеи | Да | Не обязательно | Цель — проверка, а не запуск |
| Личный кабинет с данными клиентов | Прототип | Да | Безопасность данных и доступов |
| Прием оплаты | Нет | Да | Ошибки стоят денег |
| Интеграции с CRM и сервисами | Прототип | Да | Обработка ошибок и повторов |
| Проект, который будет развиваться | Первая версия | Да | Код нужно понимать, чтобы менять |
Как понять, что прототип пора передавать в разработку
Прототип сделал свое дело, если на нем удалось проверить идею. Дальше стоит честно посмотреть на признаки, что пора звать разработчика.
Первый признак — появились реальные пользователи и их данные. Пока прототипом пользуются коллеги на тестовых данных, ошибки не страшны. Когда приходят клиенты с настоящими телефонами и адресами, ответственность меняется.
Второй — нужна оплата или интеграции с внешними системами. Это то место, где ошибки стоят денег или заявок.
Третий — каждая новая правка ломает что-то старое. Если вы замечаете, что исправляете одно, а ломается другое, код стал слишком запутанным, чтобы вести его вслепую.
Четвертый — вы боитесь что-то менять. Это верный знак, что вы уже не контролируете проект.
Пятый — проект нужен надолго. Если инструмент должен работать и развиваться годами, его код должен быть понятен человеку, а не только нейросети.
Передавать прототип в разработку — не значит признать неудачу. Наоборот: работающий прототип — лучшее задание для разработчика. Он показывает, что нужно сделать, как это должно выглядеть и как пользователи с этим работают. Это гораздо понятнее любого текстового описания.
Есть и промежуточный вариант: показать прототип разработчику на аудит. Он посмотрит код, отметит, что можно оставить, что опасно и что придется переписать. Иногда выясняется, что основа вполне рабочая и нужно доделать только безопасность и интеграции. Иногда — что проще написать заново, используя прототип как образец. В обоих случаях решение принимается на основе понимания кода, а не надежды.
Если ваш прототип дошел до этой точки, посмотрите на нестандартную разработку. Если это приложение внутри Telegram — на разработку Telegram Mini App. А обсудить, что делать с прототипом, можно через квиз на mara-craft.com: я посмотрю, что в нем можно оставить, а что лучше переделать.