Владислав Беляев, AutoFAQ.ai: Разработка с ИИ может оказаться дороже готового решения

«А давайте сделаем сами»

Есть фраза, которую сейчас всё чаще слышат коммерческие команды поставщиков корпоративного ПО: «А зачем нам покупать лицензию? Давайте разработаем сами. Теперь же есть ИИ».

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

В последнем исследовании McKinsey «State of AI 2026» 32% респондентов сообщили, что их компании отказались от покупки хотя бы одного программного продукта или функции, поскольку смогли самостоятельно создать аналог с помощью ИИ-агентов для написания кода. На этом месте легко сделать вывод: если разработка стала дешевле и быстрее, зачем вообще покупать готовое ПО?

В то же время ежегодный опрос разработчиков от Stack Overflow показывает более сдержанную картину: только 19% разработчиков создают ПО для замены платных решений, хотя среди них более половины используют ИИ.

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

Что на самом деле продаёт вендор

Экономика разработки действительно изменилась: наша команда из 15 человек работает с ИИ-инструментами последние два года, и выполнение задач ускорилось на 30–40%. При этом остались узкие места на этапах уточнения и согласования постановки задач, тестирования, развёртывания необходимой инфраструктуры с особенными настройками для проверки и классический возврат на последнем этапе сдачи, когда «оказалось», что заказчик хотел иного.

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

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

В случае с AutoFAQ внешние сервисы коммуникаций выпускают новые версии API, и интеграции приходится переделывать. Службы безопасности находят уязвимости, и их нужно закрывать. Бизнес просит сценарии или «галочку», которых не было в исходной постановке задачи, и добавлять их нужно так, чтобы не сломались старые. Растёт нагрузка, и архитектура, работавшая на прежнем масштабе и задачах, перестаёт подходить. Есть известная фраза, что с ростом нагрузки на порядок приходится целиком переписывать систему. Меняется регулирование, появляются новые каналы коммуникации, обновляется отчётность. Ни один из этих пунктов не исчез из-за появления ИИ.

ИИ ускоряет только то, что можно проверить

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

ИИ ускоряет работу там, где есть чем проверить результат. У зрелого продукта за годы разработки и эксплуатации накапливается тестовая база, покрывающая компоненты, их взаимодействие, бизнес-логику и нагрузку, плюс чек-листы ручного тестирования и готовые тестовые окружения. В нашем случае это десятки тысяч тестов, написанных людьми, и 30–40% ускорения разработки стали возможны только благодаря тестам. У проекта, который стартует сегодня, нет тестов, и выходит, что ИИ ускоряет производство непроверенного кода или кода, который невозможно проверить.

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

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

Похожую закономерность показывает и опрос Stack Overflow. Чем сложнее и критичнее система, тем осторожнее разработчики относятся к использованию ИИ. Для небольших автоматизаций ошибки легко найти и исправить. В корпоративном ПО цена ошибки выше, а проверка и поддержка кода требуют больше ресурсов. При покупке готового решения значительная часть этих задач остаётся на стороне поставщика. При внутренней разработке ими занимается команда. Поэтому при сравнении двух подходов важно учитывать не только скорость создания кода, но и ресурсы на его проверку, поддержку и развитие.

Ошибки, за которые уже заплатил кто-то другой

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

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

Например, некоторые ошибки проявились только через один-два года при определённых начальных условиях и в связи со сменой условий эксплуатации. Ошибки были исправлены, но функциональные и нефункциональные требования остались без изменений. За весь этот опыт придётся заплатить в случае разработки системы «с нуля» за счёт собственных пользователей и клиентов.

То же самое происходит с безопасностью. Единую рыночную поставку тестируют службы безопасности банков, телеком-операторов, страховых компаний и государственных организаций, независимо друг от друга, разными методиками и в разные сроки. Результаты каждой такой проверки попадают в общий продукт. Внутреннюю разработку может проанализировать ИИ, и, если «не» повезёт, к ней будут предъявлены внутренние требования информационной безопасности, аналогичные тем, которые предъявляют к рыночным решениям.

Внешняя среда меняется независимо от вашего релизного плана

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

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

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

Что не попадает в бюджет проекта

Токены языковых моделей стоят денег. Если пересчитать экономику разработки в единицы потребления облачных сервисов, получается следующая картина. Стоимость токенов для разработки части среднего микросервиса силами senior-специалиста обойдётся дополнительно в 0,5–1 месячный оклад, а в системе нашего класса десятки микросервисов. К этим затратам добавляются тестировщики и стоимость инфраструктуры тестовых окружений, в которых проверяется создаваемый функционал, работа менеджера по продукту. Реалистичный сценарий разработки промышленного полнофункционального решения, выполняющего требования безопасности и надёжности, с использованием ИИ выглядит как фонд оплаты труда 3–5 человек в течение 1,5–2 лет плюс затраты, сопоставимые с 200–300 тысячами долларов на инфраструктуру и токены за тот же период.

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

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

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

Продуктовая команда не может бросить систему, потому что на ней держатся десятки клиентов и весь бизнес компании. Ответственность вендора — обеспечить надёжность и сменяемость команды. Внутренняя разработка держится на одном заказчике и на нескольких конкретных людях, поэтому есть высокий риск, что проект закончится, если люди изменят место работы или бюджет переведут на более приоритетный проект.

Скорость изменений для бизнеса

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

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

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

Когда разрабатывать самим правильно

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

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

Что ИИ изменил, а что нет

Мы считаем, что люди по-прежнему необходимы в коммерческих продуктах, когда требуется следить за нагрузкой, закрывать уязвимости, обновлять интеграции, проверять, что новая версия не сломала старые сценарии, и быстро отвечать перед бизнесом, если «продуктив лёг». Корпоративное ПО существует потому, что кто-то должен отвечать за систему годами. ИИ снизил стоимость разработки, но не берёт на себя ответственность за продукт.

Ключевой вопрос, на который нужно ответить: «Кто будет заниматься этой системой через три года?» Если простого ответа нет, покупка готового решения окажется дешевле даже в ситуации, когда код научились писать почти бесплатно.