Как мы создали свой отдел вайб‑кодинга из бывших студентов

Вайб‑кодинг — это метод написания кода, при котором разработчик описывает желаемое на естественном, человеческом языке, а нейросеть преобразует техническое задание в код. В этом симбиозе человек зачастую даже ничего не исправляет. Он выступает в роли куратора «на вайбе», который просто дает задачу и следит за ее исполнением.

Придумал термин Андрей Карпатый, сооснователь компании OpenAI — это они подарили миру ChatGPT.

В университете «Зерокодер» есть курсы по вайб‑кодингу и промпт‑инжинирингу, и если с первым все понятно, то второе — это навык создания запросов‑промптов к нейросети настолько точных, что они не требуют правок. Некоторые из студентов, окончивших эти курсы, остались у нас и продолжили здесь работать. О них сейчас и хотелось бы рассказать.

Команда вайб‑кодинга

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

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

Почему нам понадобился свой отдел разработки

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

У нас возникла потребность в разработке внутренних инструментов, которые были бы идеально заточены именно под наши особенности работы

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

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

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

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

Насколько эффективнее стала работа

Раньше у нас многое делалось «на коленке». Что было: таблицы и формы. Чего не было: собственной разработки с использованием кода. Разные приложения приходилось делать по мере возникновения потребности, из‑за чего рабочие процессы сильно страдали. Это даже в половину не закрывало основных больших потребностей, потому что решало, в основном, всякую мелочь.

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

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

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

Как внедрить вайб‑кодинг в процессы компании

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

Начинать нужно именно с внутренних процессов, с автоматизации, как это сделали мы: CRM, аналитика, обработка данных, внутренние сервисы. Там цена ошибки ниже, а эффект — быстрый и измеримый.

Ставку нужно делать на людей. Хороший промпт‑инженер разберется с любой нейросетью — и подберет такую, которая наилучшим образом подойдет под задачи компании. В сущности, хороший «вайб‑кодер» — это продакт и аналитик в одном лице.

Идеально у нас получилось не сразу, если вообще получилось.

Идеал — некая мечта, которую невозможно измерить, и к которой зачастую невозможно прийти

Мечтать безусловно не вредно, однако вайб‑кодинг лучше всего подходит именно для прототипирования, для того, чтобы написать за несколько дней MVP, минимально жизнеспособный продукт, а уже потом решить, нужно ли переписывать проект «по‑взрослому».

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

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

Вайб‑кодинг действительно подойдет не всем и не для всего. Но в контексте внутренних продуктов, автоматизации, прототипирования и быстрой проверки гипотез он оказался мощным инструментом. Особенно если в команде есть люди, которые понимают, как работать с ИИ на уровне процессов с ответственностью за результат.