ИИ снижает стоимость кода, но повышает требования к разработке

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

Екатерина Медведева, управляющий директор-партнер GreenData, на

XXI Конгрессе ИТ-директоров «Белые Ночи»

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

Сегодня уже никто всерьез не спорит, может ли модель написать код. Может. Вопрос в другом: можно ли этот код запускать в промышленный контур. Кто его проверит? Кто объяснит логику решения? Кто будет отвечать за ошибку? Кто обновит приложение через полгода? Как передать решение другой команде?

Что изменилось

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

Сеньоры пишут 50% своего кода с помощью искусственного интеллекта

Спрос на такие инструменты уже стал массовым. По данным Stack Overflow Developer Survey, 84% разработчиков используют или планируют использовать ИИ-инструменты в работе. Но при этом 46% не доверяют точности ответов ИИ, а полностью доверяют только около 3%. То есть ИИ используют, но результатам не доверяют.

Дмитрий Васильев, генеральный директор Code Pilots, поделился опытом своей команды. Сначала компания пошла самым простым путем: загрузила ТЗ в модель и попросила оценить проект. Не сработало. Оценка получалась непредсказуемой и могла отличаться от реальности в несколько раз. Доверять такому результату было нельзя.

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

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

ИИ в разработке программного обеспечения

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

Этот кейс хорошо показывает, что ИИ полезен не сам по себе, а внутри отлаженного процесса. Он ускоряет работу на конкретном этапе, но не заменяет разработку целиком.

К похожему выводу пришла METR. В 2025 году организация провела эксперимент с 16 опытными open-source-разработчиками на 246 реальных задачах в знакомых им проектах. Участники ожидали ускорения на 24%, а после эксперимента им казалось, что ИИ ускорил работу примерно на 20%. На практике же, задачи с ИИ потребовали на 19% больше времени. Сгенерированный результат нужно было читать, проверять, исправлять и встраивать в существующий код.

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

Екатерина Медведева, управляющий директор-партнер GreenData, обращает внимание именно на этот слой. Для enterprise-приложения важны не только формы и бизнес-логика. Нужны управление доступами, аудит, логирование, интеграция с мониторингом, подключение к внутренним системам без открытого API, обновление без остановки и понятный процесс передачи решения между командами.

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

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

ИИ требует правил и контроля

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

Поэтому снова растет значение платформенного подхода. Не в том смысле, что low-code или BPMS заменят разработку. Их роль другая: они задают рамки, в которых ИИ может быть полезен без дополнительного расширения хаоса. Есть модель процесса, типовые элементы, роли, коннекторы, исполняемое приложение, мониторинг, аудит, KPI и SLA.

Владимир Быков, директор по развитию аналитического центра «Круги Громова», описывает BPMS как среду, где бизнес-процесс сначала моделируется, а затем может быть превращен в исполняемое приложение. Важна не столько скорость запуска, сколько контроль исполнения, архив процессов, аудит, мониторинг и управление.

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

Быков отмечает, что ИИ уже встраивается в такие системы. Бизнес-процесс можно описать текстом и получить BPM-диаграмму. Из модели можно вызывать LLM-агентов. No-code-системы уже предлагают готовых AI-агентов, например для классификации входящих документов.

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

Но контур нужен не только коду. Он нужен и для распределения ответственности. Андрей Нестеров, профессор практики и руководитель лаборатории «Лидерство + ИИ» бизнес-школы ИМИСП, называет это новой управленческой границей. Компаниям нужно заранее определить, что можно отдать алгоритму, где решение остается за человеком и кто отвечает за результат работы агента.

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

AI-код требует новых правил

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

Обзор Российские low-code BPM-решения Представьте, что компания — это оркестр. Только вместо инструментов у его участников документы и программы, а вместо нот рабочие процессы, которые требуется выполнять в нужной последовательности. Система BPM (Business Process Management) — это дирижер, который знает, кто, что, когда и в каком порядке должен сделать и что предпринять, если что-то пошло не так.

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

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

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

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