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

Главная тема пленарной дискуссии No-сode Conf 2026 была сформулирована почти провокационно: если искусственный интеллект уже умеет писать код и собирать приложения, зачем нам no-code?

Но разговор довольно быстро вышел за пределы соревнования двух подходов.

Модератором дискуссии выступила Евгения Весницкая, главный архитектор РИТМ, itSMF России. В обсуждении также приняли участие Арсен Благов, генеральный директор ИТ-экосистемы «Лукоморье», Александр Шепилов, директор направления обеспечения безопасности корпоративных информационных систем «Ростелекома», Александр Дмитриев, генеральный директор IVA Technologies, Всеволод Шадрин, председатель itSMF России, и Антон Зиновьев, руководитель службы проектной методологии и процессов ГИСТЕХ.

Участники обсуждали уже не столько вопрос «AI или No-сode», сколько то, как меняется сама конструкция разработки — от первой идеи и прототипа до архитектуры, безопасности, внедрения и эксплуатации.

И одна из самых точных формулировок дискуссии звучала примерно так: ИИ драматически снизил стоимость первой версии. Бутылочным горлышком становится проверка.

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

А значит, дефицит постепенно уходит из этой точки процесса и возникает в другом месте.

Первая версия становится почти расходным материалом

Несколько раз в ходе пленарной сессии ее участники возвращались к одному и тому же факту: ИИ позволяет резко сократить стоимость и время первого результата.

Как следствие, теперь не обязательно сразу строить большой продукт. Можно проверить гипотезу, получить прототип, посмотреть, получилось ли то, что задумывали, кому это нужно. И, если результат не нравится — переделать и попробовать ещё раз. Таким образом кардинально изменилось то, что раньше было критической проблемой- цена ошибки.

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

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

Что происходит на практике

В пленарной дискуссии это не осталось только теорией.

Представитель IVA рассказывал о собственном опыте использования AI в разработке и о платформенном подходе, который компания строит вокруг этого процесса. В разговоре фигурировал ИИ-инструментарий для разработки, в том числе IVA ADP и подход Harness, где задача состоит не просто в том, чтобы дать модели возможность генерировать код, а в том, чтобы встроить её работу в контролируемый процесс.

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

И возникает уже нормальный управленческий вопрос: как считать экономику ИИ-разработки целиком, а не только экономию на зарплатном фонде?

И здесь появляется No-сode

Если смотреть на No-сode исключительно как на способ сделать приложение без программиста, после появления генеративного ИИ, действительно, возникает резонный вопрос: зачем визуально собирать то, что можно попросить ИИ сгенерировать?

Но участники пленарной сессии предлагают смотреть на No-сode шире.

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

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

Именно поэтому участники дискуссии обращали внимание на важность связки: ИИ + No-сode + человек, в которой ИИ может отвечать за скорость создания, No-сode — за среду и управляемость, а человек — за постановку задачи, архитектурные решения и ответственность за результат.

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

Самое важное в этой связке — не скорость

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

Да, действительно, сейчас ИИ позволяет получить первую версию необходимого продукта за считаные часы. И, «генерируя» код, он параллельно генерит очень серьезные проблемы: что компаниям делать с десятками таких первых версий?

  • Как эти «продукты» попадают в архитектуру?
  • Какие из них можно допускать в эксплуатацию, а какие — ни в коем случае?
  • Как их (и какие из них) интегрировать с уже существующими системами?
  • Кто (и как), спустя время будет вносить изменения?
  • И, самое важное, кто отвечает, если решение работает не так, как ожидалось?

В этой ситуации у No-сode-платформ появляется новая роль — они становятся интересны как инструмент не просто что-то создать, а создать это что-то в определённой среде.

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

Безопасность тоже перемещается внутрь среды

Самый жёсткий блок вопросов пленарной сессии был посвящен теме безопасности: и это не только о традиционной проверке программного кода.

Появляются prompt injection, jailbreak, атаки через взаимодействие моделей, новые риски при использовании AI-агентов, необходимость отслеживать их действия и понимать, какие данные проходят через систему.

Отдельная проблема — огромный объём «логов» и следов работы таких систем: чем больше автоматизации, тем больше событий приходится контролировать.

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

И это ещё одна из причин, почему разговор о No-сode не сводится к вопросу «можно ли написать приложение без кода?». Когда безопасность встроена в саму платформу, она не появляется только после того, как ИИ уже что-то сгенерировал. Часть функций контроля начинает исполняться еще «до создания» решения.

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

Новые инструменты меняют не только разработчиков

На пленарной сессии уделили внимание и изменениям традиционных ролей специалистов, произошедшим благодаря появлению ИИ.

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

В этом есть важное отличие современных процессов от классической автоматизации. Раньше автоматизировалась отдельная операция. Теперь ИИ может участвовать сразу в нескольких этапах. Поэтому вопрос уже не только в том, сколько работы машина способна выполнить. Вопрос в том, кто и как задаёт направление этой работы.

А No-сode — это про кого?

И здесь становится понятнее, почему организаторам No-сode Conf было важно поставить рядом две темы — AI и No-сode.

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

Теперь этот же порог входа снижает ИИ. Но делает это иначе. Он не даёт человеку готовую среду, но позволяет ему сформулировать запрос и получить результат. И в этом и состоит принципиальная разница двух подходов.

Использование ИИ снижает стоимость создания продукта. Платформа позволяет сделать само производство более управляемым. Это разные свойства.

И потому вопрос «зачем нам No-сode, если есть ИИ?» в рамках этой пленарной дискуссии не получил ответа в виде одного инструмента-победителя.

Скорее наоборот: участники пришли к тому, что выбор зависит от задачи.

  • Для одной задачи достаточно ИИ.
  • Для другой важна No-сode-среда.
  • Для третьей нужен полноценный разработчик.
  • Для четвёртой — комбинация трёх составляющих.

Цена становится сложнее

Есть ещё один слой этой истории — экономика.

На пленарной сессии прозвучала мысль, что при оценке эффективности применения ИИ нельзя считать только стоимость зарплаты людей, которых он заменил.

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

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

А это уже меняет сам процесс принятия компаниями решения о том, что вообще стоит разрабатывать.

Поэтому, как будто сам вопрос «ИИ или No-сode?» становится «неправильным». Началом пленарной дискуссии было довольно понятное противопоставление: если ИИ умеет писать код, зачем нужен No-сode?

Но конкретные кейсы и цифры, которые прозвучали в разговоре, постепенно поставили вопрос, а есть ли это противопоставление.

Сокращение количества разработчиков — это не история о полном исчезновении людей из процесса.

Миллионы рублей на оплаты токенов плюс стоимость платформы — не история о бесплатной разработке.

600 млн рублей оценки затрат на построение безопасности — не история о том, что достаточно просто подключить AI.

И NoCode в этой конструкции — не старый инструмент, который ждёт, пока его окончательно вытеснит новая технология.

Раньше мы спрашивали: как сделать цифровое решение быстрее и дешевле? Теперь, когда первая версия действительно может появляться очень быстро, приходится спрашивать, в какой среде это решение должно появиться, как оно будет встроено в систему компании, кто будет им управлять и какую часть этой работы имеет смысл отдавать AI?

И вот здесь у NoCode появляется не ответ на ИИ, а собственная функция в новой конструкции разработки. Не потому, что ИИ недостаточно хорош.

А потому, что быстро создать решение и построить управляемый процесс его создания — всё-таки не одно и то же.

Источник:
Иллюстрация предоставлена пресс-службой компании