Привет, я Максим, лидер 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, знакомился с нейросетками. Сейчас я вижу, как моя методология правда приносит пользу.
Я перестроил свою жизнь, которую раньше связывал со спортом. Без ИИ такой буст был бы просто невозможен. Выбрал для себя путь — не бояться и не ждать указаний сверху.
Я уже пробовал вайб‑кодинг в своих проектах, пока о нём не говорили на уровне стратегии. Именно поэтому, когда у корпорации появился интерес, у меня были готовые ответы, инструменты и понимание, что сработает, а что не очень.

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

mahmud90
26.05.2026 11:38Для роли вайбкодера знание языков теперь вторично
То есть для вайбкодера главное уметь вайбкодить (настраивать процессы, скилы и т.д.), а понимать, проверять и при необходимости исправлять написанный код - необязательно ("вторично")? А кто же будет проверять и контролировать то, что выдал ИИ? Большие бородатые серьезные дяди?
Вообще, пока выглядит как ИИ ради ИИ. Выделили бюджет, велели внедрять ИИ в песочнице, устраивать конкурсы, хакатоны. Пилить экспериментальные проекты.

akod67
26.05.2026 11:38Понимать - сам ИИ объяснит. Исправлять - сам ИИ исправит. В чём проблема?

mahmud90
26.05.2026 11:38Если говорить о серьезных проектах, то проверка кода обязательна. Тем более в такой чувствительной сфере, как банковская. ИИ по-прежнему ошибается и галлюцинирует, при раздувании контекста - начинает тупить. Hallucination rate на AA-Omniscience у GPT-5.5 - 86%.
Думать, что ИИ вайбкодеру всё объяснит, и он во всем разберется и поймет - тоже, мягко говоря, несерьезно. Человек учится ровно то время, пока руками пишет код, сам пытается в нем разобраться, отладить, найти и исправить возникшие баги. Если ошибки (особенно скрытые) содержатся в сгенерированном ИИ коде - вайбкодер никогда об этом не узнает. Или узнает, когда упадет прод. Все тесты (которые ИИ любят подгонять под свой код) при этом могут быть зелеными.
А кто будет править баги в проде? Вайбкодер окажется беспомощен. Он не понимает как работает код, не знает как искать причины багов, будет просто запихивать в LLM простыни ошибок и логов. Снова нужны будут взрослые дяди-программисты, которые способны разобраться и всё поправить. Долгосрочную поддержку проекта с помощью ИИ вайбкодер тоже не сможет обеспечить.
Поэтому утверждение "для роли вайбкодера знание языков теперь вторично", если вести речь о серьезных проектах - попахивает наивностью и популизмом.

akod67
26.05.2026 11:38Вот представьте. У вас опыт 20 лет с Java. Но тут, вдруг по какой либо причине потребовалось всё делать на .Net, с которым у вас опыт минимален. Вы “пишете” теперь вайбкодом. Разве у вас реально будут сложности с пониманием (с помощью LLM) кода и его сопровождением? В банковском то коде, где рокет сайнс минимален.
Баги - ещё раз. Почему вдруг это поверие, что код пишется один раз LLM и потом поддерживается руками? От отсутствия опыта работы с агенскими системами (Клод, Кодекс)? Это же не одноразовый чатик. Зачем править баги руками?
не знает как искать причины багов, будет просто запихивать в LLM простыни ошибок и логов
И удивительно, но это будет работать. Потому что опытный дев заставит ЛЛМ обвесить весь проект тестами, документацией и подробной трассировкой и, о чудо, ЛЛМу этого будет достаточно для самостоятельного исправления проблем в 99% случаев.
Пишу как дев с 30летним стажем, очень плотно подсевшим на вайбкодинг последние пол года, как только Клод пришёл в сознание. Да, это не прошивки имплантов, а обычный B2B.

mahmud90
26.05.2026 11:38Вы приводите пример вайбкодера с многолетним опытом в программировании. И это ключевой момент. В статье же речь идет о вайбкодере не-программисте.
Автор статьи пишет что при найме вайбкодеров в первую очередь смотрит на софт-скиллы, а затем - на хард-скиллы, под которыми он подразумевает "понимание структуры промптов, опыт создания скиллов, способность работать с семантической разметкой". О каком-либо опыте в программировании, даже начальном знании языков речи вообще не идет! И вот такой человек будет генерить код.

domix32
26.05.2026 11:38Почему вдруг это поверие, что код пишется один раз LLM и потом поддерживается руками?
Потому что часто ллм не способна решать проблемы хоть как-то и может выдавать unhinged решения вроде сноса лайв базы данных или удалить весь репозиторий. Опять же инциденты в продакшене бывают совершенно разные - где-то косяк с конфигурацией случился, где-то баг в коде действительно появился, где-то UX привел к неприятным искажениям в базе данных - робот знать не знает про UX и не может AB-тестировать интерфейсы. Он может написать тест, но не провести тестирование. Держать систему призрачного лайва и пускать LLM только куда довольно затратно как по вычислительным ресурсам, так и по технической поддержки - фактически второй лайв держать, да ещё и какой-нибудь обфускатор под боком, чтобы ПД не обрабатывать лишний раз.
В банковском то коде, где рокет сайнс минимален.
Вы кажется недооцениваете количество всякой регуляторки, которая сопутствует всему тому не рокет-саенсу.

akod67
26.05.2026 11:38Извините - но половина из всего описанного - чисто человеческий фактор и банальное неумение или чрезмерное доверие к инструменту. Как ЛЛМ снесёт лайв базу, если любой разумный технарь её в лайв базу просто не пустит? (я пускаю в некритичные, уж слишком это удобно =)
фактически второй лайв держать
так в том-то и дело, что это ранее держать Н энвайренментов было трудозатратно. Сейчас же сам LLM всю эту инфраструктуру легко поднимает и делает это лучше людей (в ансибле он такие вещи вытворяет, до которых бы сам не додумался либо поленился бы так писать). С каких пор dev, stage env вообще стали предметом сомнений? Обычная практика в здоровом проекте.
Вы кажется недооцениваете количество всякой регуляторки, которая сопутствует всему тому не рокет-саенсу.
Именно чек регуляторки (если я правильно понимаю о чем вы), то что дефинируется текстом - и есть сильная сторона применения соотвсетствующего инструмена.

domix32
26.05.2026 11:38С каких пор dev, stage env
я не про dev и stage, а про бэкпорт лайва обратно в стейжинг - для имитации нагрузки или для проверки соответствия функциональности на живых данных. ghosting называется. Правда доподлинно знаю только две кампании, которые использовали это как отдельный этап аналогичный stage - netflix и cloudflare. В банковской сфере с подобными этапами есть нюансы из-за персональных данных, которые необходимо обезличивать. На хабре всплывали несколько статей рассказывавшие истории про поднятие оных для отдела тестирования и как это превращается в брейкданс между отделами тестирования, безопасности и финансов.
Именно чек регуляторки
там не просто чек, а формирования отчётов всех форм и размеров для себя и для васьки и для государства, всякие аудиторские логи, отчеты и аналитика, прочая телеметрия разного уровня надобности. Сами по себе мелкие детали не сложные, но когда это 20 разных продуктов в линейке, то количество комбинаций начинает взрываться, иногда триггеря какие-нибудь особенные ограничения которые должны появляться в високосный год в пятницу в третью фазу луны когда чел с ФНС на горе свистнет. ЛЛМ такие кейсы разве что нагаллюцинировать могут и могут периодически "забывать", что этот кейс должен быть учтён с учётом этих ограничений.

Andrey2008
26.05.2026 11:38Не удержался. А можно где-то посмотреть на хороший С++ вайб-код? Может кто-то подсказать открытые проекты?

akod67
26.05.2026 11:38Linux Kernel? не плюса правда. Там уже хватает коммитов. Если уж даже такой диктатор как Торвальдс открыл ворота, то пора делать выводы.

Andrey2008
26.05.2026 11:38Ну то есть новых проектов нет? У Linux Kernel всё было отлично и раньше.

akod67
26.05.2026 11:38Почему за пол года резко должны появиться совершенно новые проекты? Что бы что? Что бы доказать технологию? В реальности не так внедряется ИИ. Внедряется сначала на второстепенных задачах, потом, по мере роста доверия, на задачах всё сложноее. А проектов на самом деле много. Особенно внутри бизнеса, где сейчас активно переписывают всякие разные легаси на новые рельсы, так как это стало кардинально проще.

domix32
26.05.2026 11:38Профи, полжизни изучавшие языки и фреймворки, видят в LLM конкурента.
Хз как вы к этому выводу пришли. Персонально воспринимаю их как необучаемых джунов. Они могут хорошо имитировать честно спи жена код, но семантику они не понимают, почему оно пишется именно так тоже не анализируют. А учитывая, что многие не видели современных подходов они его часто и не используют вовсе. И для того чтобы хоть что-то из этого прикрутить приходится половину контекста отдавать под мегабайт токенов - контекст кончается быстрее. Плюс дурилки не могут сказать нет и не понимают слова нет и будут искать проблемы на ровном месте - ты ему говоришь, что работа с буффером точно секьюрна и обложена тестами, оно тебе будет в каждом респонзе писать "РРРЯ НЕБЕЗОПАСНО", опишешь ему план работ по шагам - будут модули X, Y и Z, назначения модулей такие-то, пишем модуль, пишем тесты, коммитим, переходим к следующему модулю - сделает все шаги в один подход - у 7 агентов весь код без плана.
Это же снова что‑то изучать.
скорее не так - программист превращается в аналитика и начинает писать техническое задание не самым стандартным способом на крайней нестандартизируемом языке программирования - естественном языке. Определённо не то чем хотелось бы заниматься среднестатистическому программисту, иначе бы он в писатели ТЗ и пошёл. Несравнимая разница с изучением нового языка или фреймворка. В корпорации ожидаешь, что требования спускаются программисту сверху после анализа всех бизнес требований, а не программист пропагирует их в обе стороны.

greenrus
26.05.2026 11:38Я не знаю в какой вы корпорации работали, но в реальной работе программиста написание кода занимает 30-40% времени. Остальное - изучение требований и коммуникации. И программист прежде всего должен понимать продукт - что он делает и зачем. А кодера который по готовым требованиям реализует функцию ИИ точно заменит первым

Artem_Bus
26.05.2026 11:38Путь от «руководителя проектов» до «лидера AI-powered разработки» за год — это карьерный рост или просто ребрендинг должности под тренд? Без сарказма, реально интересно: изменился ли найм в команду, требования к людям, бюджеты? Или та же работа, но теперь в резюме пишем «вайб-кодинг» вместо «автоматизация»?
tkutru
Мощно...
Осталось еще ролей понакидывать: фронтендер, бекендер, девопс, (веб-)дизайнер, безопасник, тестировщик, DBA, дата инженер, ML-щик и пр.
А в идеале ("в корпоративной парадигме") это вообще должен быть один человек, обвешанный "ИИ". Остальных уволить, на эскономленные деньги построить себе дачу, например.
Когда начнётся пожар (человек уволится или техдолга станет слишком много) объяснить борде и стейкхолдерам "сложную рыночную ситуацию" и перейти в другую компанию. А там можно повторить сначала. P - profit.