ИИ заставит программистов читать написанное?

Нехватка ИТ-специалистов, разработчиков программного обеспечения, в частности, в сфере инженерного ПО, заставляет искать новые подходы к решению проблемы. Согласно некоторым оценкам, 100 тыс. выпускников профильных направлений, по которым ведется подготовка в российских вузах, – капля в море ежегодно растущих кадровых потребностей различных индустрий. В какой мере технологии Low Code/No Code/AI могут способствовать решению проблемы, насколько продуктивным может быть их применение в сегменте разработки инженерного ПО? Ответы на эти вопросы искали представители компаний «Аскон», C3D Labs, Datadvance и «Цифрум» в ходе дискуссии, которая состоялась в рамках
конференции C3Days 2025.

Разговор, в роли модератора которого выступил руководитель отдела продуктового маркетинга компании C3D Labs Денис Стаценко,
начался с трактовки понятий. Low Code, No Code, AI – это методологии, при помощи которых конечный пользователь может решить поставленную задачу – в удобном для него интерфейсе конфигурировать новый продукт.

Преимущества подходов

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

Инженер-программист «Компас-3D» компании «Аскон» Валентина Дмитриева считает искусственный интеллект наукой, такой же, как химия или биология, внутри которой много подразделов (машинное и глубокое обучение, нейросети, большие языковые модели и т. д.). Сегодня чаще всего речь идет о больших языковых моделях. По мнению эксперта, хайп генеративного ИИ, который начался с появления чата GPT, продолжается. Генеративные модели создают много различной информации – текстовой, видео и т. д. В решениях Low Code и No Code эта технология также будет широко использоваться.

На вопрос модератора дискуссии об аргументах в пользу применения Low Code при создании инженерных систем участники разговора характеризовали преимущества, иллюстрируя их примерами. Product Owner ЦИМ компании «Цифрум» Татьяна Ковальчук отметила возможность переиспользования модулей, имеющихся на платформе Low Code. Например, при разработке продукта нужны были вьюеры для просмотра ПДФ-документации, чертежей. «И наша команда не потратила на это время, направила запрос коллегам в одну из служб платформы, которая занимается интерфейсами. Они сделали функциональность, а мы получили релиз платформы. Минимум затрат», – рассказала Татьяна.

Еще одно преимущество – сокращение кодовой базы. Один и тот же модуль подойдет для разных продуктов. Что касается рисков применения Low Code, то, по словам эксперта, отрасль сложная, поэтому при разработке архитектуры платформы предусмотрена возможность не только использования инструментов Low Code, но и добавления собственного кода, чтобы «не бежать к вендору за каждым чихом».

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

Риск упрощения

Участники дискуссии обратили внимание на риски упрощения, когда теряется точность, надежность или контроль либо когда пользователь не понимает, что на самом деле происходит «под капотом». Иными словами, пользователь «нажимает кнопки, выполняет действия, но при этом не осознает происходящего». Возможна и другая крайность: ограничение гибкости. Low Code дает алгоритм действий, паттерны поведения, и пользователю кажется, что за них он выходить не может.

Наличие подобных трудностей признал Александр Прохоров. Но прогресс не остановим. Производитель платформы Low Code дает набор инструментов, и часть пользователей, которые занимаются методикой решений, способны использовать их для создания новых решений. Применительно к рискам эксперт предлагает аккуратно оценивать аудиторию. Платформу дорого и сложно разрабатывать. Успех внедрения подхода Low Code зависит от аудитории, наличия большого количества схожих, но при этом уникальных задач (в его терминологии «комбинация трех факторов»).

Виртуальный помощник как панацея

На перспективы применения ИИ в процессе разработки инженерного ПО обратила внимание Валентина Дмитриева. Наиболее очевидный вариант автоматизации – внедрение аналога второго пилота (виртуального ассистента, Copilot) для программиста (интеллектуального помощника на основе ИИ). Программист пишет код, а ИИ-помощник дополняет, предлагает возможные или оптимальные решения и таким образом ускоряет разработку. Сегодня можно встроить аналог второго пилота, работающий не только с зарубежными моделями. Российские разработки представлены «Яндексом», «Сбером». Можно также упражняться в том, чтобы «поднимать» большие языковые модели на локальной инфраструктуре.

Более сдержан в оценке подобного варианта ведущий математик-программист компании C3D Labs Александр Алахвердянц. Он даже поделился идеей создания предметно-ориентированного языка, чтобы программисты с невысокой квалификацией могли писать более-менее безопасный код. По его словам, как показывает опыт, при использовании ИИ-инструментов нужен высококвалифицированный специалист, способный определить – «галлюцинирует» виртуальный помощник или дает хороший совет. Рассчитывать на существенное упрощение работы при таком подходе не стоит – сложность из одной сферы перетечет в другую. Инструментарий меняется, но требования к квалификации специалистов, способных делать качественные продукты, не снижаются.

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

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

Модератор Денис Стаценко заметил, что желание есть, но вопрос ресурсов, к тому же нет гарантий, что результат будет идеальным. В ответ Александр Алахвердянц признал, что в определенном смысле это исследовательская научная задача. Причем неточное решение его не пугает. Эксперт рассматривает нейронные сети как источник приближенного решения (вычисления на видеокартах происходят), которое потом («если мы говорим о будущем математическом решении для PLM») следует уточнять. Но и такая помощь нейронных сетей – большой шаг вперед.

Идею использования второго пилота, но уже для инженера-конструктора, обрисовала Валентина Дмитриева, когда речь зашла о том, как ИИ встроить в интерфейс CAD-системы. Умный ассистент способен предугадывать гипотетические шаги инженера-конструктора. Не менее перспективная задача – качественный реверс-инжиниринг с созданием дерева построения моделей.

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

Скорость разработки и «забагованность»

Когда встал вопрос о том, насколько увеличилась производительность программистов после внедрения умных помощников, Валентина Дмитриева рассказала, как пытались это измерить, для чего, например, старались распределять между командами одинаковые задачи. Выяснилось, что скорость разработки повысилась на 5–20%. Но можно ли довольствоваться таким показателем? Не лишним будет выяснить, насколько возросла «забагованность». При упоминании этого фактора аудитория заметно оживилась.

После обмена репликами эксперт отметила, что программисты, владеющие ИИ-инструменты, чаще пишут юнит-тесты (теперь это легко), ведь проверка отдельных компонентов кода – само по себе весьма скучное занятие. Кроме того, повысилось качество документации, которой программисты сопровождают предложенные решения. Таким образом, значение виртуальных помощников невозможно не учитывать, но оценить их влияние (измерить) действительно зачастую непросто. Программисты научатся код читать, что уже неплохо, поддержал коллегу Александр Прохоров.

Что мешает внедрению подхода Low Code в инженерном ПО? Мнения участников разговора и приведенные аргументы различались. Для одних экспертов это технические ограничения, уровень разработки, для других – предубеждения (классическая разработка более надежная, чем автоматическая с помощью кубиков, по шаблонам). Если в индустрии в целом Low Code не очень распространен, то предприниматели считают подобный шаг рискованным, и с этим приходится считаться. Имеет значение также уровень цифровой зрелости клиента в инженерной среде.

Знания в цене

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

Ряд задач с помощью платформы Low Code уже решается в определенных нишах, что дает возможность прилично сэкономить. Ключевой фактор для подобных проектов – объем рынка. Разработать платформу на порядок сложнее, чем разовое решение. Открытым остается вопрос поиска сегмента, в котором подход целесообразно внедрять – окупится ли разработка? Этот вопрос участники дискуссии адресовали аналитикам и исследователям рынка.

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