Зачем low-code в эпоху AI: от генерации кода к управлению агентами

Еще несколько лет назад low-code воспринимался прежде всего как способ ускорить разработку. Но с появлением генеративного AI вопрос стал звучать иначе: если код теперь может писать модель, зачем вообще нужны low-code и no-code платформы?

Этому вопросу и был посвящен эфир AM Live, в котором приняли участие Дмитрий Старов («Диасофт»), Антон Симуни (ИТ-экосистема «Лукоморье»), Ева Беляева (Security Vision) и Александр Жуланов (SimpleOne). Эксперты обсудили, где проходит граница между low-code и no-code, какие задачи такие платформы решают в enterprise-разработке, как в этот процесс встраиваются AI-агенты и что происходит с привычными ролями внутри IT-команд.

По мнению Дмитрия Старова, директора департамента «Инструменты и технологии разработки» компании Диасофт, low-code – это уже про то, как удержать разработку под контролем. Особенно теперь, когда код начинают массово генерировать AI-агенты. Платформа в новых условиях становится набором правил и ограничений: она задает архитектуру, стандарты, готовые компоненты и не дает агенту каждый раз изобретать систему заново.

Low-code – не обязательно «разработка без разработчиков»

В начале дискуссии Дмитрий Старов отметил, что стоит разделять low-code и no-code прежде всего по тому, для кого предназначены эти подходы.

No-code, по его словам, в большей степени рассчитан на citizen developers – пользователей, которые могут вообще не быть профессиональными программистами. Low-code, напротив, ориентирован на разработчиков, которым необходимо сократить объем рутинной работы.

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

Но здесь важна не только скорость генерации кода. Low-code-платформа должна задавать определенный «скелет» разработки: единые архитектурные паттерны, лучшие практики и правила, по которым строятся приложения.

Именно стандартизацию он считает одной из главных ценностей low-code для крупных компаний.

Чем больше система, тем важнее единые правила

Один из факторов развития low-code – дефицит сильных разработчиков. Задач становится больше, а количество опытных senior-специалистов не растет с той же скоростью.

Второй фактор – требования бизнеса к срокам. Разработку необходимо вести быстрее, изменения выпускать чаще, а количество ошибок при этом не должно увеличиваться.

Третья причина – рост сложности самих корпоративных систем.

В качестве примера Дмитрий рассказал об одной из продуктовых линеек, где в момент его прихода работало восемь программистов, а впоследствии команда выросла примерно до 300 человек. При таком масштабе проблема уже не только в объеме кода. Если разные части системы создаются по разным принципам, продукт постепенно становится все сложнее сопровождать.

Low-code в такой ситуации позволяет закрепить общие правила: модули получают похожую структуру, API описываются единообразно, документация также формируется по общим принципам. То есть речь идет уже не столько о том, чтобы писать меньше кода, сколько об управлении сложностью разработки.

Открытый код: почему для enterprise это важно  

В некоторых low-code платформах сгенерированная логика остается внутри собственной среды исполнения. В экосистеме Digital Q, которую развивает «Диасофт», используется другой подход: платформа генерирует обычный программный код.

Дмитрий отдельно подчеркнул требование к его отторгаемости: созданный код должно быть возможно забрать из платформы и использовать дальше независимо от нее.

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

По словам Дмитрия, заказчикам важно иметь возможность вмешаться в созданное решение: изменить его, дополнить или продолжить разработку своими силами. Поэтому жесткая зависимость от платформы и невозможность отделить от нее результат разработки становятся существенными ограничениями.

В «Диасофт» этот подход реализуется в Digital Q – экосистеме low-code-платформ, ориентированной именно на создание enterprise-приложений.

AI меняет роль low-code

Отдельная часть дискуссии экспертов в эфире AM Live была посвящена генеративному AI. На первый взгляд распространение AI-инструментов ставит под вопрос необходимость low-code: если модель умеет генерировать код самостоятельно, зачем нужен еще один промежуточный слой?

Дмитрий отметил, что AI умеет создавать код, но для промышленной разработки этого недостаточно. AI-агенту необходимо объяснить, какими методами пользоваться, какие стандарты соблюдать, как строить сервисы и в каких архитектурных рамках работать.

В этом сценарии low-code-платформа становится своеобразной «обвязкой» (harness) для AI-агента. Она задает доступные платформенные методы, ограничивает допустимые действия и позволяет проверять соблюдение стандартов. Это должно уменьшать количество ошибок, не давать агенту уходить в сторону от заданной архитектуры и предотвращать лишний расход токенов.

Поэтому к привычным требованиям – безопасности, расширяемости и отторгаемости – добавляется еще одно: AI-ready или AI-driven готовность платформы.

Иными словами, задача платформы постепенно меняется. Раньше она в первую очередь помогала разработчику быстрее создавать приложение. Теперь она дополнительно должна определять рамки, в которых работает AI.

Автоматизировать хаос – плохая идея

Дмитрий отдельно подчеркнул: само появление AI-агентов не решает организационные проблемы разработки.

Если в компании не определено, кто ставит задачи, кто утверждает архитектуру, кто отвечает за выпуск, где хранятся существующие компоненты и как организовано их повторное использование, AI не устранит этот хаос.

Перед построением AI-конвейера необходимо сначала выстроить сам процесс производства ПО. Должны быть понятны этапы, роли и ответственные, определены стандарты и существовать каталог уже созданных модулей.

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

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

От одного AI-агента к мультиагентной системе

В дальнейшем процесс разработки может строиться не вокруг одного универсального AI-агента, а вокруг группы специализированных агентов.

Один агент может анализировать существующие компоненты, другой – формировать или реализовывать решение, следующий – выступать в роли «критика» и проверять, соответствует ли результат требованиям и архитектурным стандартам. Если проверка выявляет проблему, задача возвращается на предыдущий этап. Дмитрий описывает это как мультиагентную систему, за которой при этом продолжает наблюдать человек.

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

Команды разработки тоже будут меняться

Автоматизация затрагивает не только инструменты, но и структуру IT-команд.

По мнению Дмитрия, традиционная модель, в которой отдельно работают аналитики, архитекторы, backend- и frontend-разработчики, тестировщики, DevOps-инженеры и другие специалисты, будет постепенно меняться. На первый план могут выйти product engineers – специалисты, способные провести задачу через несколько этапов жизненного цикла продукта.

При этом узкие компетенции полностью не исчезнут, но скорее станут дополнительными специализациями внутри более универсальных команд. Команды будущего могут состоять из двух-четырех таких специалистов с разным бэкграундом вместо более многочисленных групп с жестким разделением ролей.

Одновременно потребуется отдельная команда или функция, отвечающая за сам мультиагентный конвейер. Если значительная часть разработки зависит от него, его отказ становится критической инфраструктурной проблемой.

Разным заказчикам low-code нужен для разных задач

В ходе эфира Дмитрий также рассказал, что заказчики используют low-code по-разному.

Некоторым заказчикам нужен прежде всего готовый продукт. Для таких компаний не особенно важно, каким способом он был создан. Но возможность самостоятельно изменить интерфейс, форму или отдельный бизнес-процесс становится полезным дополнением.

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

У наиболее крупных организаций уже есть собственные большие команды разработки. Для них low-code интересен, например, возможностью автоматически создавать типовую обвязку сервисов и обеспечивать единые правила интеграции, оставляя сложную логику собственным разработчикам.

Есть и еще один сценарий – покупка не готового отраслевого продукта, а самой платформы разработки, чтобы создавать на ней собственные ИТ-решения. Так, например, делают технологические партнеры компании «Диасофт».

Что в итоге

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

Появление AI добавляет еще один уровень. Теперь платформа может задавать правила уже не только разработчику, но и AI-агенту – определять доступные методы, контролировать архитектурные ограничения и участвовать в автоматических проверках.

При этом переход к AI-разработке начинается не с подключения очередной модели. Сначала компании необходимо формализовать собственный процесс создания ПО. И только после этого имеет смысл строить поверх него мультиагентный конвейер.

Таким образом, AI-агенты не столько заменяют разработчиков, сколько трансформируют их роль: фокус смещается от ручного кодирования к работе с требованиями, архитектурой, правилами и контролю результатов, а сами команды становятся более компактными и универсальными.