Привет, Хабр!
«Давайте все будем на ассемблере писать. Зачем мы пользуемся фреймворками?» — эта фраза из недавней дискуссии о low-code платформах прозвучала как манифест. И она заставила задуматься: где граница между разумным использованием абстракций и откровенным vendor lock-in?
Коллеги устроили жёсткий разбор low-code платформ — без маркетингового глянца и дипломатии. В дискуссии участвовали практикующие разработчики и представители вендоров: Сергей Жучков (создатель школы программирования ProgKids), Николай Алёшин (Golang developer, ШтрафовНет.ру), Павел Сандовин (ведущий системный аналитик, Outlines Tech), Сергей Лозовской (Head of DevOps), Зураб Белый (руководитель направления Java-разработки в компании «Рексофт») и я, Александр Сахаров, директор по работе с партнёрами «Диасофт».
Спойлер: никакой «серебряной пули» мы не нашли. Зато выяснилось, что low-code платформы прошлого и нового поколения — это принципиально разные вещи. И что конфликт между разработчиками и визуальным программированием — это на самом деле спор о том, как писать код в 2025 году, когда есть и мощные LLM, и микросервисная архитектура из сотен сервисов.
Ниже — ключевые аргументы обеих сторон. Без розовых очков, только то, о чём действительно спорят техлиды и системные архитекторы. Зураб Белый в конце сказал: «Все неправы и все правы одновременно» — и, пожалуй, это лучшее резюме для тех, кто не захочет читать дальше.
Главные претензии — от vendor lock-in до «здоровенного полотна»
Многие разработчики считают, что зависимость от вендора — главная опасность low-code платформ. И речь не о теоретических рисках, а о вполне конкретной проблеме: ко��да бизнес-логика описывается на специфичном языке платформы, компания теряет возможность легко мигрировать или заменить решение. Особенно критично это для микросервисной архитектуры, где каждый сервис должен быть независим и заменяем.
Николай Алёшин, Golang developer из ШтрафовНет.ру, сформулировал проблему так: «Любое решение, которое выносится вне компании — это большая зависимость от вендора. Чем больше интеграция происходит с такими платформами, тем больше ресурсов будет завязано: домены, код, процессы масштабирования».
Для сравнения эксперт привёл пример облачных решений. Даже к AWS, где существует огромная экосистема и масса сертифицированных специалистов, крупные компании долго присматривались, прежде чем начать миграцию. «У low-code платформ не будет тысяч компаний-пользователей и большого рынка специалистов, как у облачных провайдеров», — отметил Алёшин.
Визуальная сложность: когда упрощение превращается в проблему
Но vendor lock-in — не единственная претензия. Вторая болевая точка возникает именно там, где low-code обещает преимущество — в визуализации логики. На простых примерах это работает отлично: соединил несколько блоков, настроил базовую логику. Проблемы начинаются, когда бизнес-процесс включает десятки условий, вложенные циклы, обработку исключений и интеграции с внешними системами.
Сергей Жучков, создатель и генеральный директор школы программирования ProgKids, описал эту ситуацию на основе реального опыта: «Когда строишь сложный бизнес-процесс с использованием low-code, получается здоровенное полотно из соединённых блоков. Связи становятся настолько запутанными, вложенные структуры настолько многоуровневыми, что охватить это взглядом уже невозможно».
По мнению эксперта, на определённом уровне сложности структурированное текстовое описание логики оказывается понятнее визуальных схем. «Гораздо проще написать спецификацию: получи данные из такого-то поля базы, проверь диапазон значений, прими решение на основе условий. По сути, это тот же человеческий язык, только без визуальной прослойки. Я формулирую требования — и на выходе получаю готовый код, который решает задачу», — объяснил Жучков.
Кадровая проблема: замкнутый круг специализации
Усугубляет ситуацию кадровый вопрос. Low-code платформы обещают решить проблему дефицита разработчиков, но на практике создают новую — дефицит специалистов по самим платформам. Получается замкнутый круг: чтобы платформа стала популярной, нужны специалисты, но специалисты не идут в нишевые технологии без массового спроса.
Николай Алёшин указал на этот парадокс: «Где взять специалистов на такие платформы? Рынок показывает реальность — даже у крупных вендоров вроде Adobe, выпускавших визуальные конструкторы для создания сайтов, не получилось создать массовую базу специалистов. Если и без того сложно найти разработчиков на популярные языки, то для нишевых low-code решений эта проблема становится еще более актуальной».
Интеграция в реальность: когда платформа не вписывается в процессы
Все перечисленные проблемы могли бы показаться терпимыми, если бы не ещё одна — техническая интеграция. Современная разработка — это не только написание кода, но и целая экосистема: CI/CD-конвейеры, анализаторы безопасности, линтеры, автоматические тесты. Low-code платформы часто существуют параллельно этой экосистеме, создавая отдельный контур разработки со своими правилами.
Сергей Лозовской, Head of DevOps, обозначил техническую проблему: «Не все low-code платформы поддерживают отраслевые стандарты безопасности, и интегрировать их в общий контур разработки крайне сложно. Проблема в том, что нужно встроить специфичные правила платформы в единый конвейер с уже существующим кодом — подключить анализаторы, настроить code style, обеспечить совместимость инструментов».
Добавляет сложности необходимость работы со старым кодом. «Редко какая компания внедряет low-code с нуля. Обычно уже есть legacy-системы и множество доработок», — отметил эксперт.
Но самое неожиданное наблюдение Лозовского касается долгосрочного влияния на команду. Low-code платформы автоматизируют именно те задачи уровня junior и middle-разработчиков, на которых обычно растут специалисты. «Когда простые задачи уходят на платформу, мы лишаем разработчиков возможности набираться опыта. В итоге получается разрыв: есть джуны после университета и сеньоры, которые разбираются в сложных системах, — а середины нет. И кто будет разбираться с кодом, который сгенерировала платформа?» — предупредил специалист.
Получается, low-code платформы одновременно создают зависимость от вендора, усложняют визуальную логику, требуют редких специалистов и не вписываются в существующие процессы. Но может быть, все эти проблемы характерны только для решений предыдущего поколения?
Low-code против ChatGPT — нужен ли промежуточный слой в эпоху LLM?
Пока обсуждали проблемы low-code платформ, возник логичный вопрос: если визуальное программирование превращается в «здоровенное полотно», а зависимость от вендора пугает — может, проще использовать LLM? Современные языковые модели генерируют код по текстовому описанию, не требуют специфических навыков и не привязывают к платформе.
Сергей Жучков сформулировал этот аргумент прямо: «Зачем вообще нужен этот промежуточный слой? Разработка продукта строится по спецификации — процесс должен делать то-то, интегрироваться с тем-то. Это текстовое описание. Если у нас есть текстовое описание, мы можем отдать его в ИИ, который владеет кодовой базой. Будет создан новый код, который решит задачу. Если в тестовой среде проверили, что задача решена — всё, можно внедрять».
По мнению эксперта, LLM убирает необходимость в визуальной прослойке и делает разработку более гибкой.
Галлюцинации и несуществующие библиотеки
Но у этого подхода есть существенные проблемы, и первая из них — качество генерируемого кода. Сергей Лозовский, Head of DevOps, поделился опытом использования LLM для написания инфраструктурного кода: «Честно говоря, несколько раз пытался генерировать манифесты для Kubernetes, для Terraform, код на Go и Python — количество галлюцинаций начинает пугать. LLM ссылается на несуществующие библиотеки, на несуществующие подходы. Пробовал разные модели — и Claude, и GPT-4 — все равно галлюцинируют».
Эксперт отметил, что отладка сгенерированного кода может занять больше времени, чем написание с нуля: «Количество времени, которое ты потратишь на дебаг, может превысить то время, которое потратил бы самостоятельно на написание или развертывание».
Проблема долгосрочной поддержки
Еще серьезнее выглядит вопрос поддержки кода, созданного LLM. Зураб Белый, руководитель направления Java-разработки в компании «Рексофт», указал на исследования, которые показывают обратную сторону «эйфории от быстрой генерации»: «Последние исследования показывают, что LLM достаточно сильно удорожают разработку на больших дистанциях. Сначала эйфория — написали три строчки в промпт, получили много работающего кода. Но в итоге это превращается в сложно поддерживаемую систему, потому что ИИ действительно галлюцинирует, а код нужно тщательно ревьювить».
Эксперт обратил внимание на риски безопасности: «В этом ИИ-коде часто бывают бэкдоры, уязвимости, о которых опытные разработчики знают и могут их увидеть при ревью, а машина — нет. Она просто сгенерировала то, что увидела в обучающих данных».
По словам Белого, попытки решить эти проблемы приводят к необходимости подключать анализаторы, генерировать тесты к коду, тщательно его проверять. «В конечном итоге это превращается, если не в ту же самую low-code платформу, где ты мышкой двигаешь блоки, то во что-то очень похожее», — резюмировал специалист.
Контраргумент: структура против хаоса
Александр Сахаров, директор по работе с партнёрами «Диасофт», предлагает другой взгляд на проблему. По его мнению, LLM хороши для разовой генерации, но не решают задачу долгосрочной поддержки: «Было бы здорово, если бы нужно было просто что-то написать, сдать и уйти отдыхать. Но обычно мир устроен не так. Пока вы что-то писали, спецификация уже изменилась, у заказчика появилось столько новых требований, что вы будете каждую неделю перегенерировать код».
Эксперт привёл пример критичной инфраструктуры: «Представьте, что ваша система работает в Центральном банке. После падения вас просят восстановить работу за два часа. Вы что, будете спрашивать у ChatGPT: "Слушай, что-то у тебя неправильно работает, может, найдёшь проблему?"»
По словам Сахарова, преимущество структурированного подхода — в наблюдаемости и контролируемости: «Когда у вас есть структура, вы можете правильным образом настроить мониторинг. Весь код оснащён юнит-тестами, системами логирования, контроля здоровья сервисов. Когда возникает ошибка, вы можете посмотреть архитектуру, увидеть, где она произошла, что из этого следует».
Ещё одна проблема LLM, по мнению эксперта, — неполнота требований: «Если человек написал функциональные требования и забыл про информационную безопасность, забыл про десяток других вещей — вы это и не получите в коде. А потом будет сложно всё это сопровождать».
Так что, получается, LLM-генерация — это не волшебное решение, которое отменяет необходимость в платформах. У неё свои ограничения: галлюцинации, проблемы с безопасностью, сложность долгосрочной поддержки. Но решают ли эти проблемы low-code платформы нового поколения?
Эволюция платформ — что изменилось в новом поколении
Претензии к low-code платформам не появились из ниоткуда — за ними стоит реальный опыт команд, работавших с решениями первого поколения. Vendor lock-in, проприетарные форматы данных, невозможность интеграции с CI/CD, дефицит специалистов — все эти проблемы действительно существовали и были болевыми точками внедрений.
Но low-code платформы тоже эволюционировали. За последние годы появились решения, которые пытаются учесть критику и предложить другую архитектуру — открытую, интегрируемую, не создающую жёсткую зависимость от вендора.
Александр Сахаров, директор по работе с партнёрами «Диасофт», описал при��ципиальное отличие подходов: «Low-code платформы прошлого поколения и low-code платформы нового поколения — это кардинально отличающиеся истории. Раньше были большие проблемы, но сегодня появляются платформы, которые несут в себе решение тех проблем, с которыми сталкивались предыдущие поколения».
Открытый код вместо vendor lock-in
Главное изменение коснулось архитектуры хранения и работы с кодом. Если раньше бизнес-логика была заперта внутри платформы в проприетарных форматах, то новые решения генерируют обычный код в стандартных языках программирования.
Эксперт объяснил, как это работает: «Экосистема позволяет рисовать диаграммы, а результатом её работы является полностью открытый и независимый код, который лежит в Git. Программисты, которые дальше работают с ним, могут его сколько угодно усложнять и дорабатывать. Код запускается в операционной системе, в контейнерах. И никак от вендора не зависит — хотите используйте визуальные инструменты, хотите не используйте, это не влияет на runtime».
Такой подход решает проблему миграции: компания в любой момент может перестать использовать визуальные инструменты платформы и продолжить работу с обычным кодом в Git.
Гибридный подход: визуализация + ручной код
Ещё одно изменение — признание того, что визуальных инструментов недостаточно для всех задач. Платформы нового поколения изначально проектируются как гибридные решения, где визуальная часть дополняется возможностью писать код вручную.
Александр Сахаров объяснил эту концепцию: «Код полностью открыт и специально сделан открытым, чтобы в него добавляли то, что нельзя реализовать визуально. Интеграцию с внешними системами визуально не опишешь — её нужно программировать. Сложную бизнес-логику кубиками не выразишь — её нужно кодить».
По словам эксперта, платформа создаёт базовую структуру приложения — микросервисы с настроенной инфраструктурой, API, системами логирования и мониторинга. «Платформа генерирует базовый каркас приложения, а всю специфичную логику, интеграции и сложные алгоритмы вы дописываете сами — руками программистов, с помощью LLM или любыми другими способами», — пояснил Сахаров.
Такая архитектура позволяет использовать визуальные инструменты для типовых задач и инфраструктурных вещей, а уникальную бизнес-логику реализовывать традиционным способом.
Интеграция с CI/CD и инструментами разработки
Третье важное изменение касается интеграции в экосистему разработки. Если раньше low-code платформы существовали отдельно от CI/CD-конвейеров, анализаторов кода и систем тестирования, то новые решения включают эту интеграцию из коробки.
«Внутри экосистемы полностью реализован современный CI/CD на базе open source решений. И он полностью открыт. Если вы используете любые анализаторы кода или внешние инструменты для эффективного программирования — они туда элементарно подключаются. Нужны LLM для генерации unit-тестов? Подключайте. Нужны LLM для генерации бизнес-процессов или кода? Подключайте», — рассказал эксперт.
Получается комбинированная среда, где визуальные инструменты платформы работают вместе с привычными DevOps-практиками, а не вместо них.
Стандартизация как главная ценность
Но если код открыт и можно писать вручную, зачем вообще нужна платформа? Ответ лежит в области стандартизации и автоматизации рутинных задач, которые не связаны с бизнес-логикой.
Александр Сахаров привёл аналогию с фреймворками: «Давайте все будем на ассемблере писать. Зачем мы пользуемся Spring, Angular? За что вам платят деньги? Нам платят за реализацию бизнес-задач. Если я каждый раз буду писать модуль авторизации, систему управления ролями, систему логирования, горизонтальное масштабирование — я, честно говоря, со скуки умру. Мне как программисту хочется делать что-то новое, а не старое».
Особенно критична стандартизация при работе больших команд. «Когда одновременно работают две сотни команд разработки, добиться, чтобы они одинаково правильно решали вопросы информационной безопасности, горизонтального масштабирования, стандартов качества по описанию API, юнит-тестирования, логирования — это практически невозможно без инструмента автоматизации», — объяснил эксперт.
По его словам, суть современной low-code платформы изменилась: «Это не no-code платформа. Это инструментарий, который позволяет программистам и аналитикам 90% рабочего времени тратить на создание нового прикладного решения. И не тратить время на рутинные процедуры, которые каждый раз нужно перепроверять — иначе софт не пройдёт нагрузочное тестирование, не выдержит pentest».
Микросервисная архитектура «из коробки»
И ещё один аргумент в пользу нового платформенного подхода — автоматическая поддержка микросервисной архитектуры. При разработке микросервисов вручную каждый сервис нужно оснастить однотипной инфраструктурой.
«Если вы занимаетесь разработкой в микросервисной архитектуре, вам нужно помнить про информационную безопасность, про горизонтальное масштабирование, про единые подходы к интерфейсам, про единые подходы к программным API, обеспечивать обратную совместимость при внесении изменений», — перечислил Сахаров типовые задачи.
Платформа автоматизирует эту инфраструктурную работу, позволяя разработчикам сосредоточиться на бизнес-логике конкретного сервиса.
В результате, получается, между платформами разных поколений действительно большая разница: открытый код против проприетарных форматов, интеграция с CI/CD против изоляции, гибридный подход против чистого визуального программирования. Но снимают ли эти изменения все претензии?
Компромисс — не бывает плохих технологий, бывает неправильный контекст
Споры о преимуществах и недостатках low-code часто упускают главное: любая технология эффективна только в правильном контексте применения. Вопрос не в том, хороша или плоха микросервисная платформа визуальной разработки, а в том, для каких задач она подходит, а для каких — нет.
Зураб Белый, руководитель направления Java-разработки в компании «Рексофт», сформулировал это так: «На самом деле не бывает технологий плохих или хороших, и решений плохих или хороших. Каждое из них нужно оценивать именно в том контексте, в котором оно будет использоваться. Обычно у нас технология идеальная, а люди, которые её используют, не идеальные».
Зураб Белый обозначил чёткую границу применимости: «Если говорим про уникальный проект, который раньше никто не делал, малопредсказуемый, или это интеграция с совсем новыми системами — в этом случае low-code платформу использовать сложно. Другое дело — типовая разработка».
Эксперт объяснил, что большинство корпоративных проектов состоят из повторяющихся компонентов: «Практически все проекты повторяют то, что уже было реализовано ранее. Портал, на который будут приходить пользователи — функционал понятен и предсказуем. Внутренняя система документооборота — это уже сотни раз делали. Здесь вопросов к использованию low-code платформы нет. Мы понимаем, что это будет, можем предсказать, как система будет работать. В таких случаях платформа просто убирает рутину».
П�� словам Белого, структура крупных проектов демонстрирует эту типовость: «Возьмём любой большой проект — там есть модуль нормативно-справочной информации, модуль документооборота, модуль внешних интеграций, модуль управления доступами. Функционал одинаковый, реализация похожая — но разработчики переписывают это из проекта в проект. Заново анализ, заново тестирование. Если можно написать один раз, тщательно проверить и затем использовать в нужных проектах — это экономит ресурсы».
Уникальные проекты: где low-code становится проблемой
Но есть и обратная сторона. Зураб Белый предупреждает об ограничениях платформенного подхода: «Всегда есть проекты, уникальные с разных точек зрения — экстремальные требования к безопасности, специфичная нагрузка, нестандартный функционал. Они не вписываются в рамки платформы. В таких случаях использовать low-code вряд ли будет оптимально — слишком много придётся кастомизировать и переделывать».
Эксперт сформулировал принцип выбора: «Если понимаем, что проект действительно уникальный — не стоит использовать платформу. Пытаться решить нестандартную задачу стандартным инструментом — это как открывать дверь отвёрткой вместо ключа. Технически возможно, но зачем?»
Кроме того, даже для типовых проектов критически важна возможность доработки платформенного решения под специфические требования. Зураб Белый сформулировал это условие: «Ключевое требование к платформе — лёгкая кастомизация. Недостаточно просто визуально собрать приложение из блоков. Должна быть возможность дописать специфичную логику под конкретные требования бизнеса».
Эксперт описал правильную пропорцию: «Обычно 80% проекта — это типовой функционал, который платформа генерирует автоматически. Оставшиеся 20%, которыми ваш проект отличается от других, пишутся вручную программистами. И вот здесь возникает экономия: да, в некоторых местах код может быть чуть менее оптимален, зато вы сэкономили колоссальные ресурсы на тестировании, написании типовых модулей, подготовке требований».
Есть и человеческий фактор, который нельзя игнорировать при выборе подхода. Зураб Белый напомнил о мотивации команд: «Разработчики любят писать код. Это не просто работа, это то, что им интересно — копаться в сложных задачах, придумывать элегантные решения. Если начать всех переучивать только на работу с визуальными платформами, потеряем сильных инженеров. Высококвалифицированные специалисты не хотят просто таскать блоки мышкой».
По мнению эксперта, это создаёт естественное ограничение на применение low-code: «Полностью перейти на платформы не получится. Всегда будет запрос что-то кастомизовать под специфичные требования, всегда будут задачи, где нужна настоящая программистская работа, а не визуальная сборка».
Эволюция продолжается: от FrontPage до платформ нового поколения
Павел Сандовин, ведущий системный аналитик Outlines Tech, предлагает рассматрива вопрос low-code еще и в исторической перспективе: «Желание писать меньше кода существует с��олько же, сколько существует программирование. Было множество подходов и инструментов — какие-то исчезли, какие-то остались в истории. Это естественный процесс эволюции индустрии».
Эксперт привёл примеры из прошлого: «В конце 90-х Microsoft выпустил FrontPage — визуальный редактор, который автоматически генерировал HTML. Сначала был хайп: можно создавать сайты без знания кода! Но где сейчас FrontPage? Давно закрыт. А HTML как был, так и развивается. То же самое с CMS-системами нулевых — все ими пользовались для быстрого запуска порталов, потом необходимость отпала».
Но это не значит, что идея автоматизации умерла. Сандовин объяснил: «Реальность меняется — теперь нужно создавать сложные системы с множеством зависимостей. И снова те же типовые компоненты: авторизация, документооборот, интеграции. Зачем каждый раз писать заново, если можно использовать проверенные решения?»
Сергей Жучков, создатель школы программирования ProgKids, признал практическую ценность современных решений в российских реалиях: «В текущих условиях low-code платформы вроде той, что представляет «Диасофт» — это востребованный инструмент. Квалифицированные специалисты уезжают, найти хороших разработчиков всё сложнее, бюджеты компаний сокращаются. Для госкомпаний и крупных корпораций это работающее решение проблемы кадрового дефицита».
При этом эксперт продолжает скептически относиться к идее визуального программирования как универсального подхода. Хотя в условиях ограниченных ресурсов такие платформы и решают реальные бизнес-задачи.
Что в итоге?
Получается, мы вернулись к тому, с чего начинали: разница между low-code платформами прошлого и нового поколения — не маркетинговая уловка. История FrontPage и CMS показывает, что инструменты, которые пытаются полностью заменить программирование, отмирают. А инструменты, которые помогают программистам работать эффективнее — эволюционируют.
Low-code платформы имеют смысл для типовых проектов, где большая часть функционала стандартна, а уникальность — в деталях. Они неэффективны для уникальных решений с высокими требованиями к производительности или специфичной бизнес-логике. И критически важна возможность кастомизации: платформа должна генерировать открытый код, интегрироваться с CI/CD и позволять дописывать сложную логику вручную. Иначе экономия на старте превращается в технический долг на дистанции.
Ключевой вопрос не «хорош ли low-code», а «подходит ли конкретная платформа для конкретной задачи в конкретном контексте». И если платформа нового поколения действительно решает проблемы предыдущих — открытый код, интеграция с экосистемой, возможность доработки — то это уже совсем другой разговор. А как думаете вы?
