Как я (внезапно) стал адвокатом вайб‑кодинга в корпорации
Привет, я Максим, лидер AI‑powered разработки. В 2024 году я пришёл в банк руководителем проектов, потом занимался партнёрскими интеграциями, а теперь привет, Enterprise Vibe Coding!

Как так получилось и что я понимаю под тем самым AI‑powered и вайб‑кодингом в корпорации — поделюсь в статье.
Как я пришёл к искусственному интеллекту
Мой путь в вайб‑кодинг начался не с написания кода, а с понимания, как работают процессы в большой ИТ‑компании. Сначала в Альфе я руководил проектом, связанным с обезличенными приложениями, потом рефакторингом легаси с 98 iOS‑разработчиками. Моя команда переписывала устаревший код, делала миграцию с оптимизацией. Со временем наш подход стал приносить видимый результат без месяцев согласований, за которые часто ругают корпорации.
Потом в Альфе появилась собственная AI‑платформа AlfaGen. Я перешёл на интеграцию AI‑продуктов, но в какой то момент понял: мне не хватает ощущения созидания.
Когда в банке стали обсуждать, как с LLM улучшить внутренние процессы, я решил попробовать себя в этой роли. Без технического образования, с дипломом менеджера и бэкграундом системного аналитика я начал плотно изучать большие языковые модели.
Почему вайб‑кодинг в пет‑проекте нельзя перенести в большую компанию
Первая шишка, которую я набил: нельзя просто взять и разрешить разработчикам юзать модельку для генерации сниппетов кода — это не вайб‑кодинг в корпоративном масштабе.
Enterprise Vibe Coding начинается с системной трансформации всей компании.
В этой самой трансформации надо увязать:
-
политику информационной безопасности и требования регулятора;
-
централизованное управление доступом и правами пользователя;
-
комплаенс и security‑first‑архитектуру;
-
работу десятков команд в параллельных ветках;
-
бизнес‑требования заказчиков.
Индивидуальный, он же классический вайб‑кодинг — это когда разработчик пишет запрос к модели своими словами и получает код.
В корпоративном вайб‑кодинге ты ещё до первой строчки кода создаёшь структурированное техническое задание, прорабатываешь архитектуру, планируешь безопасность и только потом приступаешь к генерации кода через LLM.
Состояние вайб‑кодинга в российских корпорациях мы обсуждали с Альфой, Сбером, Яндексом и red_mad_robot — можно посмотреть видео или попросить пересказать нейросетку, если нет времени.
Да кто такая эта ваша ИИ‑трансформация?!
На старте проекта мы рождали идеи буквально вдвоём с CTPO Сергеем Денисовым. Начали с экспериментов на внутренних репозиториях вышеупомянутой платформы AlfaGen.
Мы тестировали разные модели — от DeepSeek V3 и Qwen до GLM-5, сравнивали результаты. Более пристально смотрели на китайские решения: в наших задачах GLM‑модели — то, что надо, особенно с должной настройкой. К слову, GLM мы сейчас сменили на MiniMax в части решений.

Большим открытием для меня стала семантическая и якорная разметка. Я сел изучать AI‑документацию Google и Anthropic (до сих пор советую это делать всем, кто хочет понять базу вайб‑кодинга) и наткнулся на идею структурирования контекста через XML, JSON и Markdown‑файлы.
Для примера вот моё сравнение XML и JSON при работе с LLM.
|
Основная структура |
Пары «ключ: значение» |
Вложенные теги |
|
Пример |
{“name”: “John”} |
<name>John</name> |
|
Читаемость для человека |
Хорошая для коротких данных |
Лучшая для сложных структур |
|
Для ИИ |
(много одинаковых символов) |
Чёткие «якори» для внимания |
|
Использование в ИИ |
Только для вывода данных |
Для структурирования запросов и вывода |
|
Размер payload |
Компактнее (~20% меньше) |
Более подробный |
|
Parserability LLM |
Сложнее (много скобок) |
Проще (чёткие начало/конец) |
|
Performance с длинным контекстом (>4k токенов) |
Точность падает на 30% |
Стабильна |
Немного данных от OpenAI по исследованиям последних двух лет:
-
При контексте до 1000 токенов JSON и XML работают одинаково хорошо (0% разницы).
-
При контексте 4000–8000 токенов XML даёт на 15% более точные результаты.
-
При контексте более 16 000 токенов XML сохраняет точность, JSON теряет до 30%.
-
При контексте более 100k токенов: XML даёт 99.5% точность, JSON деградирует полностью.
Вот что рекомендует Google при работе с их нейросетью Gemini: «Для сложных промптов используйте XML‑подобную разметку. JSON рекомендуется только для простых структур вывода данных в виде API‑ответов».
Мы вывели такое правило для новичков:
-
Если ваш запрос короче одного экрана, можно использовать JSON.
-
Если ваш запрос длиннее одного экрана, используйте XML.
-
Если контекст > 4000 токенов, всегда используйте XML.
Вы можете буквально управлять вниманием модели: чётко обозначать ей, на каких участках нужно сфокусироваться и какие части кода для вас приоритетнее.
С этим пониманием мы создали методологию семантической и якорной инженерии для наших проектов в Альфе. Так код получается не только лаконичнее. Экономия токенов выходит ощутимой (в 1,5–2, а где‑то даже в 4 раза) — корпорация точно прочувствует плюсы такого подхода.

Написали — надо пробовать. Наши пилотные команды повысили точность ответов модели на 60–70% по сравнению с разработчиками, которые вайб‑кодили по старинке — без структурированных промптов. А ещё мы сократили расход токенов со 160 до 85 тысяч на крупных кодовых базах. Это только про экономию GPU (хотя вы цены на графические процессоры видели?), но и про стабильность работы серверов без жалоб пользователей.
Чем вайбкодеру усилить методологию и семантику
От сборки методологии и единичных экспериментов мы перешли к задачам побольше. Первым серьёзным проектом с вайб‑кодингом у нас стал эквайринг. Нужно было перенести легаси RPG‑код с IBM 4000 на Java 21. На масштабе мы яснее увидели отдачу прописанной методологии — без неё можно было бы переписывать код месяцы, а мы справились за 3 недели.
Чтобы вайб‑кодить могли не только энтузиасты, но и микро‑команды вайбкодеров, их ещё называют Tiny Teams, мы подготовили важные штуки.
Наш стартер‑пак для вайбкодера:
-
Автоустановщики: нажал кнопку, вставил API‑ключ — и собственный или совместимый с AlfaGen плагин готов к работе.
-
Фаст‑трек для мгновенного деплоя веб‑проектов в тестовые среды менее чем за сутки.
-
Кукбук — руководство по сборке MVP за 6 часов. Мы с Сергеем Денисовым (ещё раз спасибо моему CTPO, который иногда проводил за проектом выходные и так же горел им, как я) расписали всё. Это документ в Confluence, который сэкономит часы и дни нашему разработчику. По нему можно пройти от вводных терминов до запущенного продукта с бэком, фронтом и интеграциями с системами банка.

Инструментарий собрали — надо подключать энтузиастов. В апреле мы провели хакатон по вайб‑кодингу. Придумали задачу для наших разработчиков банковских систем, дали им сутки на решение и ещё день на подготовку защиты для успешных команд.
Подключилось (абсолютно добровольно, тема правда оказалась популярной, ну и призы были неплохие) 280 сотрудников. 81 команда из 1–4 человек была на старте, 71 команда сдала решение. За сутки коллеги написали 1 626 723 строк кода (5800 строк кода на участника), 96 000 запросов отправили модели AlfaGen (340 запросов на участника), составили 100 000 промптов, получили 38 000 000 completion.

Хакатон точно будем повторять с другими задачами и командами даже в этом году — у нас практика отлично дополняет внедрение ИИ в разработку через курсы, кукбук и техтолки.
Сам пройдя этот путь от знакомства с чужой AI‑документацией до сборки методологии для корпорации, я могу писать и ревьюить код на Python, Java и JavaScript, хотя на старте знал только базу Python. LLM стала моим учителем.
Я вижу, как строка за строкой создаётся алгоритм, могу в реальном времени корректировать логику. Это так же залипательно, как наблюдать за огнём или текущей водой — только в чате с LLM видишь рождение продукта.
Почему кто‑то пока не может перестать беспокоиться и начать вайб‑кодить
Теперь будет немного неудобной правды. Само слово «вайб‑кодинг» пока у многих встречает отторжение — ну ещё бы, мы прожили 2 года с этим понятием и только пробуем вкатываться в тему.

В этом году в горящем поиске вайбкодеров я провёл 30 собеседований и нанял только 4 человека.
Почему вайб‑кодинг пока заходит не всем:
-
Мы не луддиты, но всё ещё боимся, что машина отнимет у нас заработок. Профи, полжизни изучавшие языки и фреймворки, видят в LLM конкурента. Вместо того, чтобы стать архитектором результата, они отрицают подход под соусом «это неправильно написано, не канон, я бы сделал лучше» и так далее
-
А вдруг придётся работать — не как раньше. Классический разработчик кодит 2–3 часа в состоянии потока, остальное время — на обдумывание, подход к снаряду, кофе, встречи. С вайб‑кодингом «поток» уже можно уложить в час, но от тебя ждут продуктивности в освободившееся время. Надо менять привычки и ритм — бежать быстрее, делать больше, чем вчера, отдавая машине часть «жвачки», которая занимала будни.
-
Это же снова что‑то изучать. Многие, кто называет себя вайбкодерами, просто копируют промпты в GPT. Они не понимают, как структурировать контекст, прописывать семантику, увязывать несколько агентов в проекте. В корпорации точно понадобится вдумчивый подход. Да, с ним результат превосходит ожидания, но для начала нужно перестроиться и (иногда через «не хочу» и «нет времени») получить новые навыки.
Как было с другой технологией вокруг ИИ у нас в банке: одним из первых в инструментарии AlfaGen появился LLM‑агент для тестирования. Тестировщики отрицали его, пока не увидели результат — вместе с заказчиком задачи. Постепенно втянулись, сейчас сложно представить, что раньше жили без него.
Нам больно принять перемены, потому что кажется, что если инструмент делает работу быстрее, значит мы так себе эксперты. На деле я вижу, что фокус просто смещается на оркестрацию и контроль результата.
«Правильный» вайбкодер — он с нами в одной комнате?
Для меня (почти) идеальный вайбкодер в корпорации — универсальный солдат. В моей команде нет чёткого разделения на бизнес‑аналитика, системного аналитика, руководителя проекта и разработчика. Теперь всё это ты, в одном лице, берёшь задачу целиком.
Важный дисклеймер: в Альфе у наших ребят на руках все инструменты, чтобы собрать документацию, архитектурный вижн, сделать ревью кода вместе с плагинами, которые заточены под задачи банка. Ну и в одном клике от тебя совет наставника или плечо коллеги. У нас плотное комьюнити вокруг платформы AlfaGen, 6500 участников в чате, треды по всем ИИ‑продуктам, MCP, AlfaGen w, и мы быстро разбираем запросы, так как ИИ и вайб‑кодинг — наш фокус в банке.
Если говорить про навыки: при собеседовании я сначала смотрю на софты: горящие глаза, готовность развиваться, мотивацию. Потом уже — хард‑скиллы (им научим, база и методология уже есть): понимание структуры промптов, опыт создания скиллов, способность работать с семантической разметкой.
Мне важно, чтобы человек мог создать первоначальный скилл за 2–3 часа, проработав архитектуру и структуру, а не просто сгенерил код.
Для роли вайбкодера знание языков теперь вторично. Намного важнее логическое мышление, системный подход и готовность брать на себя ответственность. У меня нет ИТ‑образования, но это не помешало мне вникнуть в новую методологию, переработать её для конкретной корпорации и масштабировать вместе с командами разработки.
На каком этапе с вайб‑кодингом мы сейчас
Вот сейчас, в 2026 году, команды банка идут по нашей методологии. Пока полёт нормальный — результаты прирастают. Мы как AI‑powered компания не просто пишем промпты — мы создаём инструментарий.

Конечно, кроме кукбука, фаст‑трека и витрины плагинов нам есть что поделать. Из крупного сейчас в работе:
-
расширение библиотеки агентов для разных задач,
-
централизованное управление промптами с учётом регламентов безопасности,
-
мониторинг затрат на GPU и оптимизация выбора моделей,
-
погружение коллег в теорию и практику вайб‑кодинга: каждый новый сотрудник смотрит кукбук и с ним создаёт свой первый проект за неделю.
По своим новым проектам я заметил: если раньше задача занимала три месяца, сейчас я закрываю её за неделю с сохранением качества и соблюдением корпоративных стандартов. Но это произошло не по щелчку пальцев. Сначала мы пару месяцев буквально не спали и жили методологией: перебирали модели, подходы и увязывали всё в процесс, который устраивает безопасность, архитекторов, ИТ‑директоров и других заинтересованных лиц.
Что я думаю про вайб‑кодинг в 2026 году
Вайб‑кодинг в корпорации — это не модный тренд, а новая парадигма. С ней надо свыкнуться и пересмотреть свою роль в разработке: перестать быть исполнителем, став оркестратором, ответственным за результат. Не все готовы к этому, но те, кто готов, получат помощника для творчества и оптимизации.
Мой путь в адвокаты вайб‑кодинга не был гладким, как могло показаться. Я пришёл в эту область из другой профессии, провёл полгода в больнице после аварии на мотоцикле с ноутбуком на животе, учил Python, знакомился с нейросетками. Сейчас я вижу, как моя методология правда приносит пользу.
Я перестроил свою жизнь, которую раньше связывал со спортом. Без ИИ такой буст был бы просто невозможен. Выбрал для себя путь — не бояться и не ждать указаний сверху.
Я уже пробовал вайб‑кодинг в своих проектах, пока о нём не говорили на уровне стратегии. Именно поэтому, когда у корпорации появился интерес, у меня были готовые ответы, инструменты и понимание, что сработает, а что не очень.

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

Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.