«А давайте сделаем сами». Почему ИИ не отменил рынок готового ПО

Экономика разработки действительно изменилась, наша команда из 15 человек работает с ИИ-инструментами последние 2 года и выполнение задач ускорилось на 30−40%.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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