Вайб-кодинг: как создавать решения и что делать дальше.

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

Вайб-кодинг (vibe coding) – подход к разработке, при котором человек, в первую очередь, формулирует, что должно получиться, а всю техническую часть передает ИИ. Этот термин в 2025 году ввел в обиход Андрей Карпаты, бывший руководитель ИИ-направления в Tesla и сооснователь OpenAI.

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

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

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

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

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

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

Для проектной деятельности это серьезное преимущество.

Вайб-кодинг и Agile: больше итераций за меньшее время

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

Вайб-кодинг позволяет удешевить именно ранние циклы.

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

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

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

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

Есть и другие сценарии:

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

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

Почему навайбкоденный прототип – еще не готовый продукт

Мы начали сталкиваться с заказчиками, которые приходят уже не только с бизнес-требованием. Они приходят с работающим прототипом. «Мы сделали вот это с помощью ИИ. Теперь хотим встроить это в наши рабочие процессы». И по их мнению, 90% работы уже сделано, остались лишь небольшие доработки. С нашей же стороны, мы знаем, что это далеко не так.

Работающий прототип и готовый промышленный продукт – не одно и то же. Работать может практически что угодно. Промышленный продукт должен обеспечивать:

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

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

Проблема башни Дженга

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

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

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

Плохой код не обязательно выглядит как плохой продукт.

Хорошая разработка – это не только то, что работает сегодня

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

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

Что находится «под капотом»

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

Самый же главный вопрос: кто будет отвечать, если решение «упадет».

ИИ не отвечает за результат

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

Вайб-кодинг =/= конец классической разработке

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

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

А когда прототип превращается в часть реального бизнес-процесса, требования становятся другими. Тогда появляется необходимость в архитектуре, безопасности, тестировании, документации, интеграциях, мониторинге и ответственности за результат.

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

Этим мостом становятся разработчики, которые понимают: 1. Как сделать рабочий код 2. Как сделать систему пригодной для дальнейшей эксплуатации и развития.

Что делать, если вы уже навайбкодили продукт

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

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

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

Промпт 1. Инвентаризация контекста

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

Промпт 2. Восстановление функционального описания продукта

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

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

Что дальше?

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

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

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

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