Дисклеймер. Данная статья не претендует на туториал, руководство к действию или повторение. В ней я пытаюсь ответить на давно дискутируемый вопрос: может ли вайбкодинг использоваться для нужд реального бизнеса? И кажется, ответ положительный — по крайней мере, в рамках осени 2026 года. Статья написана с согласия моего уже бывшего коллеги @smolyakov. В ней намеренно не указаны названия или торговые марки компании.

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

С чего всё началось

Сразу оговорюсь, что ни я, ни мой коллега не обладали каким-то значимым бэкграундом в информационных технологиях, оставаясь скорее менеджерами продуктов, мы не развивались как программисты или архитекторы. Я работал менеджером интернет-проектов, делал сайты и внедрил корпортал на базе «Битрикса», знаю основы Python, HTML/CSS, JS и PHP — но не в объёме, достаточном, чтобы написать что-то значимое с нуля. Какое-то время спустя волей судьбы переключился на общее руководство рекламной и маркетинговой службой компании, в которой работал. Чуть позже к команде присоединился @smolyakov, располагавший хорошим опытом в строительстве e-commerce порталов. Этим он занимался и у нас — с переменным успехом.

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

Первый опыт - убираем рутину из PR

При этом мы, конечно, были знакомы с лучшими практиками разработки ПО — и в силу опыта, и по работе с партнёрами, вместе с которыми то и дело проходили через одни и те же этапы, пользуясь популярными фреймворками и системами постановки и контроля задач — от того же «Битрикса» до YouGile.

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

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

Выглядело всё вполне стандартно: система получала входящие потоки в виде RSS или результатов парсинга, нормализовывала их и на определённом этапе взаимодействовала с одной из моделей GPT. Роль ИИ-компонента заключалась в оценке соответствия новости теме, а также в скоринге и дедупликации (чтобы одинаковые новости из разных источников не попадали в поток дважды). Итогом являлся файл Word с набором статей, которые оставалось только критически оценить и оставить нужные.

Сама «система кодинга» тоже была довольно примитивной: я показывал ChatGPT / DeepSeek API экосистемы Langflow, описывал задачу — и дальше писались и тестировались кастомные компоненты (вместо стандартных). Например, удалось сделать интересную систему парсинга одного новостного сайта с поддержкой динамической пагинации: сначала подсчитывалось число страниц за неделю, находились скрытые даты публикации новостей (бывает и такое — дата обозначена неявно, прямо в тексте), а затем скрипт, перебирая страницы, загружал данные.

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

Система проработала около полугода — с переменным успехом и постоянными доделками, — после чего избавилась от Langflow: с помощью Claude Code она была переписана и получила серверную версию и полноценную оболочку на Python/JS, с сохранением исходной логики и обучением модели. Тем не менее, разработка хоть и с оговорками, но уже значительно экономила время отдела.

Быстрая трансформация - второй продукт

К концу год года мы в отделе уже придерживались AI-first подхода: и дизайн, и продакшн активно работали с ИИ ради повышения производительности и результативности. @smolyakov а затем и я, уже освоили вайбкодинг: мне был ближе вариант с IDE, а коллега использовал полноценное приложение, экспериментируя и выбирая между Claude Code и Codex. К этому моменту мы выработали темп и правильную практику работы: начали вести полноценный бэклог и использовать разных агентов под разные роли — от планирования до написания автотестов и вопросов ИБ.

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

В начале 2026 года компания сменила курс с b2g-продаж на b2b, превратившись из розничного продавца в мастер-дистрибьютора техники. Трансформация шла стремительно, что, в свою очередь, требовало от команды быстрых решений. Исторически компания по всем правилам ИБ работала в закрытом контуре, и внутренние сервисы разрабатывала inhouse-команда ИТ, тогда как внешние ресурсы принадлежали маркетингу. Соответственно, ИТ логично сосредоточилось на личном кабинете для дистрибьюторов. Между тем пул дистрибьюторов начал требовать определённой «обвязки» — контактов, обучения, рекламных материалов, — а времени ждать новые инструменты не было. Решение пришло как будто само собой.

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

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

Третий продукт - пишем PRM-систему

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

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

Одним из вызовов при разработке этого сервиса стала правильная схема авторизации пользователей. Как я писал выше, контур компании был изолирован от внешней сети, а дистрибьюторов нужно было как-то одобрять — и желательно автоматически, поскольку администрировать вручную несколько сотен компаний тяжело. Мы придумали изящную модель: пользователь при регистрации вводил ИНН, и если ИНН был в базе партнёров, сразу получал статус, дающий право на поиск и скачивание материалов. Но как актуализировать саму базу? Единственнй раз пришлось уйти от автоматизации. Был дописан компонент, принимавший на входе таблицу в простом Excel-формате: система раз в заданный промежуток времени оповещала админа, что база устарела. Дальше нужно было сходить в учётную систему, забрать простую таблицу с ИНН и названиями партнёров и вручную загрузить её во внешний контур. После этого данные обогащались через сервис DaData и сохранялись.

Позже этот справочник лёг в основу другого компонента, с помощью которого компания получила актуальный mail-лист.

Проблема заключалась в том, что учётная система компании и CRM исторически хранили не все email партнёров. Не будем углубляться, почему так вышло, — просто примем как факт, что у компании раньше не было полноценного CRM-маркетинга, и на тот момент мы не знали, насколько контакты актуальны и есть ли они вообще.

Ручной сбор ни к чему хорошему не привёл. В итоге мы расширили справочник компаний в системе за счёт всех электронных адресов, которые начали поступать как напрямую от пользователей, так и от представителей в регионах, а дальше система по API работала с Sendsay, автоматически актуализируя списки рассылки.

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

Впоследствии система получила название «Хаб», и мы узнали, что, сами того не ведая, изобрели маленькую, но гордую PRM-систему. Фактически разработка со всеми нюансами заняла 2–3 месяца: MVP инициативно представили в апреле. А дальше та же трансформация бизнеса, которая когда-то и породила все эти задачи, добралась и до нас: в рамках реорганизации и сокращений, последовавших за переходом на b2b, в августе мы оба покинули компанию, и разработку пришлось прекратить — по иронии, тем же процессом, который её когда-то и запустил.

Где спотыкались

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

Деплой все это время оставался предельно кустарным. Никакого CI/CD, стейджинга и внятного pipeline не было: сервисы выкатывались руками, чаще всего по SSH, на паре виртуалок, которые мы сами и администрировали, или через тот же AI-IDE. Схема держалась только потому, что нагрузка была невысокой, а число сервисов — обозримым; для чего-то большего она не рассчитана, и мы это прекрасно понимали.

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

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

Вайбкодинг в компании — итоги

По сути, наша модель разработки представляла собой команду из двух человек, в которой один (я) генерировал фичи, исследовал потребности и представлял интересы бизнеса — фактически выступая как product owner, а заодно и тестировщик, — а второй занимался всеми вопросами разработки и интеграции системы. При этом никто из нас не был опытным программистом и лишь в общих чертах понимал, как устроен или настроен тот или иной компонент.

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

Конечно, не всё так гладко, и вариант работы, описанный в статье, я рекомендую применять исключительно при наличии хотя бы первичной экспертизы в разработке ПО. Самое ценное в полученном опыте — то, что все созданные продукты так или иначе использовались бизнесом, а не оставались экспериментальной разработкой. Этот опыт уверенно показывает: развитие кастомного ПО под интересы бизнеса вполне возможно силами небольшой команды и относительно недорого — при условии, что коллеги увлечены этим безусловно интересным делом. Интересно заметить, что ряд крупных ИТ-компаний уже пошли по похожему пути, сокращая команды разработчиков и делая ставку на фулл-стек-специалистов.

Сегодня я, как и многие коллеги здесь, на Хабре, продолжаю развивать свои сервисы, которые помогают в работе и в жизни, — за полгода незаметно став yet another vibecoder. Например, один сервис ищет мне работу, другой выполняет функции в видеодистрибуции, третий я написал для друзей из спортивного клуба — он отслеживает прогресс игроков. Но это уже совсем другая история.

Опыт инди-вайбкодинга приложений как реальная бизнес-задача