Михаил Сорокин: Есть известное выражение: «если автоматизировать хаос, получится автоматизированный хаос». Оно в целом верно, но «окончательный крах» – это перебор. Автоматизация бизнес не убивает. Она закрепляет ошибки, которые раньше сглаживались ручным управлением и памятью конкретных людей. Типичная картина: заявки приходят с сайта, из почты, из мессенджеров, и никто в компании не договорился, что считать новой заявкой и кто отвечает за следующий шаг. Переносим это в CRM – хаос никуда не девается, просто теперь у него есть поля, статусы и отчёты. Цифры выглядят убедительно, но каждый сотрудник продолжает читать их по-своему. Обратная крайность тоже встречается: годами ждать идеального регламента. На практике часто именно первый прототип показывает, где процесс разваливается – какие данные реально нужны, где теряется ответственность, какие правила живут только в голове одного человека. До автоматизации нужна не стерильная чистота, а минимальная договорённость: что происходит, кто решает, какие данные критичны.

Михаил Сорокин: Для меня граница проходит там, где изменения перестают быть управляемыми. Настройка отвечает на локальный вопрос: добавить поле, отправить уведомление, передвинуть заявку по статусам. Архитектура смотрит шире: что это изменение сделает с данными, правами доступа, отчётностью и интеграциями через год. Тревожный момент наступает, когда никто не может объяснить, зачем существует конкретное поле или правило, но и убрать его страшно: обязательно что-то сломается в другом месте. Классическая история: для одного отдела делают специальный статус сделки. Под него добавляют автоматизацию, обходное поле, отдельный отчёт, интеграцию. Через год исходная задача забыта, а конструкция живёт. Любая правка превращается в расследование. Главный симптом – зависимость от человека, который всё это когда-то настроил и единственный помнит скрытые связи. Пока он в компании, кажется, что всё под контролем. Уходит – и выясняется, что гибкой системы нет, есть накопленный риск.

Михаил Сорокин: Существует, конечно. Больше того, есть процессы, которые автоматизировать просто невыгодно: операция выполняется редко, постоянно меняется и почти не приводит к ошибкам или потерям. Таблица, понятные правила и дисциплина в таких случаях работают лучше системы, которую нужно внедрять, оплачивать и поддерживать. Небольшая мастерская с несколькими заказами в неделю: владелец сам общается с клиентами, помнит сроки, видит оплаты. Система здесь создаст больше работы, чем пользы. Но когда заказов становятся десятки в день, ручной контроль начинает тормозить рост. А насчёт мифа – доля правды в упрёке есть. IT-компании действительно иногда начинают разговор с продукта и подписки, а не с задачи клиента. Это плохая практика. Сначала должна быть понятна проблема и цена её нерешённости, потом выбирается инструмент – от таблицы до платформы.

Михаил Сорокин: Сначала разведу понятия, потому что вайбкодинг и low-code часто смешивают, а это разные вещи. Вайбкодинг – нормальный способ быстро проверить идею: собрать прототип, показать клиентам, понять, есть ли вообще запрос. Риск возникает в момент, когда эксперимент незаметно становится рабочей системой. Появляются платежи, персональные данные, исключения для клиентов – а фундамент остался прототипным. Документации нет, а причины прежних решений теряются в истории переписок. Low-code при этом сам по себе техническим долгом не является. Зрелая платформа позволяет не создавать с нуля базовую инфраструктуру: модель данных, права доступа, отчётность. Но и на low-code можно собрать неподдерживаемую конструкцию, если строить без правил. Долг, который «невозможно выплатить», начинается в конкретной точке: команда больше не может оценить последствия изменения до того, как его сделает. С этого момента каждая доработка – лотерея.

Михаил Сорокин: Риск реальный, но виноват в нём не сам ИИ, а способ работы с ним. ИИ быстро предлагает структуру данных, сценарий автоматизации или бизнес-логику. Но «заработало» и «готово» – разные состояния. Критические правила должны быть понятны людям: кто имеет доступ к данным, почему система поменяла статус, как считается показатель. Если команда отвечает на такие вопросы только через историю чата с моделью, у неё есть рабочий прототип, но ещё нет архитектуры. Замечу, что явление не новое. Непрозрачные системы создавали и обычные разработчики, унося всю логику с собой после увольнения. ИИ просто увеличил скорость, с которой можно создавать решения, не успевая их осмыслить и задокументировать.

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

Михаил Сорокин: «Вопрос выживания» – слишком громко. Проектная модель никуда не денется, сложные задачи будут всегда. Уязвимость в другом: когда бизнес интегратора зависит от следующего проекта, каждый цикл начинается с нуля, а накопленная экспертиза активом компании не становится. Если интегратор несколько раз решил похожую задачу в одной отрасли, у него появляется развилка. Можно и дальше продавать часы. А можно выделить повторяемую часть – модель данных, основные сценарии, роли – и превратить её сначала в готовую конфигурацию, а затем в отраслевой пакет. Но SaaS – не обязательная вершина для всех. Это отдельный бизнес со своими продажами, поддержкой и экономикой удержания. Переход оправдан, когда есть повторяемая проблема и способность стабильно запускать такое решение для новых клиентов.

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

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

Михаил Сорокин: Я не вижу оснований ожидать, что через пять лет Enterprise-системы исчезнут. У крупных компаний останутся ERP и учётные контуры, где критичны масштаб и стандартизация. Расти будет другой слой: гибкие внутренние и отраслевые системы вокруг этого ядра. Роль Платформы Кб я вижу именно в этом гибком слое: она может служить инфраструктурой, на которой компании и IT-партнёры создают управляемые решения и встраивают их в существующий IT-ландшафт. Но у скорости есть обратная сторона. Если каждый отдел начнёт собирать себе систему без общих правил, получится теневое IT нового поколения: продажи по-своему определяют клиента, финансы – статус. Формально всё автоматизировано, фактически данные снова разошлись. Поэтому роль IT-директора станет шире. Помимо эксплуатации технологий, он будет определять архитектурные границы: какие данные считать эталонными, кто вправе создавать новые системы и как эти решения интегрируются. Запрещать инициативу не нужно – нужна среда, где она реализуется быстро, но без потери управляемости.