Маркетинг собирает себе лид-форму за вечер. Финансы поднимают скрипт сверки платежей за полдня. HR делает бота для первичного разбора резюме. Всё выглядит как победа эффективности ровно до того момента, когда это начинает ходить в прод, трогать реальные данные и ломаться в самый неудобный день.
Вайбкодинг уже вышел из режима игрушки для энтузиастов. Для компаний это новая форма теневой разработки: код появляется быстро, пользы от него сначала много, контроля почти нет. Самое неприятное тут даже не код. Самое неприятное: бизнес доволен скоростью, разработчики чувствуют угрозу, а IT-руководитель оказывается между ними.
Почему тема вообще стала острой
Термин vibe coding обычно описывает простой сценарий: человек формулирует задачу на естественном языке, а модель генерирует код. Пока речь про прототип, локальный скрипт или черновой MVP, всё выглядит безобидно. Проблемы начинаются позже.
Бизнес видит вот что: раньше на внутренний инструмент уходили недели, теперь что-то похожее можно собрать за часы. После этого почти неизбежно возникает вопрос: а чем тогда так долго занят отдел разработки?
В этой точке спор про технологии быстро превращается в спор про организацию работы. И в спор про доверие.
Как выглядит теневая разработка в 2026 году
Обычно это не бунт против IT и не желание кого-то обойти из принципа. Сотрудник из соседнего отдела просто хочет решить свою задачу быстрее.
На практике через AI чаще всего собирают:
внутренние дашборды;
скрипты для Excel, почты и отчётов;
чат-ботов для поддержки или найма;
формы и маленькие сервисы для клиентов или партнёров.
IT узнаёт об этом не на этапе идеи. IT узнаёт об этом по симптомам:
непонятный трафик к внутренним API;
запросы на доступы к системам, под которые никто не заводил проект;
жалобы, что какой-то "маленький сервис" внезапно перестал работать;
срочный вопрос "а можете починить, оно вчера ещё работало".
Почему бизнесу это нравится
Во-первых, это быстро. Во-вторых, дёшево на входе. В-третьих, человеку из бизнеса больше не нужно ждать свободного слота у команды разработки, писать длинное ТЗ и неделями согласовывать детали.
Есть и ещё один фактор, который разработчики иногда недооценивают: сотрудник предметной области часто лучше понимает свою задачу, чем внешний по отношению к ней инженер. Если у него появился инструмент, который позволяет сразу превратить знание процесса в работающий сценарий, он будет им пользоваться.
Запретить это приказом можно. Остановить нельзя.
Почему IT от этого не в восторге
Потому что у любой такой скорости есть цена. Она просто оплачивается не в момент запуска, а позже.
1. Данные уходят туда, где компания их не контролирует
Сотрудник копирует в промпт клиентские данные, фрагменты SQL, внутренние адреса сервисов, куски исходного кода, финансовые отчёты. Даже если сервис обещает аккуратную работу с данными, компания не управляет ни средой исполнения, ни жизненным циклом этих данных, ни набором реальных гарантий.
Для регулируемых отраслей, для персональных данных, для коммерческой тайны это уже не мелкий риск. Это инцидент, который просто пока ещё не оформлен как инцидент.
2. Код получается правдоподобным, но не обязательно надёжным
AI хорошо имитирует уверенность. Он может выдать аккуратный интерфейс, понятные имена функций и вполне читаемую структуру. При этом внутри легко оказываются:
несуществующие пакеты или сомнительные зависимости;
уязвимости в обработке входных данных;
слабая обработка ошибок;
логика, которая работает только на "нормальном" сценарии;
решения без запаса по нагрузке и сопровождению.
Человек без инженерной подготовки обычно не отличает "выглядит как рабочее" от "выдержит продакшн". Отсюда и ложное чувство безопасности.
3. Технический долг растёт быстрее, чем кажется
Маленькое приложение, собранное за день, редко умирает сразу. Сначала оно помогает. Потом к нему добавляют ещё одну кнопку, ещё одну интеграцию, ещё один отчёт. Через полгода внезапно выясняется, что на нём сидит кусок реального процесса.
И вот тут начинается дорогое кино: тестов нет, документации нет, владельца по факту нет, зависимость от конкретного автора огромная, а перенос в нормальный контур займёт дольше, чем изначальная разработка руками.
4. Ответственность размывается
Если сервис сделал менеджер, код сгенерировала модель, данные дала другая команда, а сломалось всё на корпоративной инфраструктуре, кто отвечает?
Формально никто. Фактически отвечать всё равно придёт IT.
Страх разработчиков: неудобная, но реальная часть истории
Этот кусок часто вырезают из публичных обсуждений, а зря.
Когда руководство видит, что приложение можно собрать за несколько часов, у разработчиков закономерно включается тревога. Она не всегда звучит как "нас всех заменят". Чаще это выглядит тише:
люди перестают предлагать улучшения;
начинают жёстко обесценивать любые AI-инструменты;
саботируют пилоты;
держатся за старые метрики типа объёма написанного кода;
внутренне готовятся к тому, что их экспертиза теперь считается менее ценной.
Страх тут понятный. Если компанию впечатляет скорость генерации, она легко начинает недооценивать то, за что на самом деле платит инженерам: архитектуру, надёжность, интеграцию, эксплуатацию, безопасность, предсказуемость изменений.
Разработчикам в такой ситуации вредно уходить в отрицание. AI уже никуда не денется. Полезнее перестроить профессиональную оптику.
Что становится важнее прежнего:
ревью и верификация AI-кода;
проектирование систем с горизонтом в годы;
интеграция новых сервисов в существующий ландшафт;
контроль данных, прав доступа и нормативных ограничений;
работа со сложной бизнес-логикой, где исключений больше, чем happy path.
Проще говоря, ценность инженера смещается от "я быстрее всех пишу руками" к "я лучше всех понимаю, что можно выпускать в реальный контур".
Почему сопротивление разработчиков тоже опасно
Есть соблазн ответить на тренд презрением. Сказать, что вайбкодинг годится только для демо, а серьёзные люди так не работают. Это психологически комфортная позиция. Для компании она вредна.
Если инженерная команда просто заблокирует тему, бизнес не откажется от идеи ускорения. Он пойдёт в обход. Результат будет хуже для всех: меньше прозрачности, больше серых инструментов, больше конфликтов между отделами.
Сопротивление разработчиков тормозит компанию не потому, что они неправы в критике. Критика часто справедлива. Проблема в другом: критика без предложенного безопасного пути оставляет бизнес один на один с соблазном сделать всё самостоятельно.
Нормальная позиция инженера тут звучит жёстче и полезнее: "Да, так можно ускориться. Нет, в таком виде это нельзя выпускать. Вот условия, при которых это станет рабочим вариантом".
Что делать IT-руководителю
У IT-лидера здесь нет роскоши занять красивую идеологическую позицию. Нужен рабочий режим управления.
1. Сначала признать факт, потом вводить правила
Если в компании уже есть вайбкодинг, бессмысленно делать вид, что его нет. Первый шаг очень приземлённый: инвентаризация.
Нужно понять:
какие приложения уже собраны;
кто их автор;
какие данные они используют;
кто их реально поддерживает;
есть ли у них внешние пользователи.
Это лучше делать без охоты на ведьм. Иначе люди просто спрячут то, что уже сделали.
2. Разделить сценарии по риску
Не каждый AI-инструмент одинаково опасен. Одно дело локальный скрипт для разовой подготовки отчёта. Другое дело сервис, который трогает клиентов, деньги или критичную инфраструктуру.
Обычно имеет смысл заранее определить, где вайбкодинг допустим:
прототипы и черновые MVP;
внутренние инструменты без чувствительных данных;
одноразовые сценарии автоматизации;
песочницы для проверки гипотез.
И где он недопустим без полноценного инженерного процесса:
клиентские данные;
платежи и финансы;
инфраструктурные компоненты;
всё, что должно стабильно работать 24/7.
3. Сделать легальный путь быстрее теневого
Пока согласование внутри IT занимает недели, люди будут собирать решения снаружи. Значит, нужен нормальный внутренний путь: понятный, быстрый, не унизительный по бюрократии.
Рабочая модель обычно включает:
безопасную платформу или песочницу для экспериментов;
понятные правила доступа к данным;
обязательное ревью перед выходом из песочницы;
инженера или small platform team, которые помогают довести полезный прототип до рабочего состояния.
Именно тут IT перестаёт быть только воротами на вход. Оно становится сервисом инженерного контроля.
4. Сменить метрики внутри разработки
Если команду до сих пор оценивают по скорости написания типового кода, конфликт с вайбкодингом неизбежен. Метрики стоит смещать туда, где AI не решает задачу целиком:
время от идеи до безопасного запуска;
число инцидентов и регрессий;
качество архитектурных решений;
скорость ревью и адаптации сгенерированного кода;
прозрачность владения сервисами.
Иначе получится абсурд: бизнес ускорился, а команда продолжает защищать объём ручной работы как самостоятельную ценность.
5. Проговорить страхи команды вслух
Иногда это важнее любой политики. Если люди уверены, что AI привезли только затем, чтобы потом тихо сократить штат, никакие регламенты не заработают.
Хороший разговор здесь довольно прямой: какие классы задач упростятся, какие роли изменятся, какие навыки станут дороже, что компания ждёт от инженеров через год. Без этого вайбкодинг будет восприниматься как политический проект против команды.
Мем, который почему-то слишком похож на реальные решения
Есть популярная схема, и она смешная ровно до тех пор, пока не встречается в управленческой практике:
Ну все, теперь будут все вайбкодить, а потом нафиг нам программисты мы сами все умеем -> увольняем программистов -> нанимаем джунов вайбкодеров -> пилим кучу всяких нужных и очень интересных программок -> потом все это хозяйство благополучно крашится -> бизнес в ауте на несколько месяцев -> возникает светлая мысль а давайте все таки профессионалов возьмем -> ищем, а их нет, они ушли в сантехники, а те кто остались стоят как чугунный мост в час.
Это наверно самый правдивый и грустный антипаттерн управления.
Самая опасная ошибка тут не в том, что компания пробует AI. Ошибка в том, что руководство путает скорость генерации артефакта со стоимостью владения системой. Код можно получить быстро. Надёжную эксплуатацию, сопровождение, эволюцию архитектуры и контроль рисков нагенерировать одной кнопкой пока нельзя.
Что меняется в роли разработчика
Разработчик не исчезает. Исчезает часть старого оправдания, почему простая задача должна ехать долго без прозрачного объяснения.
Это неприятный, но полезный сигнал.
Командам разработки придётся яснее показывать, где время уходит на реальную инженерную работу, а где в процессе накопилась лишняя инерция. Если бизнес видит только "раньше было три недели, теперь стало три часа", значит инженерный контекст не был объяснён или сам процесс давно просился на пересборку.
Сильные команды на этом фоне обычно делают две вещи:
убирают рутину и сами активно используют AI там, где это безопасно;
жёстко защищают те участки, где без инженерной дисциплины цена ошибки слишком высока.
Такой подход не выглядит оборонительным. Он выглядит взрослым.
Что в итоге
Вайбкодинг в компании есть уже сейчас, даже если о нём никто не докладывал на совете директоров. Запретами эта история не лечится. Восторгом без ограничений тоже.
Нужен более скучный и более зрелый подход: признать факт, описать границы, дать безопасный путь для инициативы, перестроить роль IT и не делать вид, что у разработчиков нет причин тревожиться.
Главный вопрос тут вообще не про нейросети. Главный вопрос такой: умеет ли компания превращать скорость в устойчивый результат, не разрушая собственную инженерную базу.
Если нет, то вайбкодинг очень быстро станет не инструментом ускорения, а инструментом накопления проблем. С красивым демо. И дорогим финалом.