За последнее время в разговорах с ИТ-командами у меня сложились два наблюдения.

Первое – про low-code Платформы стали действительно мощными: на них можно строить сложные корпоративные решения. Но вместе с функциональностью вырос и порог входа. Нужно понимать логику конкретной платформы, ее модели, инструменты, а иногда и скрипты. Получается интересный парадокс: low-code уменьшает объем ручного кода, но не всегда уменьшает зависимость от платформенной экспертизы.

Второе – AI и vibe coding Здесь маятник качнулся в другую сторону. Идею действительно можно очень быстро превратить в работающий сервис. Но первая версия — только начало. Дальше появляются интеграции, доступы, данные, безопасность, тестирование, версии, поддержка. А потом бизнес приходит с очередным изменением.

Сгенерировать стало проще. Управлять тем, что сгенерировано – всё ещё отдельная задача. И вот здесь интересно, как меняется сам запрос к платформам.

В LogicBPM Platform AI не существует отдельно от среды разработки и не оставляет после себя решение, которое потом нужно заново «оборачивать» корпоративным контуром. Задачу можно описать обычным языком, AI помогает создать или изменить основу процесса, данных или интерфейса – а результат остается частью управляемой модели платформы: с ролями, правилами, интеграциями и версиями.

Не менее важно то, что происходит после запуска. В продукте есть утвержденная рабочая версия проекта, а параллельно команда может готовить изменения в изолированных черновиках: несколько участников могут дорабатывать решение, проверять изменения и передавать их на согласование, не затрагивая то, что уже работает.

И в этом для меня одна из ключевых ценностей платформенного подхода: обычное изменение процесса не должно каждый раз превращаться в новый проект с вендором или интегратором.

В сложных задачах внешняя экспертиза, конечно, нужна. Но внутренняя команда должна иметь возможность самостоятельно развивать значительную часть решения. Поэтому LogicBPM для нас – не гонка за количеством функций и не просто «low-code + AI». Это возможность решить более практичную задачу: дать скорость создания, но не потерять управляемость, когда решение начинает жить, меняться и расти внутри компании.

Первую версию сервиса сегодня действительно можно сделать быстро. Но настоящая разница становится заметна на десятой – когда всё уже работает, а бизнес снова просит что-нибудь поменять. Что для вас важнее: скорость первого запуска или стоимость и сложность каждого следующего изменения?