Что меня ждало, когда я решил стать вайб‑кодером

Привет! Я Женя, тимлид одной из команд Альфы. В банк я пришёл разработчиком в июле 2023-го, сейчас управляю разработкой сервиса «Подбор» HR‑Tech‑платформы Alfa People. Про вайб‑кодинг слышал давно — соцсети завалены роликами, где наперебой рассказывается, как за пять минут собрать стартап с ИИ. Я был скептиком: понимал, что такое энтерпрайз-система, где за каждым релизом — десятки согласований, техдокументация и ответственность за чужие данные.

Но однажды в марте этого года прошла новость: Альфа заводит в контур GLM‑5 с плагином KiloCode для редактора кода. Руководители разработки в HR Tech раздали доступ 15 разным командам и попросили собрать на вайб-кодинге что-нибудь полезное — сервис каждая команда придумывала сама. И, что интересно, со мной в команде оказались такие же, как и я — лютые скептики. Видимо сделали специально, чтобы проверить, кто из нас первый сдастся (шутка!).

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

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

Первая проблема — а что вайб-кодить?

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

Я предложил конструктор процессов с визуализацией в духе Miro — штука, провал которой бизнес бы не убил. Маша зашла с другой стороны и захотела собрать сервис для рекрутеров прямо внутри Alfa People — но это оказалось слишком большой задачей.

Тогда мы заглянули в мастер-план и наткнулись на задачу «Цели на испытательный срок», запланированную на конец года. Из неё идея и выросла — в сервис для постановки целей всем сотрудникам банка, «Мои цели». Расчёт был простой: заодно закрыть реальную задачу из плана и обкатать вайб-кодинг на живом продукте, а не в учебной песочнице.

Сроки поджимали с самого начала. Сперва релиз назначили на 1 апреля, потом сдвинули на 26 марта, а ещё через день — на 23-е.

На раскачку оставалась пара дней, но часть работы уже была сделана: коллеги провели discovery, собрали боли пользователей и описали минимальные решения. Всё это мы отдали GLM-5 с запросом «готовь бизнес-требования». Модель выдала черновик, Маша как продакт вычистила лишнее — можно было стартовать.

Первый прототип собирали «на коленке». Маша описывала интерфейс репликами вроде «хочу зелёную кнопку справа, при клике открывается модальное окно», GLM-5 генерировал HTML, а я потом прикручивал к этому бэкенд. Так родились 19 версий, и последняя стала основой финальной разработки.

Вторая проблема — никто не говорит про Git

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

Вайб-кодеры делают проект вместе

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

Первые два дня я по шесть часов вручную разруливал мёрдж-конфликты между правками Маши и Кости. «Забрать последние изменения», «сделать пул», «запушить» для них оставались набором незнакомых слов — так что весь ИИ-поток держался на мне, потому что только я, как разработчик, понимал, что происходит в системе версий.

Третья проблема — нагрузка

Вторая проблема пришла со стороны инфраструктуры. Пилот одновременно проходили 15 команд, и все обращались к GLM‑5 через общий веб-чат. Днём модель выдавала всё медленно: ответ приходил через две-три минуты, и работать становилось невозможно.

Мы подстроились и переехали на ночь: кодили с 23:00 до 04:00, когда трафик падал и модель снова отвечала быстро. Маша уходила спать в три-четыре ночи, я сидел до часу, вставал в 8:00 — и снова садился за сервис. Позже коллеги с ИИ-платформы добавили приоритет для тех, кто работает прямо из редактора кода, но первое время выручали только ночные смены.

Четвёртая проблема — где ставить границы

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

Развязка случилась в последнее воскресенье перед дедлайном. В четыре утра Маша уснула прямо на созвоне, Костя ушёл спать, а я остался один доправлять последние баги руками — спорить с GLM-5 в чате уже не было сил. В понедельник в восемь утра я отдал сервис в поставку: релиз прошёл, оставалось закрыть три мелких корнер-кейса.

В тот же день GLM-5 ушёл на техобслуживание. Демо стояло в расписании на 17:00, KiloCode перестал работать, а в запасе было всего два часа на фикс багов. Помощи ждать неоткуда: Маша и Костя писать код без модели не умели, так что мне пришлось в одиночку бегать между фронтом и бэком.

За час до презентации я заглянул в логи и увидел, что ИТ-директор уже создал цель в сервисе и успел её отредактировать. Руки затряслись — первая мысль была про упавшую токенизацию. Но логи показали, что всё работает штатно: директор просто протестировал продукт до демо. Заодно выяснилось, что в проде заработал глобальный поиск по сотрудникам — фичу мы реализовали раньше, но к другим сервисам Alfa People ещё не подключали. Из-за маскирования данных в тестовой среде её толком не проверяли, а на проде она внезапно ожила.

На демо собрались все 15 команд — и тут проявился масштаб результата: в реальный прод за три недели вышла только наша команда. Остальные 14 показали то, что работало на локальных машинах или в тестовой среде. Я объясняю разрыв просто: другие, кажется, не сидели ночами — и сразу оговорюсь, что такой режим был нашим личным безумием, а не нормой в банке.

Результаты были уже после первой недели: в «Моих целях» набралось 10 000 уникальных пользователей, они поставили 9240 целей и прикрепили к ним 981 задачу. Позже сервис забрали развивать другие коллеги — у моей команды «Подбор» хватало своих задач, и я отдал продукт, который считал перспективным.

Пятая проблема — без программистов вы не обойдётесь

Наша команда из меня, Кости и Маши была временной. Сейчас в моей постоянной команде «Подбор» работает шесть человек — после эксперимента их разбили на две подгруппы по трое, на фронтенд и бэкенд. Разработчики периодически меняются местами, чтобы держать процесс под контролем и подстраховывать аналитиков, тестировщика и продакта. Эксперимент с вайб-кодингом в HR Tech на этом не закончился — его продолжают.

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

Главный вывод такой: в крупной компании вайб-кодинг — не замена разработчику, а инструмент в руках опытного специалиста. Без понимания архитектуры, без умения контролить Git и без готовности отвечать за релиз вы получите красивый прототип, который никто не будет (или не сможет) использовать.

Сейчас я смотрю на GLM-5 как на ассистента. Типовые задачи, которые раньше съедали по часу, я теперь отдаю модели: нарисовать кнопку, выровнять форму, написать валидатор. Пока я на созвонах — ИИ верстает, пока копаюсь в бэкенде — тот правит фронт. Получилось вести два потока разработки одновременно, и это заметно разгрузило рутину.

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

Что я могу сказать тем, кто только начинает

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

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

3. Ставьте границы своим аппетитам. Как только выясняется, что вы умеете доводить сервис до прода, начинаются бесконечные «хочу ещё вот это, другое и сделать новый продукт». Без личного стоппера — «выкатываю то, что есть, остальное после» — доработка не закончится никогда.

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