Тендеры и лиды
Информация
Ещё недавно для создания приложения требовалась команда. Сегодня ИИ за несколько вечеров собирает интерфейс, генерирует код и выдаёт работающий прототип, который нажимается и показывает данные. У бизнеса возникает закономерный вопрос: зачем обращаться к подрядчику и платить за работу, которую теперь выполняет ИИ?
Ответ короткий: между прототипом, который работает на демонстрации, и системой, от которой зависят сотрудники, клиенты и деньги, лежит существенная разница. Разберём, что ИИ реально умеет, где его возможности заканчиваются и в каких случаях без профессиональной команды не обойтись.
Разработчики не обсуждают, использовать ИИ или нет. По данным Stack Overflow 2025, 84% респондентов применяют или планируют применять ИИ-инструменты. При этом доверие к результату снижается: 46% не доверяют точности ИИ, доверяют — 33%. Среди опытных разработчиков «полностью доверяю» набирается 2,6%, «совсем не доверяю» — 20%. Чем выше цена ошибки, тем внимательнее проверяют то, что выдала машина.
Основная проблема — не откровенно плохой код, а код, который выглядит почти правильным. На это указывают 66% разработчиков. Следом идёт отладка сгенерированного кода: 45% отмечают, что она отнимает больше времени, чем написание с нуля.
ИИ экономит время на старте и требует дополнительных затрат на финише, когда нужно разобраться, почему почти работающий код падает в продакшене. Особенно когда речь заходит об автоматизации обмена данными с внешними системами: значительная часть ошибок связана с чужими форматами, а не с синтаксисом.
ИИ-инструменты закрывают ограниченный класс задач. Прототип для проверки идеи. Простая внутренняя форма для сбора заявок. Дашборд поверх одной таблицы. Автоматизация повторяющейся операции, например перекладывания данных из CSV в CRM, если сбой не приведёт к серьёзным последствиям.
В отчёте Stack Overflow 2026 видно, где разработчики применяют ИИ: генерация кода в знакомой области (69%), отладка и рефакторинг (64%), простые технические вопросы (59%), тесты (58%). Развёртывание, эксплуатация и безопасность остаются в стороне. Для продакшена ИИ пока не инструмент, которому доверяют управление.
Граница проходит по цене ошибки. Если внутренний инструмент упал и никто не заметил — это одна ситуация. Если упал и клиент не получил заказ, деньги списались дважды или данные утекли — совсем другая. ИИ не различает эти сценарии, пока ему не объяснили. Объяснять и проверять — задача человека.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13836 тендеров
проведено за восемь лет работы нашего сайта.
Типичный сценарий: заказчик приносит приложение, собранное с ИИ. Кнопки работают, формы отправляются, данные отображаются. Всё выглядит готовым, пока не начинаются вопросы.
Что происходит, если два пользователя одновременно редактируют одну запись? Что если интеграция с 1С вернёт ошибку в неожиданном формате? Куда уходят логи, когда сервис падает ночью? Кто обновит зависимость, в которой нашли уязвимость? Как система ведёт себя, когда пользователей не десять, а десять тысяч?
ИИ-генератор отвечает на вопрос «как написать код, который выполняет действие X». Он не отвечает на вопрос «как сделать так, чтобы X работал надёжно и не разваливался при обновлении». Архитектура, обработка ошибок, разграничение доступа, миграции, мониторинг — это не код в чистом виде. Отдельная тема — разработка высоконагруженных систем: прототип на десять пользователей и система на десять тысяч — два разных инженерных упражнения.
Пример из практики. Система контроля доступа для стадиона «Крылья Советов» на 45 тысяч мест. ИИ мог бы набросать интерфейс сканера билетов за вечер. Основная работа началась позже: переписать хранилище с Key Value на SQLite, потому что на Xiaomi интерфейс зависал при 45 000 билетов; заменить часть SQLAlchemy на прямые запросы, потому что сервер не выдерживал нагрузку; прогнать 224 852 прохода за один тестовый прогон, чтобы в день матча система не отказала. Ни одна из этих задач не решается генерацией кода. Они решаются пониманием, где именно система сломается.
Отдельный слой, который ИИ не закрывает, — поддержка веб-сервисов и доработка существующего кода. Когда система уже работает, задача не в том, чтобы писать с нуля, а в том, чтобы разобраться, что сломано, что устарело, а что можно сохранить. Это работа про аудит кода и модернизацию программного обеспечения, а не про генерацию нового файла.
Есть и цифры. METR в 2025 году провёл эксперимент с опытными open-source разработчиками: с ИИ они выполняли задачи на 19% дольше, чем без него. Позже METR признал, что новые данные могут указывать на ускорение, но из-за смещения выборки оценки ненадёжны. Вывод не в том, что ИИ всегда замедляет. Вывод в том, что «ИИ ускоряет разработку» — не универсальная константа. На задачах с высокими требованиями к качеству и скрытыми условиями выигрыш может исчезнуть или превратиться в минус.
Индивидуальная разработка оправдана, когда задача упирается в сложность, которая не сводится к генерации кода.
Сложная бизнес-логика, которую нельзя описать парой условий. Связка с корпоративными системами, у каждой из которых свой формат данных. Требования к надёжности и безопасности, за нарушение которых прилетит не замечание, а штраф или потеря клиентов. Нагрузка, при которой архитектура «в лоб» ложится на первой сотне одновременных пользователей. Продукт, который планируется развивать годами.
Часто речь идёт не о разработке с нуля, а о доработке и модернизации программного обеспечения: аудит информационных систем, технический аудит программного обеспечения, поиск узких мест, постепенная замена устаревших компонентов. Отдельно возникает кастомная разработка, когда готовые решения не ложатся на процесс, и разработка корпоративного ПО, когда система нужна внутри компании, а не на рынке.
Если бизнес работает в финансовой сфере, отдельный разговор — разработка финансовых решений, разработка платёжных систем и разработка финансовых приложений. Там цена ошибки в коде измеряется не переделкой, а лицензией и репутацией. Для оборудования — разработка IoT и разработка приложений для мобильных устройств, где значительная часть проблем не в интерфейсе, а в связке с железом. Для внутренних задач — разработка корпоративного портала: не сайт, а рабочая среда сотрудников.
Заказная разработка не означает «писать всё с нуля». Иногда разумнее взять готовый компонент, подключить существующую систему и разработать только то, чего действительно нет на рынке. Подрядчик в такой ситуации отвечает за то, чтобы компоненты сошлись и не развалились в процессе эксплуатации.
Бизнесу не обязательно платить за создание каждого элемента системы с нуля. Но кто-то должен отвечать за надёжность, развитие и результат, когда приложение становится частью реальных бизнес-процессов. ИИ такой ответственности не несёт. Команда — несёт.
Если система уже есть, но развитие зашло в тупик, начинать заново необязательно. Мы отдельно разбирали, как сменить подрядчика и сохранить контроль над продуктом. А чтобы понять, что в существующем решении стоит сохранить, что доработать, а что переписать, — начните с аудита и оценки.
