— Андрей, как специалист с опытом в разработке более 20 лет, который прошел путь от ранних корпоративных решений до современных гибридных инструментов, расскажите, когда появились термины Low-Code и No-Code и кто впервые ввёл понятие «Citizen Developer»?

— Всё началось около тридцати лет назад с инструментов Rapid Application Development. Позже, чтобы не путать их с одноимённой методологией, закрепились новые термины — Low-Code и No-Code. Первым потребителем стал корпоративный сотрудник, который не смог добиться разработки от внутреннего IT и сделал систему сам. В 2014 году Gartner назвал таких людей Citizen Developers, а сами термины обычно приписывают Forrester. И тут важно: именно внимание Gartner и Forrester превратило тему в хайп, благодаря чему рынок резко вырос в глазах инвесторов и корпораций.

— Но за эти годы ожидания и реальность разошлись: бизнес-пользователи продолжают формулировать требования, а спрос на программистов только растёт. Что пошло не так?

— Не совсем корректно говорить «пошло не так». Скорее, всё изменилось не так, как ожидалось. В бизнес-аналитике No-Code полностью прижился. Появились конструкторы для сайтов, интернет-магазинов, даже бэкенд-автоматизации. Типовые сервисы — это Wix или Zapier, а из всеобъемлющих решений можно назвать OutSystems или Bubble. У Bubble больше 4 миллионов пользователей и целая экосистема компаний, которые продают шаблоны и делают заказную No-Code разработку. Но самое интересное — рост популярности связан не с удобством самих конструкторов, а с прогрессом DevOps и облаков из мира профессиональных разработчиков. Именно они позволили спрятать развёртывание приложений «под капот» и сделали No-Code массовым.

— В Сбере вы руководили разработкой Low-Code платформы для Единой Фронтальной Системы. Там удалось мигрировать более 80% систем и сократить Time-to-Market в семь раз. Как это получилось?

— Мы сделали нишевое решение, которое позволяло быстро стартовать разработку с учётом жёстких архитектурных ограничений: все решения должны были интегрироваться «из коробки». Мы создали два типа конструкторов: одни описывали solution-архитектуру кода, включая API и интеграцию, и генерировали каркас, другие моделировали и реализовывали UI в едином стиле. Генерация шла в два этапа: сначала архитектурное решение, потом конечный код. Для того времени это было уникальное решение — аналогов на рынке тогда не было. Оно позволило параллелить разработку на десятки сценариев без накопления техдолга.

— Но, как вы отмечаете, ограничения всё равно были. С какими проблемами столкнулись?

— Первая проблема — простейшие функции. Допустим, нужно рассчитать аннуитетный платёж по кредиту. В графическом конструкторе это взорвёт вам мозг: настолько громоздко и неэффективно. Императивные языки для этого созданы, а No-Code сразу превращается в Low-Code. Тут два варианта, оба плохие. Первый — дать бизнес-пользователю скриптовый язык и превратить его в разработчика. В истории такие языки иногда становились «мейнстримом» — вспомним 1С, Visual Basic, ABAP, но это было на заре автоматизации. Второй — предусмотреть точки расширения, куда подключается профессионал. Это решение оказалось более жизнеспособным. Кроме того, мы не стали изобретать велосипед и использовали OCL (Object Constraint Language). Этот язык специально для описания условий, выражений и присваиваний — то, что нам и было нужно.

— А что с отладкой? Это же одна из главных претензий к No-Code.

— Отладка — ещё один «слабый зуб». Если постановка описана декларативно, для пользователя сгенерированный код — чистая магия. Он не понимает, где искать ошибку, и тратит время на угадывания. И это может сломать его мотивацию. Даже профессионалу тяжело: он не проектировал решение, а только специфицировал его в конструкторе. Для API-тестирования пользователи Bubble, например, рекомендуют Postman — инструмент профессиональных тестировщиков. Мы же пошли по другому пути: двухэтапная генерация позволила встроить пошаговую трассировку прямо в наш Low-Code инструмент. Пользователи были удивлены: оказалось, что ошибки делают все, но теперь их можно искать системно.

— Можно ли вывести общее правило: где Low-Code работает, а где лучше сразу писать код?

— Да. Стоимость владения Low-Code продуктом растёт экспоненциально гораздо раньше, чем у классической разработки. Поэтому он подходит для типовых приложений с уникальным контентом — лендингов, простых магазинов, учётных систем, «очередных» соцсетей. Но стоит бизнес-пользователю захотеть что-то по-настоящему уникальное, и каждый элемент новизны начинает обходиться дороже, чем разработка «по-взрослому».

— Часто говорят: упёрся в потолок Low-Code — можно легко «выйти в код». Насколько это реально?

— Вопрос хороший, но подвох в слове «легко». Да, можно и нужно «выходить в код», особенно после этапа Proof Of Concept. Это нормальная практика: показать прототип инвесторам, привлечь финансирование, а потом переписать продукт с нуля. Но при переписывании новая команда воспроизводит все ошибки, и делает это уже в тот момент, когда от неё ждут стабильности. Поэтому лёгким этот процесс не бывает.

— Вам удалось совместить работу бизнес-пользователей и профессионалов через «точки расширения». Как это помогло?

— Суть в том, что изменения бизнес-пользователя не должны ломать код разработчика. Мы сделали систему предупреждений: если правка в визуальной части делает код невалидным, пользователь получает сигнал. Это помогло избежать массы ошибок и позволило вести параллельную разработку без конфликтов.

— Сегодня многие No-Code сервисы добавляют AI-агентов. Но вы считаете, что это не решает ключевых проблем. Почему?

— Потому что эти агенты закрывают только отдельные компетенции — например, UI или UX. Это всё равно улучшения, но не по сути. Получается, мы едем в тот же тупик, только быстрее. Для пользователя это скорость, для сервиса — конверсия в платный план. Но цена этой конверсии — дополнительные затраты на вычислительные мощности. И не факт, что они отбиваются, ведь на этапе серьёзной разработки фаундер всё равно «выходит в код».

— То есть AI пока не даёт преимущества ни пользователям, ни самим платформам?

— В модели Bubble или OutSystems — нет. Эти компании вкладывались в усложнение конструкторов, чтобы удерживать пользователей. Но в гонке функциональности они проиграли инструментам, которыми пользуются профессионалы. Если у Figma в три раза больше пользователей чем у Bubble, у неё и больше возможностей развивать продукт. Поэтому Low-Code сервисам пора перестать соревноваться там, где победитель уже известен, и учиться интегрироваться.

— Значит, следующее поколение Low-Code инструментов уже не будет строиться вокруг визуальных конструкторов?

— Именно. Зачем, если уже есть десятки инструментов с открытым API? Куда удобнее загрузить спецификацию из Notion или аналога, чем мучиться с блок-схемами.

— Тогда за чем будущее? Ваши новаторские разработки GIGA IDE и AI-агенты — это и есть гибридная модель?

— Будущее в радикальных решениях. Не конструктор для аннуитетного платежа, а AI, который сам сгенерирует код на открытом стеке и выгрузит его в репозиторий. Не ручная отладка, а digital shadow на базе LLM, которая полностью покрывает поведение приложения и делает тестирование избыточным. И, наконец, «выход из кода»: возможность загрузить готовый код и превратить его обратно в спецификации и диаграммы. Это позволит командам работать так, как им привычно, и использовать свои сильные компетенции.