ИИ снижает стоимость реализации за счёт одного конкретного механизма: дешевеет интеллектуальная итерация, то есть цикл «предположил, проверил, переделал». Когда такой цикл стоит меньше, сдвигается граница между «идея есть» и «система работает».
Следствие расходится в две стороны. Покупателю ПО дешевле собрать своё решение вместо готового сервиса, а специалисту без команды разработчиков дешевле выпустить собственный продукт. Обе стороны опираются на одну экономику: превращение профессионального мнения в работающую систему перестало быть дорогим проектом.
Ограничение стоит держать в голове с самого начала. ИИ ускоряет рутину и черновую сборку, а противоречивые правила корпоративных систем, интеграции, исторические данные и ответственность за ошибки остаются на людях. Ниже - механизм, следствия для SaaS и новая расстановка сил между специалистами.
Почему ИИ снижает стоимость реализации: механизм и последствия
Что такое стоимость интеллектуальной итерации и как она падает
Стоимость интеллектуальной итерации - это цена одного прохода «проверить и поправить»: написать черновик расчёта, сверить его с данными, найти расхождение, переделать. Пока проход дорогой, специалист делает его редко и заранее выбирает безопасный вариант.
Пример, который хорошо показывает масштаб сдвига: если дополнительная проверка раньше занимала два часа, а теперь десять минут, меняются и производительность, и представление о нормальном результате. Автор разбора «Профессионал и Системы» описывает это как смену нормы: проверка, которую раньше делали один раз в конце, встраивается в обычный рабочий цикл.
Практический смысл простой. Когда лишняя проверка стоит десять минут, дешевле проверить, чем угадывать. Поэтому в работу попадают варианты, которые раньше отбрасывались на старте как слишком рискованные.
От профессионального мнения к работающей системе: что изменилось
Раньше между мнением специалиста и работающим продуктом стояла смета: несколько разработчиков, их зарплаты, месяцы работы. Дороговизна перевода идеи в код отсекала большинство замыслов на входе, и это касалось не только крупных проектов.
Сейчас перевод дешевеет. Специалисту, которому раньше для выхода на рынок не хватало не профессиональной идеи, а нескольких разработчиков и денег на их содержание, хватает собственной экспертизы и ИИ-инструментов. Этот же разбор фиксирует симметрию: если покупателю стало дешевле сделать продукт, то и любому специалисту стало дешевле сделать его вообще.
Второй эффект менее очевиден. Если решение проблемы дешевеет, в работу попадают задачи, которые раньше никто не решал не потому, что они никому не нужны, а потому, что стоимость ответа превышала стоимость решения. Речь о мелких и неудобных вопросах: расчёт нестандартной скидки, сверка двух несовпадающих справочников, разбор архива за прошлые годы, проверка одного подозрительного контрагента.
Что это значит для SaaS: какие сервисы теряют смысл, а какие остаются
Разговоры про «смерть SaaS» появились не на пустом месте. Если ИИ позволяет компании быстро сделать собственный сервис для обработки документов, отчётности или небольшого внутреннего процесса, покупать готовый продукт становится незачем. Для части нынешнего SaaS это реальная проблема, а не теоретическая угроза. Об этом прямо сказано в первоисточнике.
Универсальные SaaS под угрозой: когда покупать готовое перестаёт иметь смысл
Под удар попадают продукты, чья ценность держится на стоимости разработки, а не на уникальной экспертизе. Формула простая: кто-то однажды потратил полмиллиона на разработку очевидной функции и теперь продаёт её по двадцать евро в месяц. Падение стоимости разработки разрушает значительную часть этой экономики, потому что тот же результат дешевле собрать внутри компании.
Типичные кандидаты на такую судьбу: конвертеры и парсеры документов, генераторы типовых отчётов, небольшие формы согласования, внутренние дашборды по одному источнику данных. Общее у них то, что логика прозрачна и не требует доменного суждения: правила описываются на полстраницы, а спорных исключений почти нет.
Устойчивее выглядят сервисы, где ценность в накопленных данных, интеграциях и поддержке, а не в самом факте написанного кода. Там, где нужно отвечать за корректность расчёта перед регулятором или держать десятки внешних подключений, самодельная замена через ИИ быстро упирается в сопровождение.
Новые возможности: узкоспециализированные продукты и расширения поверх SAP и 1С
Обратная сторона удешевления: небольшие продукты стало дешевле делать вообще, включая специалистов без команды. Отсюда ниша - расширения и надстройки поверх крупных платформ. У SAP и 1С есть стандартный функционал и есть места, где он не совпадает с тем, как реально работает конкретный отдел.
Пример: специалист по закупкам в 1С знает, что заявка на определённую категорию товаров всегда проходит дополнительную проверку поставщика, которой в типовом маршруте нет. Расширение на десяток правил, закрывающее этот шаг, для бизнеса ценнее ещё одного универсального модуля согласования, который придётся настраивать месяцами.
Оговорка по фактам: в разобранном первоисточнике примеры SAP и 1С не приводятся, там речь идёт об общем механизме удешевления реализации. Это экстраполяция на конкретные платформы, а не подтверждённый кейс, и проверять её стоит на своём контуре с реальными правилами и данными.
Корпоративные системы: почему ИИ не отменяет сложность
Большая корпоративная среда устроена так, что часть логики не вытаскивается в аккуратное описание: правила накапливались годами, некоторые противоречат друг другу, некоторые держатся на устных договорённостях. Текст первоисточника обрывается ровно на теме корпоративной среды, поэтому дальше - разбор механизма, а не пересказ чужой статьи.
Противоречивые правила и исторические данные: что ИИ не берёт на себя
Правила в ERP конфликтуют между собой регулярно. Маршрут согласования по внутреннему регламенту расходится с требованием налогового учёта. Лимит по договору считается в одной валюте, а оплата проходит в другой. Категория номенклатуры в справочнике одна, а склад учитывает её иначе. ИИ предложит вариант разрешения конфликта, но не знает, какой из двух регламентов в компании главнее.
Исторические данные добавляют второй слой проблем: справочники дублируются, коды менялись после миграций, часть проводок закрыта вручную и пояснений к ним не осталось. Модель, работающая на таком массиве, уверенно воспроизведёт ошибку прошлых лет, потому что статистически она выглядит нормой.
Ответственность за ошибки: почему человек остаётся в контуре
Ошибка в корпоративной системе превращается в деньги и юридические последствия: неверная проводка, завышенная себестоимость, отчётность не в срок, ошибочный платёж контрагенту. Ответственность за это несёт человек и организация, а не модель.
Рабочий сценарий выглядит так: ИИ готовит вариант и объясняет логику, специалист проверяет допущения и утверждает результат. Полное делегирование без проверки упирается не в качество модели, а в отсутствие того, кто подпишется под решением. Граница между полезной передачей задач и потерей контроля разобрана в материале про то, почему часть разработчиков не отдаёт код ИИ-агентам.
Как меняется конкуренция между специалистами
Когда перевод мнения в систему дешевеет, дороже становится само мнение. ИИ уверенно воспроизводит типовые решения: стандартный отчёт, типовую интеграцию, общеизвестную практику. Различить двух специалистов с одинаковым набором инструментов можно только по суждению о конкретной операции.
Почему собственное мнение становится важнее умения воспроизводить практики
Типовая ситуация: два человека одинаково хорошо владеют платформой и одинаково быстро генерируют код. Первый собирает то, что просят. Второй уточняет, зачем это нужно, и предлагает другой разрез данных или иной шаг процесса. Выигрывает второй, потому что приносит то, чего в запросе не было.
Это перекликается с историей аналитиков: доступ к данным упростился, а ценность методологического слоя выросла. Разбор про ИИ и self-service BI показывает ту же логику на отчётности: вопросы к данным задать стало проще, а договориться о том, как считаются метрики, по-прежнему должен человек.
От больших ERP к конкуренции отдельных операций
Раньше единицей сравнения была система целиком: SAP против 1С, одно решение против другого, длинный чек-лист внедрения. Когда надстройку под конкретную операцию стало дёшево собрать, сравнение смещается на уровень шага процесса: у кого лучше реализовано закрытие смены, подготовка заявки, сверка с поставщиком.
Вывод для специалиста: глубина в одной операции даёт больше, чем поверхностное знание всей платформы. Расширение для 1С, закрывающее конкретный шаг, может принести бизнесу больше пользы, чем ещё один универсальный модуль с полугодовой настройкой.
Практические примеры: как ИИ уже меняет разработку
Пример первый: компания вместо покупки готового SaaS быстро делает собственный сервис для обработки документов, отчётности или небольшого внутреннего процесса. Задача узкая, требования известны только сотрудникам, а ИИ снимает основную часть работы по сборке черновика системы.
Пример второй: специалист без команды разработчиков и без денег на её содержание выходит на рынок с небольшим продуктом. Его вклад - постановка задачи и предметная логика, рутинное написание кода берут на себя ИИ-инструменты.
Оба сценария следуют напрямую из удешевления интеллектуальной итерации, а не из отраслевых презентаций. Ограничение видно там же: скорость сборки растёт быстрее, чем способность поддерживать результат. Как выглядит обратная сторона, когда прототип превращается в нечитаемый код, разобрано в материале про вайб-кодинг и масштабирование проекта.
Что делать специалисту: ориентиры для адаптации
Ориентир первый: формулировать собственное мнение о процессе, а не только воспроизводить чужую практику. Это значит разбираться, почему шаг устроен именно так, какие есть исключения и что ломается при их игнорировании.
Ориентир второй: углубляться в конкретные операции. Одна операция, понятая до уровня исключений и исторических причин, даёт материал для продукта или расширения. Общее знакомство с платформой такого материала не даёт.
Ориентир третий: учиться формулировать требования для ИИ. Чем точнее описаны входные данные, правила и граничные случаи, тем меньше переделок. По навыкам это ближе к написанию спецификации, чем к программированию.
Ограничения стоит проговаривать прямо. Генерация кода без понимания предметной области даёт быстрый черновик и медленную отладку: модель не отвечает за бизнес-логику и не замечает, что требование противоречит регламенту. Полный отказ от ИИ тоже не даёт выигрыша: разбор цены отказа от ИИ показывает, что альтернативой становится ручная сборка того, что конкуренты делают быстрее.
Итог: что меняется на рынке ПО и для специалистов
Снижение стоимости реализации меняет экономику SaaS: часть универсальных сервисов теряет клиентов, потому что ту же функцию дешевле собрать под себя. Одновременно открываются ниши для узких продуктов и расширений поверх крупных платформ.
Сложность корпоративных систем при этом остаётся. Противоречивые правила, интеграции, исторические данные и ответственность за ошибки остаются за человеком, а не переходят к модели.
Конкуренция смещается с целых ERP на отдельные операции и профессиональные подходы. Практический шаг: выбрать одну операцию в своём контуре, сформулировать по ней обоснованное мнение и проверить, закрывается ли она ИИ-инструментами за разумное время. Там, где ответ положительный, появляется либо внутренний сервис, либо продукт на рынок.