Вопрос был про платформу. Оказался — про горизонт.

Я занимаюсь бизнесом больше тридцати лет. Последние два года строю IT-компанию, в которой код пишет ИИ, — и среди клиентов, которые к нам приходят, один тип запросов встречается всё чаще: «нам нужна CRM» или «нам нужна единая система для менеджеров по продажам». На первый взгляд — задача про выбор платформы. На деле — задача про то, на сколько лет компания принимает решение.

Расскажу один конкретный случай.

К нам пришла торговая компания в B2B-сегменте — стройматериалы, несколько сотен менеджеров по продажам, постоянные клиенты с долгими циклами и крупными заказами.

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

Клиент хотел CRM: рабочее место, в котором всё в одном месте — клиенты, задачи, заказы, переписка, внутренние запросы к юристам и бухгалтерии, строительные объекты, отчёты. Готовые рыночные решения были изучены, IT-отдел заключил, что они не справятся с масштабом. Значит, заказная разработка или серьёзная корпоративная платформа.

Мы начали с того, что изучили, что уже есть в компании.

Обнаружился факт, который на первый взгляд делал выбор бесспорным. В компании с 2024 года идёт программа цифровой трансформации, и в её рамках уже развёрнута корпоративная платформа для автоматизации внутренних процессов. Юристы обрабатывают запросы там. Бухгалтерия работает там. Данные из финансовой системы уже ходят в эту среду. Цикл работы с просроченной дебиторской задолженностью сократился там с 55 до 40 дней.

То есть то, что клиент называл «запросами к внутренним службам» — это не будущая интеграция. Это процессы, которые уже живут в платформе. Менеджер, создавая задачу юристу, не отправляет письмо в почту — он создаёт задачу в уже работающей системе с дедлайнами и эскалацией.

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

Если смотреть на горизонте года-двух, это был бы правильный ответ.

Но у нас был второй вопрос, который мы задали параллельно. Не «какую платформу выбрать», а «как это выглядит, если разработка ведётся методом 100% ИИ-кодинга».

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

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

И здесь выбор платформы начинает звучать иначе.

Большинство корпоративных платформ — это так называемые low-code-среды. Low-code означает, что основная часть настройки делается через визуальный интерфейс: бизнес-процесс рисуется на схеме, согласования настраиваются в формах, сущности создаются кликами. Программный код — лишь небольшая часть.

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

В итоге: при работе с low-code платформой выигрыш от ИИ-кодинга будет частичным. Ускоряется только код-часть. Конфигурационная часть остаётся ручной — и этот ручной труд не ускорится при совершенствовании инструментов.

Другая картина — со стандартным открытым технологическим стеком: Python, TypeScript, React, PostgreSQL. Это языки и базы данных, на которых написаны тысячи продуктов по всему миру. Именно на таком коде обучены современные языковые модели. Именно его они пишут быстро, точно, с понятной структурой. Здесь методология работает в полную силу.

Заказная разработка на стандартном стеке с методологией 100% ИИ-кодинга — это уже не «дорого и долго». Первая версия: те же четыре-семь месяцев, что у платформы. Стоимость разработки: сопоставимая. Но после запуска нет ежегодных лицензионных платежей за пятьсот пользователей. Нет потолка в виде возможностей платформы. И каждая новая функция — в разы быстрее, чем на low-code.

Вопрос не в том, что дешевле сейчас. Вопрос в том, как выглядит система через три года, когда 100% ИИ-кодинг станет стандартом в разработке.

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

У этого выбора есть историческая параллель, которую я хорошо помню.

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

100% ИИ-кодинг выглядит сейчас примерно так же. Поначалу кажется, что разработка стала немного быстрее. Но за этим скрывается другая логика: скорость итерации над продуктом превращается в конкурентный фактор. Компания, которая выпускает новую функцию за четыре дня, и компания, которая выпускает её за три недели — это не просто разная скорость. Это разное качество реакции на рынок.

По итогу мы сформулировали клиенту не один ответ, а два.

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

Если горизонт — пять лет, и скорость развития системы важна как конкурентный фактор: тогда заказная разработка на стандартном стеке с 100% ИИ-кодингом. Та же скорость запуска, сопоставимая стоимость, но нет лицензий при росте и нет потолка в виде возможностей платформы. ИИ-функции — не надстройка поверх чужой архитектуры, а слой, встроенный с первого дня.

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

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

Но именно она сейчас меняет то, что раньше казалось фиксированным: сколько стоит первая версия, как быстро она выходит, с какой скоростью система развивается после запуска. Это не технический вопрос — это стратегический.

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

Вопросы организации разработки, когда весь производственный процесс построен на ИИ, мы с партнёром разбираем в стандарте SENAR. Подробнее — на senar.tech.