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

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

Оглавление

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

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

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

Масштаб изменения уже виден в общей статистике. В 2025 году разработчики отправили на GitHub почти миллиард коммитов — зафиксированных изменений кода, — на 25,1% больше, чем годом ранее. Они объединили 518,7 миллиона pull request — наборов изменений, принятых в проекты, — на 29% больше, чем годом ранее. Более 1,1 миллиона публичных репозиториев используют LLM SDK, программные библиотеки для работы с языковыми моделями.

Внутри Anthropic к маю 2026 года Claude создавал более 80% кода, который компания добавляла в свои системы. Средний инженер выпускал в восемь раз больше строк кода в день, чем в 2024 году. Сама Anthropic отдельно отмечает, что количество строк не равно качеству и завышает реальный прирост производительности. Эти данные не описывают весь рынок, но показывают, насколько резко AI изменил производство кода внутри одной компании.

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

Первое работающее приложение перестало быть главным барьером

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

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

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

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

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

Опыт нужен не для того, чтобы быстрее печатать код

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

ОбластьЧто видно в первой версииЧто появляется в реальном продукте
ПродуктОсновной сценарий работаетРазные пользователи, состояния, ограничения и исключения
Данные и доступДанные сохраняютсяКто что видит, как связаны записи и что произойдёт со старыми данными после обновления
Связь с другими сервисамиСервис отвечает на запросЗадержки, повторные запросы, ошибки и несовпадение статусов
НадёжностьСценарий один раз прошёлПотеря сети, восстановление, журналы ошибок, резервные копии и откат
Работа после запускаПриложение запущеноБезопасные обновления, обнаружение проблем и поддержка пользователей

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

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

Как один сценарий Мементо превратился в полноценный продукт

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

Но каждое слово в этом описании постепенно раскрывается в отдельную систему решений.

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

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

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

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

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

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

Как использовать вайб-кодинг правильно

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

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

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

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

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

Что изменилось в профессии разработчика

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

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

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

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

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

Что делать со своей идеей

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

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

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

Другие материалы о разработке таких систем собраны в разделе «Практика AI и цифровых систем».

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

Источники