Расширение доступа к инструментам разработки и генерации кода позволило многим сотрудникам создавать рабочие приложения, и команды ИТ часто не успевают отследить, сколько таких «vibe‑кодированных» приложений существует в их среде.
Каждому приложению нужен ответственный — не просто автор, а человек, который реагирует на сбои, понимает связи с другими системами и может починить приложение в случае проблем. Часто такие роли не определены при запуске «vibe‑кодированных» решений, и это становится очевидно в самый неподходящий момент.
Когда в период первой волны «теневого ИТ» обычно присутствовал вендор с поддержкой и документацией, современные решения, сгенерированные с помощью AI-инструментов, не имеют такой точки опоры. Если сотрудник создал рабочий поток через ChatGPT, Copilot или похожие средства, при отказе обращаться не к кому, а сам создатель может не понимать созданный код в достаточной мере для его сопровождения.
Профессиональные разработчики тоже отмечают проблему: в опросах разработчиков отмечают, что AI‑решения часто «почти правильные, но не совсем», а отладка такого кода оказывается более трудоёмкой задачей. Эти затраты по сопровождению быстро нарастают даже для опытных инженеров.
Когда автором критичного инструмента становится аналитик или представитель бизнеса без навыков программирования, бремя поддержки обычно перекладывается на ИТ и проявляется внезапно, как правило в кризисный момент.
Отраслевые наблюдатели называют текущую практику «context engineering»: генерация кода становится наиболее простой частью, а основная работа заключается в управлении окружением, безопасностью и ответственностью. Руководителям ИТ придётся поддерживать AI‑помощь в разработке, даже если это не было запланировано, и строить устойчивые механизмы ответственности на случай смены ролей или ухода сотрудников.
Использование AI в бизнесе выросло за последние годы, и написание или оптимизация кода — одна из главных задач. При этом многие организации ещё не выстроили адекватные рамки управления и ответственности, что приводит к значительному объёму кода без понятного владельца.
Лучше заранее ответить на ключевые вопросы об ответственности, ещё до того, как будет написана первая строка кода. Это помогает отнести приложение к подходящей группе риска и определить, нужно ли его формализовать и назначить владельца.
Кто будет звонить в ИТ при сбое? Что произойдёт, если создатель уйдёт или сменит роль? Работа с клиентскими данными или системами учёта задействована? Можем ли мы позволить себе полностью потерять этот инструмент?
Понимание типа приложения позволит определять, что можно оставить в неформальном виде, а что требует документирования, усиления защиты и назначения формального владельца. Скрипт для личной продуктивности будет сопровождаться иначе, чем автоматизированный рабочий процесс, затрагивающий клиентские данные и отчётность.
Классические подходы к распределению ролей, такие как RACI‑матрицы, остаются полезными, но «vibe‑кодинг» добавляет сложность: ответственный и эксперт могут быть разными людьми или же эксперт вовсе отсутствует. Вопросы права на интеллектуальную собственность также усложняются и требуют участия юридического отдела, однако оперативная ответственность остаётся первоочередной задачей.
Невозможно назначить владельца для того, о чём ИТ не знает, а пользователи не станут сообщать о своих экспериментах, если ожидают жёстких санкций. Лучше выстраивать модель сотрудничества, при которой сотруднику проще заявить «я создал полезный инструмент» и получить помощь в его устойчивом сопровождении.
Партнёрский подход также повышает шанс обнаружить уязвимости в сгенерированном коде до того, как они перерастут в инциденты. Доверие к ИТ стимулирует раннее выявление проблем и снижает риск дорогостоящих утечек или компрометаций.
Признаки того, что неформальное приложение переросло свои рамки, обычно очевидны задним числом: зависимость множества пользователей, интеграция с ключевыми системами, неспособность создателя объяснить работу решения или существенное расширение функционала. Любой из этих сигналов указывает на необходимость формализации.
Передача поддержки не обязана быть сложной, но должна происходить: версия, созданная пользователем, часто является прототипом, а задача ИТ — превратить её в надёжное производственное решение. Такое понимание превращает передачу ответственности в совместную работу, а не в конфискацию.
Поскольку практика «vibe‑кодинга» ещё формируется, структуры ответственности, которые вы внедрите сейчас, повлияют на то, как компания будет управлять AI‑сгенерированными приложениями в будущем. Для этого не требуется радикальная перестройка — важнее упростить процесс вовлечения новых приложений и затруднить прохождение критичных инструментов незамеченными.
Комментариев