Привет! Меня зовут Игорь Росляков, я технический писатель. По приглашению тимлида DevRel-команды Владимира Верхотурова готовлю цикл статей на тему ИИ-ассистированной разработки решений для Битрикс24.
Есть распространённые опасения, связанные с вайб-кодингом: руководители не хотят, чтобы у каждого отдельного сотрудника появилось своё ПО, и этот хаос повредил уже настроенные процессы. В то же время запретить создание приложений через ИИ-агентов может затормозить бизнес и лишить выгодных возможностей, если новое ПО действительно полезно.
Какое решение мы предлагаем: разрешить сотрудникам вайб-кодить и сделать из всех приложений одну витрину, которой заведует один ответственный — администратор.
Как это может работать и как сделать такой хаб-витрину в Битрикс24 с нашим агентом Коворк/Код — дальше в статье.
Содержание
Почему много внутренних приложений — это нормально
Опасение администратора или ИТ-директора понятно: если дать сотрудникам возможность самостоятельно собирать приложения, через несколько месяцев их будут десятки. Кто будет за всем этим следить?
Например, менеджер по продажам сделал приложение, которое собирает сделки в удобную таблицу и позволяет менять их статус. Коллеги тоже начинают им пользоваться, но не все. В итоге часть сотрудников работает через стандартный процесс в CRM, часть — через личное приложение, при этом какие-то действия обходят привычные автоматизации, и руководитель уже не понимает, где находится актуальная информация и по каким правилам работает отдел. Получается хаос и зоопарк из разных сервисов.
Теперь смотрите: большое количество приложений само по себе ещё не проблема. Проблема возникает, когда личный эксперимент без контроля превращается в инструмент команды. Значит, управлять нужно именно этим переходом:
Пусть сотрудник свободно проверяет идеи на своей стороне, а если приложением начали пользоваться другие, оно проходит следующий уровень контроля.
Какие нужны расходы на разные приложения
В классической разработке каждое новое приложение обычно означало отдельные затраты на разработку, инфраструктуру и поддержку. Поэтому компании привыкли заранее ограничивать количество внутренних решений. Но с вайбкодингом экономика поменялась, и деньги чаще всего тратятся в двух местах: на работу ИИ-агента при создании и доработке приложения и на серверные ресурсы для его хранения и поддержания работы.
Для приложений на наших порталах мы используем платформу Битрикс24 Вайбкод, которая по умолчанию помогает поднимать два вида серверов: отдельные виртуальные машины либо общий сервер для нескольких приложений. Во втором случае неактивные приложения переходят в спящий режим и не потребляют вычислительные ресурсы. Исходники при этом сохраняются в хранилище с версиями.
С такой системой не нужно ограничивать количество экспериментов заранее. Сотрудник может собрать несколько личных приложений, проверить разные идеи и отказаться от тех, которые не пригодились.
Что стоит вынести в регламент: старые приложения не нужно удалять сразу после эксперимента, но администратор должен периодически проводить ревизию: проверять давно неиспользуемые приложения, их владельцев и занятые серверы. Действительно ненужные решения нужно архивировать или удалять.
Три жизни одного приложения
Сейчас получается, что у приложения есть три стадии:
Стадия |
Кто пользуется |
Что с ним происходит |
Личная |
Автор |
Экспериментирует, проверяет идею |
Командная |
Сотрудники или отдел |
Решение оказалось полезным, его используют несколько человек |
Корпоративная |
Весь портал |
Решение прошло отбор и опубликовано для остальных |
Личное приложение можно спокойно бросить. Командному уже нужен владелец. Корпоративное должно пройти проверку и попасть в общий каталог.
Чем шире аудитория приложения, тем больше к нему требований.
Контроль начинается, если приложение становится общим
Схема простая:
сотрудник создаёт приложение →
оно приживается в отделе →
автор отправляет заявку →
администратор проверяет приложение →
после одобрения оно попадает в хаб — корпоративную витрину.
Обратите внимание, что заявку тоже можно отправлять на хабе. Корпоративная витрина-хаб объединяет два вида приложений, которыми пользуются:
Отдел или команда.
Вся компания — то есть весь портал сотрудников.
С таким подходом компания контролирует распространение приложений, не мешая сотрудникам проверять идеи.
Выглядеть это может так. Сотрудник заходит на витрину и видит два вида приложений — для своего отдела и общие:
На этапе заявки администратор смотрит, кто отвечает за приложение, с какими данными оно работает, какие права использует и не дублирует ли уже существующие. После проверки решение можно открыть для отдела или всего портала.
Что умеет хаб приложений
Это единая корпоративная витрина приложений, которую администратор собирает для своей компании. Она показывает сотруднику только те приложения, которые относятся к его работе. Именно хаб помогает отделить личные эксперименты от решений, которые уже можно использовать шире.
Коротко, что он умеет:
Показывать внутренние приложения компании в одном месте, чтобы сотрудникам не приходилось искать их по ссылкам и чатам.
Работать в правах конкретного пользователя через ключ авторизации, чтобы каждый видел только доступные ему данные и инструменты.
Служить точкой публикации одобренных приложений — в хаб попадают решения, которые прошли проверку администратора.
Разделять приложения по отделам или категориям, чтобы витрина оставалась понятной даже при большом количестве решений.
Хаб превращает множество разрозненных внутренних приложений в управляемый корпоративный каталог.
Сам хаб тоже создаётся как вайбкод-приложение, пока что в формате встроенного плагина такого инструмента нет. В следующем разделе рассказываем, как повторить такое решение.
Создаём хаб приложений
Для создания мы использовали нашего ИИ-помощника для работы с платформой Битрикс24 Вайбкод Коворк/Код:
Промпт для создания хаба с учётом наших ошибок во время разработки:
Собери и задеплой рабочее приложение «Хаб приложений» -- корпоративную витрину внутренних приложений для Битрикс24. Это витрина, разложенная по отделам реальной оргструктуры портала, которую видят все сотрудники, но каждый -- своё, а админ одобряет/отклоняет заявки на включение приложений. ## Что должно быть 1. Витрина работает на КЛЮЧЕ АВТОРИЗАЦИИ (а не на общем API-ключе): - личность и роль приходят из заголовков шлюза: X-Vibe-User-Id (только цифры; значение с префиксом net_/share:/vibe: в REST Битрикс24 не подставлять), X-Vibe-User-Role (ADMIN/MEMBER), X-Vibe-User-Name-Encoded (читать через decodeURIComponent, не сырой X-Vibe-User-Name); - отдел сотрудника читается из оргструктуры портала: /users/:id → departmentId, список отделов -- /departments; - обычный сотрудник видит корпоративную витрину (approved для всех) + приложения своего отдела (scope=team, departments) + свои личные (scope=personal); - администратор портала дополнительно видит панель модерации. 2. Механика заявок: - сотрудник подаёт заявку через кнопку «Подать заявку»: название, описание, категория, ОБЯЗАТЕЛЬНАЯ ссылка на задеплоенное приложение (http(s)), «куда подаём» -- отдел или портал; заявка получает статус pending; - админ видит заявку (включая имя подавшего), может открыть само приложение по ссылке, и решает: одобрить (с выбором области -- весь портал ИЛИ конкретный отдел из оргструктуры) или отклонить; одобренное появляется в выбранной области. 3. Данные хранятся в JSON-файле /data/hub-catalog.json (переживает передеплой), атомарная запись (tmp + rename), seed демо-приложений только при первом запуске против реальных отделов. 4. Эндпоинты: GET /api/hub (витрина по роли/отделу), GET /api/hub/admin (только ADMIN), POST /api/hub/apps (заявка), POST /api/hub/admin/apps/:id (модерация + выбор области), GET /api/health. В портал ходит ТОЛЬКО сервер, ключ не уходит в браузер. Портал отвечает десятки секунд -- вызовы на таймере/в фоне, таймаут 180 с, внутри запроса посетителя в портал не ходить. 5. Стек: Node на node:http без внешних зависимостей, package.json со start: "node server.js", сервер на process.env.PORT || 3000. Интерфейс в public/ (index.html, styles.css, app.js), безопасный рендер через createElement/ textContent, без innerHTML из пользовательских данных. Статику отдавать с Cache-Control: no-cache. Роль ADMIN проверять на сервере. ## ОБЯЗАТЕЛЬНЫЕ требования по процессу (из прошлого опыта ошибок) - Сначала проверь, что различаешь: сервер сессии (куда шлёт кнопка «Деплой» из папки) vs встроенный сервер приложения (что открывается по боковой кнопке в портале) -- это могут быть РАЗНЫЕ адреса. Сверь оба адреса явно и подтверди с пользователем, какой именно должен открываться в портале, прежде чем деплоить. - Деплой кода ≠ встройка в портал. Сначала задеплой проверенный код, потом отдельно настраивай встройку. - Deploy-ключ: один vibe_api_... = один сервер. Если старый ключ «уже связан с существующим сервером» -- удали старые серверы и ключи и создай один новый свободный vibe_api_... на странице ключей. Новый ключ привяжется к новому серверу сам; НЕ пытайся переиспользовать занятый ключ. - Не правь код вслепую и не списывай сразу на кэш браузера. Если правки CSS/JS «не доезжают» до прода -- запроси фактическое содержимое /styles.css и /app.js с прода и сравни с локальным файлом, прежде чем менять что-либо ещё. - После деплоя проверь по факту: витрина открывается, «оргструктура подключена», кнопка «Подать заявку» открывает МОДАЛКУ (не встроенную вниз форму), заявка доходит до админа, одобрение с выбором отдела/портала работает. - Данные каталога писать только в /data (не рядом с кодом в /opt/app) -- иначе передеплой сотрёт заявки. - Если нужен доступ в портал для локальной проверки до деплоя -- сообщи, что требуется привязать ключ vibe_api_... (вставить в поле ввода или через иконку ?). Когда будешь готов задеплоить -- опубликуй на сервер сессии, сообщи точный адрес из результата деплоя (только из него, не из списка серверов) и подскажи, как открыть доступ всем сотрудникам в портале.
Что в итоге получилось:
Ниже — разделённые согласно отделам доступные приложения:
И самое интересное — отправка приложения на рассмотрение. Проверив приложение и его пользу на себе и ближайших коллегах, его можно отправить на рассмотрение администратору:
Как устроен хаб
Вот как это работает, если коротко и без глубокой технической детализации.
Сам хаб ничего не хостит: приложения, которые собирают сотрудники на платформе Битрикс24 Вайбкод, живут каждый на своём собственном сервере со своим адресом вида https://app-….vibecode.bitrix24.tech. Хаб — это витрина ссылок на них.
Каталог всех приложений хранится на сервере хаба в одном JSON-файле. Этот файл переживает передеплой. В нём для каждого приложения хранятся: название, описание, ссылка на реальное приложение, статус (pending/approved/rejected), область видимости (отдел или весь портал), кто подал заявку.
Чтобы коллеги получили возможность пользоваться приложением, есть два механизма, которые работают вместе.
1 — Видимость на витрине: каждый сотрудник видит только то, что ему положено по отделу и роли. Отдел сотрудника читается автоматически:
X-Vibe-User-Id со шлюза → /users/:id → отдел
2 — Непосредственный доступ к самому приложению. Этим управляет платформа Битрикс24 Вайбкод. Когда сотрудник жмёт «Открыть» на карточке — он переходит на https://app-….vibecode.bitrix24.tech этого приложения. В этот момент платформа (шлюз) уже аутентифицировала его (он вошёл в портал), а у самого приложения должна быть выставлена политика доступа (например, «весь портал»), чтобы он вообще туда смог попасть. Если доступ к приложению закрыт для коллег — они увидят его в витрине, но открыть не смогут.
Что должен проверять админ перед публикацией приложения
Перед добавлением приложения в общий хаб администратору достаточно проверить четыре вещи:
Владелец. У приложения должен быть ответственный, который сможет его поддерживать или передать другому сотруднику.
Дубли. Если похожее решение уже есть, лучше выбрать один общий вариант.
Права и данные. Нужно понимать, к каким данным обращается приложение и от чьего имени работает.
Актуальность. Неиспользуемые приложения стоит периодически убирать из витрины.
Если автор приложения увольняется, само приложение не должно потеряться: исходники остаются в хранилище с версиями, и их можно передать новому владельцу.
Заключение: что стоит настроить
Вот краткий чек-лист, который можно взять и попробовать применить.
Разрешить сотрудникам создавать личные приложения. На этом этапе можно не вводить отдельное согласование — человек просто проверяет свою идею.
Контролировать приложения, которые выходят за пределы одного пользователя. Для командных и корпоративных решений проверять права доступа, владельца и то, какие данные использует приложение.
Собирать одобренные решения в общем хабе и регулярно его пересматривать. Полезные приложения остаются на витрине, устаревшие и дублирующие надо убирать.
Так контроль появляется там, где приложение начинает влиять на работу других сотрудников, а личные эксперименты не блокируются заранее.