Или история о том, как «работает на демо» перестаёт быть аргументом, когда приложением начинают пользоваться люди.
Представьте: бизнес решил сэкономить и собрал приложение с ИИ. Кнопки жмутся, формы отправляются, данные показываются. Всё выглядит готовым. А потом выясняется, что два пользователя не могут одновременно править одну запись, интеграция с 1С падает на неожиданном формате, а при десяти тысячах пользователей всё ложится. И спросить некого — генератор кода за результат не отвечает.
Мы разобрали, где проходит граница между прототипом и системой. Без магии и без «ИИ заменит всех».
Что разобрали
Посмотрели, что ИИ реально умеет в разработке. По данным Stack Overflow 2025, 84% разработчиков используют ИИ-инструменты. При этом 46% не доверяют точности результата. Самая частая боль — не «ИИ написал чушь», а «ИИ написал почти правильно»: на это жалуются 66% разработчиков, а 45% говорят, что отладка сгенерированного кода отнимает больше времени, чем писать самому.
То есть ИИ экономит время на старте и сжирает его на финише. Особенно когда дело доходит до интеграций — половина ошибок там в чужих форматах, а не в синтаксисе.
Самое сложное
Не написать код, а понять, где система сломается.
Первое — граница по цене ошибки. Если инструмент упал и никто не заметил — одно. Если упал и клиент не получил заказ, деньги списались дважды или данные утекли — совсем другое. ИИ не понимает разницы, пока ему не объяснили.
Второе — архитектура. Обработка ошибок, разграничение доступа, миграции, мониторинг — это не код в чистом виде. Это решения, которые принимаются с оглядкой на конкретный бизнес и инфраструктуру. Генератор кода их не принимает.
Третье — нагрузка. Прототип на десять пользователей и система на десять тысяч — два разных инженерных упражнения. В кейсе СКУД для стадиона на 45 000 мест ИИ набросал бы интерфейс за вечер. А потом пришлось переписывать хранилище с Key Value на SQLite, потому что на Xiaomi всё зависало, заменять часть SQLAlchemy на прямые запросы и прогонять 224 852 прохода в нагрузочных тестах.
К чему пришли
Было: «ИИ умеет писать код, значит, команда не нужна». Стало: ИИ закрывает часть задач, но не отвечает за результат, когда приложение становится частью реальных процессов.
Собрали таблицу, которая помогает выбрать подход под конкретную задачу: где хватит ИИ-прототипа, где нужен готовый сервис, где — интеграции и доработка, а где без индивидуальной разработки не обойтись.
Отдельный интересный момент
Заказная разработка не означает «писать всё с нуля». Иногда разумнее взять готовый компонент, подключить существующую систему и разработать только то, чего действительно нет на рынке. Подрядчик в такой ситуации — не фабрика кода, а человек, который отвечает за то, чтобы куски сошлись и не развалились.
Что дальше
Если у вас уже есть система или прототип и непонятно, что с ним делать дальше — мы можем посмотреть код, оценить риски и предложить план доработок. Без предложения «давайте всё заново».
Полный разбор — с цифрами, кейсом стадиона и таблицей выбора подхода — читайте на сайте: https://itfox-web.ru/ru/blog/zachem-biznesu-zakaznaia-razrabotka-esli-ii-uzhe-umeet-sozdavat-priloz?utm_source=sostav&utm_medium=social&utm_campaign=ai_vs_custom_dev&utm_content=post