Привет, Хабр! Меня зовут Александр Сахаров, я отвечаю за партнерства в «Диасофт». Хочу разобрать с вами один сюжет, который рынок сейчас подает максимально противоречиво, — платформенную разработку.

Повод любопытный. Прямо сейчас идут два встречных сигнала. «Ведомости» в апреле написали, что интерес крупного бизнеса к low‑code за год упал почти вдвое: с 66% компаний в 2025 году до 34% в 2026-м. А свежие обзоры по integrated development environment говорят ровно обратное: внутренние платформы разработки внедряют все активнее. Так в какую сторону мы на самом деле движемся — и чего при этом боимся?

Поверьте, страхов до сих пор хватает: технический долг, который никто не хочет наследовать, вендор‑лок, спагетти‑код от нейросетей, вопрос «кто будет это поддерживать через три года». В «Диасофт» новая линейка продуктов построена на микросервисах по единым стандартам экосистемы Digital Q — полноценная AI driven экосистема разработки (IDE), так что часть этих болей мы для себя и наших клиентов уже закрыли. Но мне было интересно другое — как на те же страхи смотрит рынок. Ниже выжимка обсуждения: эволюция подходов, где low‑code реально полезен, немного про ИИ‑агентов и взгляд со стороны заказчика. Себя я позволил процитировать в рамках обсуждения, чтобы не выбиваться из контекста. 

Кому лень читать лонгрид — полная версия дискуссии лежит на Rutube. А спорить и задавать вопросы приходите в Telegram‑канал Департамент разработки, там собирается сообщество разработчиков.

Что именно хоронят

Директор по партнерствам Диасофт Александр Сахаров объясняет: «Ведомости писали про конкретные системы — то, что я называю low‑code платформами старого поколения. По сути это дикий монолит: внутри можно собрать простую форму, навесить на нее пару скриптов, и оно как‑то работает. Таким системам места действительно не осталось, и причины очевидны — вендор‑лок, монолитность, неспособность держать нагрузку, провал по информационной безопасности. Написано все это в лучшем случае году в 2015-м. Сегодняшние (читай „современные“) платформы и фреймворки живут в другой парадигме: полностью открытый код, никакого вендор‑лока, микросервисная архитектура, горизонтальная масштабируемость, подтвержденная тестами, визуальное проектирование, связанное с кодом напрямую, полноценный DevOps и информационная безопасность. По сути это сильно прокачанная IDE, внутри которой собран весь жизненный цикл производства ПО — от проектирования до quality gates, тестов и выкатки. И туда же встроен искусственный интеллект. У аналитика вместо клавиатуры теперь микрофон: он голосом проговаривает, что нужно изменить, и не рисует экранные формы руками. Многие медиа просто не понимают, о чем пишут, и ставят кликбейтный заголовок. Тренд же ровно обратный: старый low‑code не нужен никому, а новые low code фреймворки набирают обороты».

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

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

Каждому инструменту своя задача

Ян Азизов, генеральный директор АО ВИРТУАЛИТЕХ считает: «Бизнес смотрит на платформы совершенно иначе, чем разработчики, и вся эта терминология для него пустой звук. У бизнеса есть процесс, в этом процессе есть узкое место, и закрыть его нужно здесь и сейчас. Часть таких задач платформы научились решать очень давно. Бухгалтерию, например, одна известная компания закрывает уже тридцать лет, и мы все видели, как ее продукт рос и масштабировался. Excel — история того же рода: им пользовалась моя мама, пользуется мой ребенок, это инструмент, переживший поколения. В него сейчас встраивают искусственный интеллект, но работать с ним по‑прежнему. Платформа, которая закрывает узкую задачу, попадает в свою нишу настолько точно, что заменить ее в этой нише попросту нечем».

Алексей Какунин, CEO EmDev: «Все упирается в задачу. No‑code и low‑code хороши для типовых решений: платформа закрывает 80 процентов нужного функционала, оставшиеся 20 мы доконфигурируем. Перевернем пропорцию — и подход ломается. Когда на платформу приходится 20%, а остальные 80 дописываются на low‑code, мы пишем код, упираясь в ограничения, которые сама же платформа в этот low‑code и заложила. Такую задачу правильнее решать на фреймворке, точечно. ИИ, фреймворк, RAD‑система — инструменты момента: они дают результат здесь и сейчас. Сила low‑code и no‑code в другом — в гибкости на дистанции. Сегодня ты получил результат, а завтра нужно то же самое, но с перламутровыми пуговицами. И выбор такой: либо снова идти к ИИ, который уже забыл, что делал, либо к разработчику, который писал это на фреймворке и давно уволился, либо взять low‑code и фактически перешить пуговицы самому. Поэтому никто не идет к разработчику с просьбой написать бухгалтерию вместо 1С — проще донастроить то, что 1С уже умеет. Под каждый сегмент заказчиков нужен свой инструмент: разработчику один, бизнесу другой. А шумиху в прессе породили два фактора разом. Первый — смена парадигм: негибкий low‑code старого образца уходит. Второй — экономика: крупный энтерпрайз затаскивает разработку внутрь, потому что хочет ее контролировать».

Черный ящик возвращается под новым именем

Егор Дьяченко, ведущий разработчик ТИМ ФОРС: «Тренд все заметнее смещается в сторону искусственного интеллекта: бизнес‑процессы один за другим начинают закрывать через него. У нас в компании это видно по тому, как мы отказываемся от вендорных решений в пользу собственной разработки — с ИИ ее можно ускорить и заточить ровно под свои нужды. Это одна сторона. Другая — лавина SaaS‑платформ, которые точно так же продвигаются через ИИ. Их становится очень много, но что у них внутри, неизвестно. Это и есть тот самый черный ящик. Сервисов быстрой разработки масса: загружаешь скрин дизайна, и ИИ сам пишет по нему приложение. Разработчик понимает, что за этим стоит. Но эту же историю все активнее тянут на себя бизнес‑аналитики. Cursor, Claude и другие агенты позволяют собрать приложение, вообще не погружаясь в код, — и тенденция эта недобрая, потому что такие приложения выходят ненадежными. Вендор‑лока здесь уже нет, решение сделано точно под ваш бизнес. Но контроль потерян: систему собирал не разработчик, который в ней разбирается, а аналитик, которому важно одно — закрыть бизнес‑потребность».

Алексей Какунин напоминает: «Чтобы стало понятно, чем оборачивается потерянный контроль на дистанции, стоит вспомнить историю тридцатилетней давности. Начало девяностых, Петербург. Сеть, торгующая автоэлектроникой. Стандартов учета еще нет, бизнес подняли вчерашние студенты — и они попросили однокурсника: напиши нам бухгалтерию. Он написал. Ровно как ИИ сегодня: сел, написал, потом дописал, потом еще раз дописал, потому что на длинную дистанцию изначально никто не закладывался. Закончилось это тем, что к концу девяностых тот программист ездил с охраной — бизнес осознал, что, случись с ним что‑нибудь, все встанет. А когда компания наконец перешла на нормальную платформу, все перекрестились и выдохнули: появился хоть какой‑то фундамент, до этого все держалось на совершенно непредсказуемой истории. Так что вопрос с контролем кода никуда не делся. ИИ или разработчик напишет решение — оно действительно закроет разовую задачу. Но думать надо про длинную дистанцию и про то, кто именно этот код контролирует: ИИ, который его написал, ушедший разработчик или все‑таки вы как бизнес».

Александр Ахмеров, ведущий архитектор BPMsoft: «Про длинную дистанцию забывают почти все. Бизнесу реализовали его потребность — и на этом успокоились. Но современные средства практически никогда, за редким исключением, не дают проекту архитектурную подоснову. Их можно назвать Форрестом Гампом: задачу, которую перед ними поставили, они выполняют, а вот проектировать на будущее не умеют. Момент критический, и про него все время забывают. На длинной дистанции решения, собранные такими средствами, дают сильный отрицательный эффект».

ИИ не умеет останавливаться

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

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

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

Вывод из этого один, и он не про запрет на ИИ. Он про то, что инструмент такой силы нельзя оставлять без каркаса.

Каркас, а не костыль

Алексей Какунин: «Первично всегда одно — грамотно описанный бизнес‑процесс и документация. Если у нас есть толково составленная BPMN‑диаграмма или внятно описанный API, то все дальнейшее — уже вопрос инструмента. Нужно решить точечную задачу — берем фреймворк и разработчиков, превращаем процесс и API в работающую систему. Нужна гибкость и модифицируемость — тот же самый процесс загружаем в BPM‑движок и оживляем его без труда разработчика, получая функционал no‑code. Поэтому я по‑прежнему развожу инструменты: при наличии бизнес‑процессов и документации мы либо применяем их во фреймворках разработки как инструменте для разработчика, либо в классических no‑code и low‑code системах как инструменте для бизнеса. Что до искусственного интеллекта — в энтерпрайзе это пока ассистент команды разработки, а не ее замена. Весь вопрос в том, кто именно держит инструмент в руках».

Александр Сахаров: «То, о чем здесь говорят, и есть главная проблема: кто‑то что‑то написал, потом ушел — и появился черный ящик в виде кода, который непонятно как править. Неважно, ИИ это, талантливый разработчик, бесталанный или сотня разработчиков, которые поработали и ушли в банк на большую зарплату. Чтобы об этом не думать, нужны архитектурные артефакты: ER‑диаграмма сервисов и объектов, BPM‑диаграмма процессов, экранные формы, интеграционные потоки, потоки данных. И нужен процесс: когда кто‑то где‑то пишет код, этот код попадает в DevOps‑конвейер, а там контроль архитектурных стандартов, правил, уязвимостей. Если все это соблюдается, любого архитектора можно разбудить среди ночи — и он знает, что у него есть актуальная схема, которая реально работает на рантайме, и ни один программист не поправил ее руками в обход. А если поправил, то лишь там, где это разрешено, в виде конкретного скрипта в известном месте. Вот к такому фреймворку очень удобно подключать ИИ‑агентов: каждую проверку, каждый этап ведет отдельный агент. Получается мультиагентная схема. Первый агент берет на вход бизнес‑требование и раскладывает его по артефактам. В каждом артефакте происходят изменения, затем все склеивается и проверяется на консистенцию. Нашлись нарушения — их выявляет агент, отвечающий за стандарты. Неправильно использована библиотека — это ловит агент, который следит за библиотеками. Дальше один агент формирует тестовые сценарии, другой их прогоняет, третий проверяет на уязвимости. На выходе — полноценный сквозной процесс производства ПО».

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

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

Кто подтвердит, что решение взрослое?

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

Заказчик смотрит на ту же картину под своим углом.

Андрей Филиппов: «Осенью выходила известная статья MIT: только пять процентов компаний полноценно используют ИИ в своей работе. Дискуссия о платформах обычно идет с позиции разработчика и вендора — а стоит посмотреть глазами заказчика, среднего и крупного бизнеса. Энтерпрайз — это почти всегда мимо SaaS, все внутри, все on‑premise. Развертывание и запуск крупных языковых моделей у себя — отдельная большая история, на которую в наших условиях, в том числе из‑за дефицита инфраструктуры, бизнес сейчас точно не пойдет. Так что с позиции разработки платформ и продуктов ИИ — это вектор и импульс. А с позиции энтерпрайза и среднего бизнеса все равно все останется в границах тех платформ и продуктов, которые им предлагают».

Александр Ахмеров: «Крупный бизнес тоже способен реализовывать большие и сложные сценарии. Но важно разграничивать разработку и конфигурирование платформы. Платформа — очень хороший инструмент для прототипирования и последующей реализации процесса, но не для разработки. При этом крупные компании могут спокойно ее использовать: есть описание, ER‑диаграммы, ADR‑записи — на этом можно обучить систему и поставить конфигурирование платформы на уровень агентов. Думаю, со временем крупные компании в эту сторону и пойдут».

Трактор вместо лопаты

Александр Сахаров резюмирует: «Тренд виден, и спорить с ним можно сколько угодно — он от этого никуда не денется. Я не хочу тратить время своих людей на то, чтобы они руками рисовали экранные формы, руками писали уже расписанную документацию, руками собирали и прогоняли тестовые сценарии. Тем более не хочу, чтобы кто‑то руками выписывал сложный JavaScript‑код, который сегодня писать руками просто незачем. Все эти задачи можно делать автоматически — отрицать это бессмысленно. Другой вопрос — как именно. Если сесть на трактор, завязать себе глаза и поехать наугад, то можно передавить много людей, и по деревне пойдет слух, что трактор — это зло. А если за тот же трактор сядет подготовленный механик, он вспашет десять гектаров за пару дней — столько, что людям с лопатами потребовался бы год. Когда ИИ используют как черный ящик, не умея им пользоваться, получается автоматизированный хаос и куча проблем. Все, о чем предупреждают коллеги, абсолютно справедливо, так и есть. Но если за дело берется квалифицированный человек, выстраивает правильный процесс и опирается на знания, которые индустрия копила сорок пять лет, — если он создает фреймворк, внутри которого агенты занимаются ровно тем, чем должны, — происходит та самая четвертая промышленная революция. Люди делают свою работу, агенты делают ту, что руками выполнялась бы куда дольше. Но именно люди контролируют последовательность действий и сам производственный процесс — следят, чтобы каждый этап шел с нужным качеством, а при сбое агент откатывал бы разработку и заходил на этап заново».

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

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