Дмитрий Старов: «Low-code становится фундаментом для AI-нативной разработки»

Директор департамента «Инструменты и технологии разработки» компании «Диасофт» в эфире AM Live, посвященном платформам no-code/low-code и роли искусственного интеллекта в разработке, рассказал о том, почему low-code превращается из «инструмента для тех, кто не хочет кодить», в фундамент для AI-нативной разработки, и почему без него ИИ-агенты рискуют утонуть в техническом долге.

Эфир собрал представителей российских вендоров, каждый из которых развивает собственную платформу разработки. Разговор шел о том, как устроен российский рынок no-code/low-code, чем эти платформы отличаются от BPM, RPA, iPaaS и классической разработки, какие сценарии автоматизации действительно работают, как выбрать платформу и провести внедрение, не получив «зоопарк» мини-приложений и новый слой теневого ИТ.

Дмитрий Старов: «Low-code становится фундаментом для AI-нативной разработки». Рис. 1

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

No-code и low-code принципиально разные

Сначала нужно уточнить терминологию. По словам Дмитрия, no-code и low-code часто путают, но это принципиально разные подходы. No-code — инструмент для так называемых citizen developers, непрофессиональных программистов, которые могут вообще не иметь опыта в разработке. Low-code — платформа для профессиональных разработчиков, которые не хотят заниматься рутиной и тратить время на бойлерплейт, имея в виду шаблонный, повторяющийся код, необходимый для работы программы, но не содержащий уникальной бизнес-логики.

Проведя аналогию с двумя подходами к строительству зданий, эксперт добавил, что low-code, образно говоря, это фундамент и скелет для стен, а no-code больше похож на здание с готовым интерьером, построенное по принципу «заходи и живи». Оба подхода имеют право на существование: «Low‑code задает определенный стандарт, своего рода каркас, — пояснил спикер, — Это не только простой генерируемый код, но и стандартизированная основа, на которую разработчики «наращивают» функциональность. В одних случаях ее нужно меньше — например, для простых CRUD‑операций или генерации объектов баз данных. В других — требуется сложная логика, скажем, расчет графика платежей. Тут уже в работу включается человек или ИИ».

Как развивалась потребность в low-code?

Отвечая на вопрос о том, какие тренды толкают рынок в этом направлении, Дмитрий Старов говорил не о рыночных драйверах вообще, а о том, откуда все это «вылезло на практике». Он напомнил, что Gartner говорил о low-code еще с шестнадцатого года. То есть тема не новая, просто потребовалось десять лет, чтобы к ней пришли на практике.

Эксперт обозначил три ключевых момента. 

Первый — дефицит разработчиков. Изначально системы low‑code и no‑code как раз и предназначались для решения этой проблемы. Количество задач постоянно росло, а программисты всегда были в дефиците и обходились дорого. Сегодня объем задач заметно увеличился, но число опытных специалистов — так называемой старой гвардии — по понятным причинам сокращается. При этом настоящими сеньорами, высококвалифицированными разработчиками, не становятся мгновенно: для этого требуется время и серьезная практика.

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

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

«Система неизбежно усложняется и рискует превратиться в хаос, — отметил он, — С небольшим монолитом еще можно смириться, но с масштабным работать гораздо сложнее — даже если его разбили на микросервисы. А если каждый фрагмент написан небрежно, сопровождать такую систему становится особенно трудно. Low‑code‑системы как раз задают четкую основу и единые правила: модули имеют схожую структуру, API описывается по единому шаблону, а документация выглядит единообразно. Это приобретает огромную важность».

Для enterprise-платформ нужны оторгаемость и кастомизация

Говоря о выборе платформы, спикер подчеркнул, что для серьезной enterprise-платформы критически важны кастомизация, расширяемость, безопасность и отторгаемость. «Сейчас неохотно внедряют low‑code‑ и no‑code‑системы, где впоследствии невозможно избавиться от привязки к вендору, — сказал он, — В крупных enterprise‑компаниях никто не хочет попадать в зависимость от поставщика — то есть сталкиваться с вендор‑локом. Зайдите в Сбербанк, ГПБ, Альфа‑Банк — и убедитесь сами: ни один из наших клиентов не желает зависеть от команды разработчиков, к которой порой приходится чуть ли не умолять обратиться для исправления какой‑нибудь ошибки».

По его словам, в компании «Диасофт» линейка продуктов построена по иному принципу. Сначала генерируется качественный код, такой, будто его написал опытный программист, и его можно свободно использовать вне платформы: «Вы просто берете его, копируете в нужное место — и дальше можно вообще не возвращаться к low‑code». 

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

Low-code должен быть фундаментом для ИИ-разработки

Сегодня low-code-системы становятся чуть ли не главным фундаментом для AI-нативной разработки. «Разработчик, использующий Claude Code или Copilot, может сгенерировать огромный объем технического долга — и потом разбираться с ним будет крайне непросто, — предупредил Дмитрий, — В серьезном бизнесе приложения эксплуатируются годами: их нужно сопровождать, модифицировать, дорабатывать, устранять в них ошибки. Поэтому критически важно, чтобы фундамент системы был четким, понятным и простым для освоения — то есть имел низкий порог входа».

Есть и «ноу-хау» по так называемой догенерации кода, созданного в среде low-code. По оценкам «Диасофт», около 70% кода обычного приложения генерируется low-code-системой, остальное дописывает ИИ-агент. Это дает экономию на токенах и снижает количество галлюцинаций.

«Агенту задали базовую структуру и указали: здесь нужно дописать, там — дополнить. При таком подходе он уже не сможет ее испортить», — пояснил эксперт.

Спецификации — новое золото

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

«Спецификация — это новое золото, новая нефть, — считает Дмитрий Старов, — Код уже не столь ценен: если у вас есть продуманная спецификация, нужный код можно без труда сгенерировать заново буквально за пять минут. Именно к такой модели мы движемся».

В рамках этой модели работа с low‑code‑системой строится так: часть элементов система генерирует самостоятельно, а в отдельных местах требуется написать код — но строго по заданным правилам и спецификациям. При этом четко обозначаются запреты: что делать нельзя, а что допустимо.

Эксперт отмечает, что опытные разработчики нередко выражают опасения: «А вдруг ИИ‑агент что‑то упустит? Например, начнет выполнять запросы к базе данных внутри цикла?» В ответ на такие сомнения он советует прямо прописать в спецификации для агента четкое требование: «Не выполняй запросы к базе данных в цикле». Подобные правила‑ограничения реализуются через навыки агента, эксперт подчеркивает, что это значимая часть работы — и компания целенаправленно вкладывается в их проработку.

Один работает, два критикуют

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

«Они вовсе не стремятся к согласию — у них другая задача и другой ракурс оценки, — поясняет спикер, — Им передают правила и архитектурные стандарты, и они независимо анализируют код, пытаясь оценить его с этих позиций, а затем возвращают свои замечания».

Это часть мультиагентной платформы Digital Q.Agents. Она не привязана к какой-то одной модели (LLM); в ней можно использовать любые популярные ИИ-агенты (Open Code, Qwen Code, Claude Code и т.п.).

«Платформа отвечает за обвязку: она задает, какие правила применять, что допустимо, а что — нет. Именно эти механизмы, по сути, ценнее, чем сама языковая модель», — подчеркнул эксперт.

Токеномика и качество кода

Когда речь зашла о том, что разработка с помощью ИИ часто влетает в копеечку, Дмитрий Старов отметил, что низкий уровень модели не всегда означает плохой результат. Выбор модели сильно влияет на экономику всей связки: «Зачастую нет необходимости переплачивать за топовую модель. Можно выбрать более простую и недорогую: для большинства бизнес‑задач ее будет вполне достаточно, при этом расходы на токены снизятся примерно на 80%».

При этом качество кода по‑прежнему остается критически важным. Спикер напомнил, что ИИ нередко предлагает не объективно лучший вариант кода, а лишь вероятностно оптимальный — то есть просто один из множества возможных.

«Революцию нельзя отменить, ее надо возглавить»

Критику ИИ эксперт считает отчасти справедливой. Как говорилось выше, модели действительно часто выбирают не лучший вариант кода, а какой-то средний из множества. Но с самим приходом ИИ в разработку бороться, по его мнению, бессмысленно: «Революцию нельзя отменить, ее надо возглавить. Так сказал Макиавелли, по-моему. То есть бороться с ней бессмысленно, ее нужно поставить на службу».

Именно эту задачу, по его словам, решают low-code и такие техники, как Specification Driven Development (SDD) — метод разработки, основанный на спецификациях. «Спецификация и low‑code позволяют существенно сократить число вариантов — со ста до десяти, а в идеале — до единственного, который и должен выбрать ИИ», — пояснил эксперт.

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

ИИ усиливает low-code

Эксперт признался, что раньше полагал — с появлением мощных LLM подход low‑code начнет постепенно исчезать. Однако со временем пришло понимание, что ключевую роль играет не сама LLM, а «обвязка» — так называемый харнесс. При этом остро встал вопрос технического долга: ассистенты успели накопить огромный объем недоработок, который превратился в настоящий снежный ком.

«Задача low‑code‑подхода — навести в этом хаосе порядок, — подчеркнул он, — Его значимость сейчас существенно возросла. Да, по сравнению с использованием чистого Claude расход токенов выше: задействовано много агентов, накоплено немало наработок, а у low‑code есть собственные правила, которым они обучаются. Но это оправдано: в результате вы получаете качественный, структурированный, производительный, масштабируемый и безопасный код — достичь такого уровня, полагаясь только на ассистента, крайне сложно».

Советы заказчикам

В ходе дискуссии Дмитрий Старов поделился практическими рекомендациями для тех, кто только планирует внедрять low‑code и ИИ‑агентов: «Важно четко представлять всю цепочку: откуда поступают требования, кто их анализирует, как идет создание продукта, как он проходит тестирование, выпуск и доставку пользователю. Иными словами — весь путь от идеи до релиза, включая CI/CD».

Лишь после этого, по его мнению, стоит подбирать подходящую low‑code‑систему — с учетом требований к масштабированию, кастомизации и работе с собственным кодом: «Затем обязательно оцените, насколько система готова к интеграции с ИИ. Подумайте, каких усилий потребует обучение ваших агентов работе с этой low‑code‑платформой. И, наконец, проверьте, предусмотрены ли в самой системе какие‑либо встроенные возможности для агентов — не просто CI/CD, а полноценный AI‑native SDLC».

Команды будущего и AI-среды

Эксперт прогнозирует масштабные изменения в структуре ИТ‑команд. По его оценке, в течение двух‑трех лет практически все компании создадут собственные платформы или фреймворки, а примерно через пять лет команды трансформируются и станут состоять из продакт‑инженеров и системных групп, которые будут обслуживать SDLC‑конвейер: «Больше не будет отдельных ролей вроде внедренцев, разработчиков, аналитиков, архитекторов, тестировщиков или девопсеров. На первый план выходят продакт‑инженеры — специалисты, способные вести задачу от старта до полного завершения. Если раньше над проектом работала группа из 10–12 человек — бэкенд‑разработчики, фронтендеры, тестировщики, — то теперь эту работу смогут выполнять три‑четыре продакт‑инженера с расширенным профессиональным бэкграундом, достаточным для автономности такой команды».

По мнению эксперта, отдельная команда должна быть выделена специально для поддержки конвейера. «Если в мультиагентской системе произойдет сбой, вся команда должна оперативно реагировать — конвейер не должен становиться узким местом. Это критически важный элемент: если он остановится, можно сказать, что «свет выключили» — и тогда встанет значительная часть производственных процессов», — подчеркивает спикер.

Главный вывод, который делает эксперт, заключается в том, что low‑code не исчезнет с развитием ИИ, а, напротив, станет ключевой средой, где ИИ‑агенты смогут надежно и эффективно разрабатывать корпоративные приложения.

Опубликовано 29.09.2026

Похожие статьи