Вопрос ИТ-компаний сменился. Ещё недавно он звучал как «как нам внедрить нейросети», теперь звучит иначе: «как нам выжить, когда нейросети есть у всех». Именно такой сдвиг формулирует автор разбора на Хабре.
Причина простая и неприятная. Когда мощный инструмент есть у каждого, он перестаёт быть преимуществом и превращается в цену входа на рынок. Это не значит, что ИИ стал бесполезен. Кодогенерация, разбор логов, черновики тестов, поиск по незнакомой кодовой базе: всё это работает и экономит часы. Перестало работать другое. Раньше сам факт, что у вас есть LLM-агент, был строчкой в коммерческом предложении. Теперь такая строчка есть у всех, и клиент её даже не читает.
Отсюда практический вопрос: где держать ценность, если модель доступна любому вашему конкуренту по той же подписке? Дальше четыре направления, которые устойчивы к всеобщей доступности нейросетей: собственная обвязка вокруг модели (harness), отлаженный годами код, узкоспециализированные модели на своих данных и критичный софт с высокой ценой ошибки. Плюс два системных следствия, которые меняют правила игры: сокращение открытости отрасли и утечка данных через чужие API.
Что такое harness: обвязка вокруг языковой модели
Harness - это вся обвязка вокруг языковой модели, которая превращает её из функции «текст на входе, текст на выходе» в систему, способную работать. Определение короткое, объём работы за ним огромный.
Полезно начать с того, чего модель не умеет сама. Она не выполняет код, не ходит в интернет, не помнит, что было десять шагов назад, и не останавливается вовремя. Ни одна из этих способностей не появляется от размера модели. Всё это обеспечивает harness.
Из чего состоит harness: инструменты, цикл, граф, правила
- Подключение инструментов. Модель получает описания доступных действий, а код решает, что реально исполнить: чтение файла, запрос к базе, вызов внутреннего API, создание тикета.
- Цикл «действие, проверка, исправление». Агент делает шаг, результат проверяется тестами, линтером, схемой или человеком, и только после проверки начинается следующий шаг.
- Сборка вызовов в граф. Отдельные обращения к модели связываются в управляемую последовательность с ветвлениями, повторами и точками выхода.
- Подстановка промптов и правил. Что агенту разрешено, что запрещено, какой формат ответа ожидается, куда смотреть в первую очередь.
- Ограничение радиуса поражения. Что именно сломается, если агент начнёт галлюцинировать: песочница, права только на чтение, лимит на изменяемые файлы, обязательный ревью перед мержем.
Пример из разработки: кодовый агент в IDE берёт тикет и правит проект. Модель предлагает дифф, а harness решает, какие файлы ему открыть, как прогнать тесты, когда откатить изменения и когда остановиться. Второй пример: бот поддержки сам добирается до нужной записи в базе. Здесь harness - это доступы, лимиты и проверка, что бот не вытащит чужой аккаунт. Третий: «ИИ-сотрудник» на сайте банка. Разница между удачным и провальным внедрением почти никогда не в том, какая модель стоит под капотом.
С этой точки зрения полезна статья о том, почему разработка с ИИ-агентами стала тяжелее, а не легче: код подешевел, а проверка результата подорожала, и значительная часть harness уходит именно на проверку.
Почему модель почти всегда чужая, а своя - только логика вокруг неё
Свои языковые модели есть у нескольких бигтехов и горстки компаний, которым инвесторы разрешили сжечь миллиарды. Все остальные работают с чужими моделями по API. Обучение с нуля стоит столько, что для типовой ИТ-компании этот разговор даже не начинается: дешевле взять подписку или платить за токены.
Отсюда неприятный, но честный вывод. У типовой ИТ-компании своей бывает только обвязка. Кодовый агент в IDE, бот поддержки, «ИИ-сотрудник» на сайте банка: внутри почти всегда одна и та же чужая модель. Некоторые идут дальше и строят агентов поверх чужих агентов, получается «надагент», но механика та же: модель чужая, логика вокруг неё своя.
Это не приговор. Это рамка, в которой нужно искать преимущество. Если ваша модель доступна всем, защищаться придётся не весами, а тем слоем, который вендор не отдаёт из коробки, и данными, которых у вендора нет.
Гонка обёрток: почему конкурировать качеством harness можно лишь на беговой дорожке, которая едет назад
Вендоры моделей помимо самих весов достраивают собственный harness: выпускают своих агентов, расширяют набор встроенных инструментов, перенимают удачные приёмы. Эта механика описана в том же разборе.
Отбор у вендора идёт просто: если приём стабильно помогает большинству пользователей, он попадает в продукт. Вендору это стоит копейки по сравнению с обучением модели, а пользователям даёт ощутимое удобство. Так исчезает целый класс платных прослоек.
Историческая аналогия оттуда же: платформы всегда забирали лучшие фичи слоя над собой. То, что вчера продавалось отдельным продуктом, завтра оказывалось бесплатной галочкой.
Итог для команды: хорошие промпты, схемы loop-инжиниринга, граф-инжиниринг и целые наборы скиллов, то есть всё, что сегодня считается кастомной разработкой, через какое-то время становится строчкой в changelog чужого релиза. Формулировка «беговая дорожка, которая едет назад» звучит резко, но описывает ситуацию точно: бежать надо быстро, чтобы просто оставаться на месте. Это авторская оценка, а не измеряемый факт.
Что именно вендоры забирают в свои продукты
Категории, которые рискуют превратиться во встроенную функцию:
- промпты и системные инструкции, отработанные на реальных задачах;
- схемы loop-инжиниринга: сколько шагов делать, когда повторять, когда останавливаться;
- граф-инжиниринг: разбиение задачи на управляемые узлы с проверками между ними;
- наборы скиллов и заготовок под типовые сценарии;
- набор встроенных инструментов: поиск, работа с файлами, вызовы внешних сервисов.
Речь о наблюдаемой механике, а не о конкретных анонсах и слухах. Точные сроки, когда тот или иной приём переедет в продукт вендора, не знает никто.
Отдельный риск, который стоит держать в голове: чем сильнее ваша логика завязана на конкретный продукт, тем дороже переезд. Как устроена зависимость от вендора в AI-редакторах кода и что именно ломается при недоступности облака, разобрано в материале про устойчивость AI-редакторов к архитектуре и зависимости от вендора.
Что это значит для стратегии команды
Harness нужен как гигиена: без него агент не работает предсказуемо, а быстрые эксперименты превращаются в ручной труд. Но вкладываться в него как в основной ров рискованно: то, что вы построили за месяцы, вендор может отдать бесплатно.
Оговорка важна: баланс разный для разных типов компаний. Если вы продаёте инструмент разработчикам и живёте скоростью выпуска фич, гонка обёрток может быть рабочей моделью, просто с высокой скоростью бега. Если у вас есть собственные данные и критичные процессы, логичнее вкладываться туда, что вендор не заберёт: отлаженный код, свои датасеты, критичный софт.
Отлаженный годами код: почему легаси сложно воспроизвести генеративному ИИ
В исходном разборе эта часть только обозначена, конкретных замеров, насколько хуже модели воспроизводят старый код, там нет. Дальше логика, а не измеренный факт.
Есть категория активов, которую генеративный ИИ воспроизводит с трудом, и это код, отлаженный годами. Причина не в том, что модель не умеет писать код. Она умеет, и часто вполне сносно. Проблема в контексте, который в этот код вшит.
Что накапливается в легаси за пять, десять, двадцать лет:
- обходы багов в чужих библиотеках, про которые не написано ни одной статьи;
- неочевидные решения, принятые под давлением конкретного инцидента и оставшиеся комментарием из трёх слов;
- неявные бизнес-правила, нигде не задокументированные, но определяющие расчёты;
- знание о том, как система ведёт себя в продакшене под реальной нагрузкой, и почему часть кода намеренно неоптимальна.
Ничего этого в открытом корпусе текстов нет. Модель видит diff и файл, но не видит историю решений. Сгенерировать новый модуль с нуля обычно дешевле, чем восстановить смысл существующего.
Практический вывод: легаси с долгой историей, интеграциями с внешними системами и неявными правилами остаётся ценным активом. Переписывать его «на свежем ИИ» стоит только тогда, когда вы понимаете накопленные ограничения и готовы их перенести. Иначе теряется та самая накопленная отладка.
Узкоспециализированные дообученные модели на собственных данных
Универсальная модель по API хороша на общих задачах. На узкой предметной области она часто уступает модели, дообученной на ваших данных, потому что у вендора этих данных нет и не будет.
Логика экономическая. Данные, на которых вы дообучаете, принадлежат вам. Их нельзя скопировать из вашего репозитория, выгрузки из CRM или архива обращений. Пока этих данных нет у конкурента, преимущество держится.
Ограничения, о которых нужно сказать прямо:
- нужен объём и качество данных: дообучение на паре сотен примеров даёт нестабильный результат;
- нужны ресурсы: GPU, время, специалисты, умеющие готовить датасеты и оценивать качество;
- нужна поддержка: модель придётся переобучать при изменении данных и перепроверять при выходе новой базовой версии;
- часто это избыточно: для множества задач хватает хороших промптов и RAG поверх корпоративной базы.
Рамка выбора: если задача узкая, повторяемая, а данные уникальны и уже размечены, дообучение оправдано. Если задача меняется каждую неделю, дешевле остаться на API с RAG. Конкретные бенчмарки тут не помогут, потому что качество определяется вашим датасетом, а не средней температурой по рынку.
Критичный софт с высокой ценой ошибки
Там, где цена ошибки высока, автономность агента ограничена, а требования к предсказуемости выше. Это делает критичный софт устойчиво ценным: заменить его генерацией нельзя, потому что никто не подпишется на непредсказуемость в расчётах, платежах или управлении инфраструктурой.
Области, где это заметнее всего: финансы, медицина, промышленная и сетевая инфраструктура, безопасность. Признак один: ошибка стоит дороже, чем скорость работы.
Здесь harness перестаёт быть абстракцией. Ограничение радиуса поражения превращается в обязательное требование: агент читает и предлагает, а изменение проходит через ревью, тесты и откат. В таких системах ИИ дополняет существующий софт, а не подменяет его.
Два следствия: сокращение открытости отрасли и риск утечки данных через API
Первое следствие: отрасль становится менее открытой. Опубликованные знания, статьи, разборы, схемы и открытый код уходят в обучающие корпуса моделей. Если ваша экспертиза, выложенная в блог, завтра работает против вас в чужом продукте, мотивация публиковать снижается. Разбор обозначает эту связь, но без примеров и метрик, так что это скорее направление тренда, чем измеренный сдвиг.
Второе следствие практичнее. Данные, отправленные в чужой API, покидают ваш периметр. Речь не о том, что вендор обязательно обучается на ваших запросах, а о риске: чем больше чувствительного уходит наружу, тем больше поверхность утечки и тем меньше вы контролируете, где эти данные окажутся через год.
Почему локальные модели - логичный ответ для чувствительных задач
Локальный запуск закрывает главную проблему: данные не покидают вашу инфраструктуру. Это логичный ответ для медицинских записей, персональных данных, финансовой отчётности и внутренних документов, которые нельзя выносить за периметр.
Цена решения тоже понятна: нужны GPU и VRAM, поддержка, регулярное обновление весов, а качество открытой модели на вашем железе может уступать топовым облачным вариантам. Для части чувствительных задач это приемлемо, для части нет.
Как выбирать между локальным контуром, открытыми весами, RAG и гибридной схемой, разобрано в статье про AI-суверенитет и контроль над моделями, данными и вычислениями. Там же есть чек-лист выбора AI-стека, который помогает не уйти в крайности.
Отдельный аргумент в пользу локального контура - экономический. Если объёмы запросов растут, а данные чувствительны, локальная модель перестаёт быть идеологической позицией и становится обычным расчётом. Почему в 2026 году пользователи всё чаще отказываются от облачных подписок в пользу своих моделей, разбирается в материале про тренд на локальные AI-модели.
Что делать: куда вкладываться, когда нейросети есть у всех
Пять направлений, которые выдерживают проверку временем:
- Harness держать как гигиену. Он нужен, чтобы агент работал предсказуемо и чтобы гипотезы проверялись за дни, а не за месяцы. Как основной ров он не работает.
- Отлаженный код ценить. Не спешить переписывать легаси с долгой историей и неявными правилами: сначала разберитесь, какие ограничения в нём зашиты.
- Свои данные и дообучение. Вкладываться там, где есть уникальные размеченные данные и узкая повторяемая задача. Если данных мало или задача плывёт, оставайтесь на API с RAG.
- Критичный софт усиливать. ИИ дополняет такие системы советом и проверкой, а решение и откат остаются за людьми и процессом.
- Локальные модели рассматривать для чувствительных задач. Там, где утечка неприемлема, свой контур оправдан, даже если качество на шаг ниже облачного.
Чек-лист вопросов для своей команды:
- Если конкурент завтра купит ту же подписку, что у нас останется?
- Какой объём работы уходит на проверку результата агента и кто её делает?
- Какие данные мы уже отправляем в чужие API и можно ли это прекратить без потери качества?
- Есть ли у нас данные, которых нет у вендора, и размечены ли они?
- Что произойдёт, если агент ошибётся в нашей самой критичной системе?
Конкретное действие простое: возьмите одну задачу, где у вас есть либо уникальные данные, либо высокая цена ошибки, и вложите ресурсы именно туда. Harness при этом остаётся на месте, только в другой роли: не как крепостная стена, а как способ быстро проверить, стоит ли строить стену вообще.