Привет, Хабр!

Продолжаю публиковать наши разговоры из телеграм-канала Dev Q&A. В этот раз собрались обсудить одну из самых спорных тем в российском IT — low-code платформы. Тема настолько горячая, что удалось собрать представителей ведущих российских low-code платформ и практикующих разработчиков: Валерия Самарского (Comindware), Константина Леладзе (Proscom), Бориса Соколова (ex-UDP Auto), Александра Шантаровича (Agizo) и меня от «Диасофта».

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

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

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

Кому интересна полная версия — она доступна в записи на канале. Если есть вопросы или хотите поделиться своим опытом (особенно негативным) — пишите в комментариях или заходите в Dev Q&A.

Дальше — от третьего лица собрал самые интересные моменты дискуссии, включая свои реплики как участника.

«Low-code курильщика» против low-code здорового человека

Рынок low-code платформ переживает период турбулентности. С одной стороны, технология обещает революцию в скорости разработки, с другой — многие разработчики сталкиваются с серьёзными ограничениями и разочарованиями. Проблема заключается в том, что под одним термином скрываются принципиально разные подходы к автоматизации разработки.

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

«Low-code бывает двух типов. Low-code курильщика и нормальный low-code. Естественно, все можно испортить. Большое количество людей на этом обожглось — что-то попробовали, и все прошло не так», — объясняет специалист.

Основная проблема устаревших low-code платформ кроется в архитектурных ограничениях. Закрытые системы прошлого поколения создают критические узкие места в производительности и безопасности, что делает их непригодными для серьёзных корпоративных задач.

«Может быть совершенно закрытый low-code, когда платформа что-то создает внутри себя, и кардинально портятся важнейшие потребительские характеристики. Нет нормальной производительности, нет нормальной информационной безопасности, и вообще сложно что-то создать. Что бы ты ни собирал, все равно получаются «Жигули», — отмечает Александр Сахаров.

Однако важно понимать, что low-code — это прежде всего методология, а не конкретная технология. Такой подход позволяет более гибко подходить к выбору инструментов для решения бизнес-задач.

Константин Леладзе, CTO продукта Violet в Proscom, рассматривает low-code как универсальный метод описания логики: «Low-code — это скорее не про конкретную технологию, а про метод устройства и описания бизнес-логики любого предприятия. Low-code — это универсальное решение, которое может применяться во множестве сфер и отраслей».

Современные low-code платформы кардинально отличаются от предшественников открытостью кода и совместимостью с другими технологиями. Это позволяет избежать vendor lock-in и интегрировать решения с существующей IT-инфраструктурой компании.

Александр Сахаров подчёркивает преимущества платформ нового поколения: «Новейшие платформы уже гораздо более гибкие, они полностью открытые, позволяют избавиться практически полностью от вендор-лока. Код, который создается, полностью открыт, и это позволяет быть совместимым с искусственным интеллектом, создавать гибридные решения».

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

«Low-code позволяет работать интерактивно и детерминированно с набором правил, ограничив логику исполнения процесса. Это позволяет описывать отказоустойчивую и надежную инфраструктуру исполнения бизнес-процессов», — поясняет Константин Леладзе.

Специалисты подчёркивают, что low-code не претендует на универсальность и имеет четкие границы применимости. Разумный подход заключается в использовании технологии там, где она действительно эффективна.

Александр Шантарович, руководитель отдела бизнес-анализа Agizo, объясняет философию разумного применения: «Low-code скорее заменяет вещи, которые может заменить. Он никогда не полезет в транзакции, не полезет в шифрование информации. Он будет занимать ту нишу, которую заслуживает».

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

«Наша low-code платформа полностью открыта. Туда можно подключать все возможные виды искусственного интеллекта для автогенерации юнит-тестов, код-ревью, генерации и проверки самого кода», — добавляет Александр Сахаров, топ-менеджер «Диасофт».

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

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

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

Валерий Самарский из Comindware убеждён в жизнеспособности направления: «Low-code скорее жив, чем мертв, и не пока, а будет жить всегда. Очень много задач снимаются, если используешь low-code платформу. Сейчас большой всплеск интереса к ИИ, и его можно интегрировать — он только будет помогать».

ИИ vs low-code: конкуренция или синергия?

Развитие генеративного искусственного интеллекта поставило под вопрос будущее многих технологий автоматизации разработки. Если машина может написать код по текстовому описанию, зачем нужны визуальные конструкторы и low-code платформы? Этот вопрос волнует как разработчиков, так и бизнес-аналитиков, которые только начали осваивать новые инструменты.

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

Константин Леладзе из Proscom убеждён, что обе технологии развиваются параллельно: «На текущий момент рынок ИИ и low-code развиваются рука об руку, и нельзя сказать, что они друг с другом конкурируют. Технологии интегрируются в low-code, и low-code выступает оберткой, надстройкой, которая позволяет в удобном визуальном интерфейсе выстраивать бизнес-логику и бизнес-процессы организации».

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

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

Современные low-code платформы становятся своеобразными оркестраторами для различных ИИ-сервисов. Это позволяет использовать преимущества машинного обучения, сохраняя контроль над критически важной бизнес-логикой.

Александр Сахаров опять же подчёркивает возможности гибридного подхода: «Например, наша платформа позволяет подключать все возможные виды искусственного интеллекта для автогенерации юнит-тестов, автотестов, код-ревью самого кода, генерации, проверки. Более того, использовать механизмы не только с кодом связанные, но и для работы аналитиков — схемы, бизнес-процессы рисовать тоже с помощью ИИ».

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

Борис Соколов формулирует принципиальную позицию: «Low-code, как и ИИ — это инструмент, который дополняет разработчика и усиливает функции и решения компании. Это абсолютно не враг или монстр, который пришел кого-то заменить».

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

CTO продукта Violet ссылается на исследования отрасли: «Grandview Research прогнозирует, что к 2030 году рынок low-code вырастет с 6,78 миллиарда в 2022 году до 35,5 миллиарда долларов. Я не вижу в обозримом будущем падения рынка low-code или его сокращения».

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

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

Вендор-лок и зависимость: главные страхи бизнеса

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

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

Борис Соколов из ex-UDP Auto озвучивает ключевые опасения: «Что вы будете делать, если завтра ваш вендор закроется или поднимет цены втрое? Что будете делать с бизнес-критичными приложениями на его платформе? Возникает вопрос, как закрыть риск того, что завтра цены увеличат в два раза».

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

Борис Соколов отмечает рыночные ограничения: «У нас может складываться ситуация, когда поставщик low-code платформы один, и выбора особо нет. Клиент пользуется платформой, а потом понимает, что для перехода с Windows на Linux нужно потратить миллион долларов по всей корпорации».

Однако представители современных low-code платформ утверждают, что проблема vendor lock-in решена архитектурно. Новое поколение решений генерирует открытый код, который может функционировать независимо от исходной платформы.

Александр Сахаров объясняет принципиальное отличие: «Мы называемся low-code потому что генерируем код. Этот код полностью открыт и запускается в контейнере на Linux. Соответственно, если мы вдруг подняли цены, вы без нас взяли исходники и спокойно работаете — максимально открытая история».

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

Опытные заказчики подтверждают, что vendor lock-in — не самая критичная проблема корпоративной разработки. Гораздо серьезнее риски, связанные с потерей ключевых сотрудников и невозможностью поддерживать унаследованный код.

Александр Сахаров делится опытом работы на стороне заказчика: «Двадцать лет работал на стороне заказчика, и для меня самый страшный сон — это не подъем цены со стороны поставщика платформы. Я как-то этот вопрос решу, устрою конкурс, я умею с поставщиками разговаривать. А самый страшный сон — это когда мои программисты ушли работать в Сбербанк, или пусть даже тридцать процентов, но самых знающих».

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

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

Итоговый вывод экспертов показывает изменение приоритетов в корпоративных рисках. Vendor lock-in в современных low-code платформах минимизирован техническими решениями, в то время как альтернативные риски кастомной разработки — потеря ключевых сотрудников и невозможность поддержки legacy-систем — остаются критически важными для бизнеса до сих пор.

Почему программисты сопротивляются low-code

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

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

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

Страх замещения становится еще одним фактором сопротивления. Когда бизнес принимает решение внедрить low-code платформу, разработчики воспринимают это как угрозу своей профессиональной востребованности.

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

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

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

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

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

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

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

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

Валерий Самарский из Comindware поясняет новую модель работы: «У инженеров должны появиться навыки аналитиков или у аналитиков навыки инженеров по проектированию информационных систем, баз данных. Без этого большие решения не будут нормально работать. Наша платформа дает аналитику возможность построить модель данных, но если архитектор по данным не приложит знания, то мы получим нежизнеспособную модель».

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

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

Будущее low-code: реальность против ожиданий

Дискуссия экспертов еще раз показала, что low-code технологии находятся на переломном этапе развития. Старые проблемы — vendor lock-in, ограниченность функционала, закрытость кода — решаются новым поколением платформ. Но остаются человеческие факторы: сопротивление разработчиков, неготовность бизнеса правильно выстраивать процессы, завышенные ожидания от автоматизации.

Ключевой вывод экспертов: low-code — это не замена традиционной разработки, а её естественная эволюция. Технология решает определённый класс задач и имеет четкие границы применимости.

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

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

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