
25 июня в прямом эфире прошёл третий батл no-code/low-code, и в этот раз к двум командам неожиданно добавилась третья.
Кейс батла — реальное решение с Awards 2026: проверка реквизитов договора генеративным ИИ (Systeme Electric / Авис Эксперт).
В батле принимали участие:
🔵 Команда Low-code: Ольга Пичкова, Андрей Логвинов показали, как решение сделано в продакшене.
🟢 Команда No-сode: Дмитрий Шутов, Дмитрий Зайцев в прямом эфире совместными усилиями собрали свой вариант без кода.
🟣 Команда Vibecode: Алексей Присяжный, Дмитрий Дунаев вместо ручной настройки описали задачу ИИ и получили сразу 2 результата.
Запись доступна на RuTube и YouTube.
В прошлом году мы просили вас предложить свою реализацию одного из кейсов батла.
В этот раз всё наоборот: кейс на следующий батл ищем мы, а предлагаете его вы.
Пришлите свою реальную задачу, а мы, совместно с экспертами батла, выберем самую интересную.
Условия
Комментарий должен включать в себя:
Комментарии принимаются до 1 августа.
Эксперты батла выберут самый интересный кейс, а автора(ов) мы пригласим на сцену следующего батла, но не зрителями, а уже в роли участника(ов), кто будет защищать свой кейс в эфире.
И самое главное – приз!
В этом году автор самого интересного кейса сможет выиграть один из 3 вариантов на выбор: настольную игру, перкуссионный массажер или рюкзак.
Ждем ваши кейсы и желаем удачи!
Алексей Плисяжный надо поправить)
из интересных задач например есть зеркальные договора, внутригрупповые документы когда одним директумом пользуется группа компаний из нескольких НОР и между собой обмениваются документами. как из исходящего сделать входящий, как верно передать договор итд итп
Станислав, Да, спасибо! получилось детским голосом прочитать)
Надеюсь, Алексей не обидится)
Станислав, ждем ваш кейс!
Предлагаю кейс, который сейчас находится у нас на стадии проработки (Станислав Якименко).
Задача
Заказчик уже разработал цифрового помощника на базе RAG. Он отвечает на вопросы производственных специалистов, используя технологические инструкции, СТО и другие регламентирующие документы.
Пилот был проведён примерно на 300 документах. Пользователи протестировали помощника, оценили хорошие и плохие ответы, после чего возникла задача существенно расширить охват документации.
В перспективе единым электронным архивом заказчика должен стать Directum RX. Поэтому необходимо:
Именно разграничение доступа является основной причиной интеграции RAG-помощника с Directum RX.
Возможные подходы
Кейс можно реализовать несколькими способами:
Особенно интересно сравнить, где именно должна выполняться фильтрация: при индексации документов, при поиске либо непосредственно перед формированием ответа.
Ожидаемый результат
Пользователь задаёт вопрос цифровому помощнику и получает ответ только на основании актуальных документов, доступных ему в Directum RX. Ответ должен содержать ссылки на исходные документы, а изменения документов и прав доступа должны автоматически учитываться в RAG-системе.
В долгосрочной перспективе тот же помощник можно развить до ИИ-агента для работы с Directum RX: просмотра своих заданий и истории, согласования документов, подготовки отчётов и выполнения других действий от имени пользователя.
Решил немного пофлудить — подарок за участие понравился, правда наверное я его использую неправильно.

Второй кейс — автоматическое описание реализованной функциональности.
ИИ-агент анализирует код разработки и формирует в Markdown описание того, как работает реализованная функция.
На выходе создаются несколько вариантов документации:
Получившиеся комплекты «Как на самом деле реализовано» автоматически складываются в базу знаний и обновляются при изменении кода.
Без vibecode тут не обойтись, альтернативы решения с low-code и no-code затрудняюсь придумать.
Как вариант кейса - бросили на задачу и разберись, как на самом деле работает (и почему вообще работает).
Станислав,
Кейс ВГР
В одной системе Directum RX работает группа компаний (несколько НОР). Требуется корректно обрабатывать внутригрупповые документы которые пересылаются между компаниями из этого же директума.
Например Исходящее письмо из одной компании в другую компанию должно создавать Входящее письмо в другой компании. Соответвенно у обоих этих документов есть свои этапы согласования, этапы обработки документа, регистрация, свои права доступа и т.д.
Закрыл ее low-codoм:
Создал блок скрипт, на схеме расположил его в конце маршрута нужного типа документа. Скрипт создавал новую карточку документа нужного типа, копировал туда тело, подписи итд, отправлял по опредленному маршруту уже в другой НОР.
Скриншотов нет - NDA.
Кейс подписания УКЭП по совместительству
Есть группа компаний в одном директуме, есть сотрудники - совместители, у которых несколько карточек сотрудников в разных НОР, но учетная запись только для основного места работы, включено замещение на этих сотрудников чтобы с учетной записи он видел все свои задания.
Сотруднику приходит задание на подписание по совмещению (в замещение), но при выполнении через замещение он не может подписать т.к по замещению не передается право подписи.
Решено через кучу настроек прав подписи и правильным выбором сертификата при подписании.
там еще добавляет проблем МЧД.
ну проще было бы еще сделать 3 логина и пусть за каждый заходит подписывает.
но интересно можно ли было это еще решить как-то)
Авторизуйтесь, чтобы написать комментарий