До сих пор развитие корпоративных ИТ-систем в крупном бизнесе, как правило, строилось вокруг вендорских платформ, которые компании годами адаптировали под собственные процессы. В отдельных случаях бизнес создавал полностью собственные решения с нуля. У каждого подхода были свои ограничения, но сегодня искусственный интеллект впервые меняет экономику этих сценариев. Рынок стоит на пороге своеобразной реинкарнации самописных систем — уже в совершенно новом качестве. Дмитрий Бороздин, сооснователь и генеральный директор RetailCRM, рассказывает о будущем корпоративных систем и о новой роли вендоров в нем.
Как ИИ меняет экономику разработки
На протяжении многих лет развитие корпоративных ИТ-систем — дорогостоящий и трудоемкий процесс. Чем сильнее корпоративная система адаптировалась под конкретный бизнес, тем сложнее и дороже становилось ее дальнейшее развитие.
Однако сегодня мы наблюдаем, как ситуация может измениться. Развитие ИИ впервые может дать инструменты, которые способны структурно и логически ориентироваться в больших кодовых базах, работать с огромными объемами данных и помогать наводить порядок в большом наследии внутрикорпоративных доработок и право ПО. Например, в RetailCRM базовый код составляет около полутора миллионов строк, а совокупная экосистема — около трех миллионов. В отдельных случаях, при условии строгого контроля и перепроверки, ИИ уже справляется с этим объемом. Во втором квартале 2026 года он у нас участвовал примерно в половине из 2,2 тыс. изменений кода: разработчики используют его для отдельных функций, тестов и однотипных правок.
Мы также начали пилотировать ИИ-агента для проверки кода: он анализирует внесённые изменения и может, например, обратить внимание на пропущенную проверку прав доступа, необработанный сценарий или недостаток тестов. Сейчас это начальный пилот: планируется до 100 проверок в месяц. Расчётная экономия только от этой доработки может составить до 3,6 млн рублей в год.
В результате развития как самих моделей, так и средств контроля качества, сопровождение и кастомизация корпоративного ПО становятся быстрее и дешевле. Практика RetailCRM показывает: чем больше порядка, чем лучше детерминирован процесс разработки до ИИ, тем меньше проблем и ошибок возникает при переходе на современный стек разработки, использующий ИИ модели. Это касается сразу двух типов корпоративных систем, хотя эффект для них оказывается разным.
Два типа систем — два эффекта
Важно разделять два типа решений.
Первый вариант — полностью самописная система, созданная с нуля. Со временем в них часто устаревает документация, архитектурные решения оказываются завязаны на знания отдельных разработчиков, а чтобы внести изменения, новой команде приходится сначала разбираться в большом объеме legacy-кода.
Здесь ИИ становится инструментом, который помогает разобраться в существующей системе. На вход ему можно подать код, а также доступные данные об архитектуре, правила развития системы, особенности интеграций, бизнес-требования и конкретные автоматизируемые процессы или сценарии. На основе этого ИИ может проанализировать текущее решение, выявить потенциальные проблемы и предложить варианты его развития. С помощью ИИ можно написать техническую документацию и на её основе вносить конструктивные изменения — по сути, отладить сопровождение. ИИ снижает стоимость и сложность работы с уже существующим наследием. Но при этом нельзя забывать и о рисках, которые на данный момент сопровождают такой подход.
Второй вариант — системы, которые изначально были построены на базе вендорской платформы и в течение нескольких лет активно дорабатывались заказчиком под собственные процессы. Такие решения сочетают надежное технологическое ядро и глубокую кастомизацию под конкретный бизнес. У них, как правило, уже сформировалась устойчивая архитектура и более структурированная документация.
И именно у этой модели сегодня самый большой потенциал развития. Здесь ИИ может стать новым уровнем взаимодействия с системой.
Что можно доверить ИИ, а что требует проверки
Однако тут важно отметить, что реальная работа с ИИ быстро показывает его границы. На практике лучше всего ИИ работает с задачами, где есть понятные правила и результат, который можно проверить. Например, однажды нам требовалось подготовить интеграцию с маркетплейсом к изменению формата обмена ценами. ИИ заменил устаревшее название поля и добавил проверку отправляемых данных. Автоматические тесты прошли успешно, затем изменение проверил и принял специалист.
ИИ также часто эффективен как дополнительный проверяющий. В одной из интеграций он заметил риск сбоя при переходе на двухэтапную отгрузку. Иногда складывалась такая ситуация: отгрузка уже существует, но подтверждение завершается ошибкой или его ответ теряется в сети. Программа не сохраняет полученный номер и при следующей попытке может создать ещё одну отгрузку. ИИ подсветил такой сценарий, а разработчик добавил необходимую обработку.
Сложнее задачи, где нужно понять контекст системы. Показательный пример из нашей практики — автоматический тест браузерного интерфейса, который перестал находить уже открытую боковую панель. ИИ изменил механизм поиска элементов, после чего тесты снова начали проходить. Но дополнительная проверка показала, что проблема была глубже: разные части интерфейса использовали разные экземпляры одной библиотеки компонентов, которые создавали одинаковые технические идентификаторы. То есть предложенное ИИ исправление помогло тесту пройти проверку, но не устранило причину, из-за которой возникала ошибка.
Похожая ситуация возникает, когда ИИ работает с кодом, но не учитывает особенности процесса его генерации. В одной из задач изменения были внесены в файл, который автоматически пересоздавался при сборке. При следующей генерации они исчезли, а сборка показала, что другие части системы всё ещё на них ссылаются. После этого код перенесли в обычный исходный файл. Для ИИ это был корректный фрагмент кода, но неправильное место для его изменения.
Для меня это хорошие примеры ограничения ИИ: там, где нужно выбрать бизнес-правило, понять архитектурные последствия изменения или определить, действительно ли устранена причина проблемы, решение всё ещё должен принимать специалист. Поэтому мы пока не выдаём расчётный эффект ИИ за достигнутую экономию. Мы видим, сколько рутинной работы он может взять на себя, но пока не считаем время человека на постановку задачи, проверку результата и принятие решения. Именно эта часть процесса ещё требует отдельной оценки.
Когда пользователь сможет создавать новые функции сам
Но необходимость проверки не отменяет главного экономического эффекта: ИИ уже сегодня удешевляет разработку и сокращает объём ручной работы. И здесь я перехожу к идее, в которую сильно верю. Я считаю, что следующий закономерный этап развития корпоративного ПО — переход от разработки отдельных модулей к созданию систем, которые могут самостоятельно создавать у себя новые возможности.
Мы уже сегодня видим, что технологии для этого готовы: у нас буквально на глазах рождается CRM-платформа, которая может дописывать себя сама. Недавно мы протестировали обновление: разработали возможность с помощью JS API создавать целые новые кастомные разделы внутри платформы. Плюс GraphQL позволяет воспроизводить практически любые действия в системе.
В результате помимо стандартной ИИ-копилота в продукте появится ИИ-разработчик, которому пользователь прямо в своем аккаунте сможет поставить задачу обычным языком, например: «Создай раздел, который будет делать сложный скоринг, забирать данные из внешней системы, рассчитывать показатели, выгружать нужные колонки и отображать все в красивом виде».
И это касается не только CRM. В будущем подобный подход может стать частью практически любого корпоративного ПО: пользователь сможет не ждать очередного релиза, а сам адаптировать продукт под изменяющиеся процессы практически в режиме реального времени.
Новая роль поставщика ПО
Если этот сценарий действительно заработает, изменится и роль поставщика ПО. Он больше не будет выступать основным исполнителем доработок. Его функция теперь будет заключаться в предоставлении надежного технологического фундамента, на котором бизнес сможет самостоятельно строить необходимые ему решения с помощью ИИ. Искусственный интеллект сделает такую кастомизацию проще, быстрее и дешевле.
При этом ИИ не отменяет необходимость качественной архитектуры и профессиональной разработки. Например, когда мы внедряли ИИ-автоматизацию, самой трудоёмкой частью всегда было связать внутренние системы и привести данные к общему порядку. В разных источниках один сотрудник, клиент или проект могут называться по-разному. Нужно было сопоставлять записи, определять ответственных, договариваться о правилах расчёта и проверять результат на реальных примерах. Каждая из этих задач занимал от двух до четырех месяцев работы.
Есть и обратная сторона: результат работы ИИ необходимо проверять и разбирать. Если система сгенерировала много кода или изменений, найти в нем ошибку может оказаться отдельной и довольно сложной работой, которая иногда стоит дороже и занимает больше времени, чем первоначальная разработка.
Чем лучше организована разработка — понятнее архитектура, документация, зависимости и проверки, — тем больше задач можно безопасно передавать ИИ.
Второе рождение самописных систем
У бизнеса всегда будет потребность развивать и кастомизировать ИТ-решения, поскольку именно в уникальных процессах часто заключается их конкурентное преимущество. И сегодня искусственный интеллект меняет сам подход к разработке таких систем.
Именно в этом смысле мы будем наблюдать своеобразную реинкарнацию самописных решений. Искусственный интеллект станет тем связующим звеном, которое позволит компаниям быстрее превращать идеи в работающие инструменты. Кастомизация станет доступной, управляемой и значительно менее затратной. А программное обеспечение окончательно превратится в живую среду, способную эволюционировать вместе с бизнесом.
Я считаю, что именно так в итоге должны выглядеть современные продукты: давать надежные узлы и одновременно возможность гибко настраивать их под конкретные задачи бизнеса.
Источник: Дмитрий Бороздин, сооснователь и генеральный директор RetailCRM
