Ещё недавно, чтобы сделать приложение, нужна была команда. Сегодня ИИ за пару вечеров собирает интерфейс, генерирует код и выдаёт что-то, что уже нажимается и даже показывает данные. У бизнеса резонно возникает вопрос: а зачем вообще платить подрядчику?

Короткий ответ: между штукой, которая «работает на демо», и системой, от которой зависят сотрудники, клиенты и деньги, лежит пропасть. Ниже — разбор без магии. Что ИИ реально умеет, где он ломается и когда без профессиональной команды не обойтись.

Разработчики не спорят, использовать ИИ или нет. По данным Stack Overflow 2025, 84% респондентов применяют или планируют применять ИИ-инструменты. При этом доверие к результату падает: 46% активно не доверяют точности ИИ, доверяют — 33%. Среди опытных разработчиков «полностью доверяю» набирается 2.6%, а «совсем не доверяю» — 20%.  Чем выше цена ошибки, тем внимательнее читают то, что выдал ИИ.

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

В отчёте Stack Overflow 2026 видно, где разработчики реально используют ИИ: генерация кода в знакомой области (69%), отладка и рефакторинг (64%), простые технические вопросы (59%), тесты (58%). Заметно, что развёртывание, эксплуатация и безопасность — аутсайдеры. Для продакшена ИИ пока не тот инструмент, которому доверяют руль.

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

Что происходит, если два пользователя одновременно правят одну запись? Что если интеграция с 1С вернёт ошибку в неожиданном формате? Куда уходят логи, когда сервис падает в три ночи? Кто обновит зависимость, в которой нашли уязвимость? Как система ведёт себя, когда пользователей не десять, а десять тысяч?

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

Вот пример из нашей практики. Система контроля доступа для стадиона «Крылья Советов» на 45 тысяч мест. ИИ мог бы набросать интерфейс сканера билетов за вечер. Настоящая работа началась потом: переписать хранилище с Key Value на SQLite, потому что на Xiaomi интерфейс зависал при 45 000 билетов . Заменить часть SQLAlchemy на прямые запросы, потому что сервер не держал нагрузку . Прогнать 224 852 прохода за один тестовый прогон, чтобы убедиться, что в день матча ничего не упадёт . Ни одна из этих задач не решается генерацией кода. Они решаются пониманием, где именно система сломается.

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

Есть и цифры. METR в 2025 году провёл эксперимент с опытными open-source разработчиками: с ИИ они выполняли задачи на 19% дольше, чем без него. Позже METR признал, что новые данные могут указывать на ускорение, но из-за смещения выборки оценки ненадёжны.

Индивидуальная разработка оправдана, когда задача упирается в сложность, которая не сводится к генерации кода.

Сложная бизнес-логика, которую нельзя описать парой условий. Связка с корпоративными системами, у каждой из которых свой формат данных. Требования к надёжности и безопасности, за нарушение которых прилетит не «ой», а штраф или потеря клиентов. Нагрузка, при которой архитектура «в лоб» ложится на первой сотне одновременных пользователей. Продукт, который планируется развивать годами.

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

Если бизнес в финансовой сфере, отдельный разговор — разработка финансовых решений, разработка платежных систем и разработка финансовых приложений. Там цена ошибки в коде измеряется не переделкой, а лицензией и репутацией. Для оборудования — разработка iot и разработка приложений для мобильных устройств, где половина проблем не в интерфейсе, а в связке с железом. Для внутренних задач — разработка корпоративного портала: не сайт, а рабочая среда сотрудников.

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

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

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