Harness вместо сотрудников: как SaaS-компания превращается в обвязку вокруг модели

Штриву Шанкар (Shrivu Shankar) написал в своём блоге утверждение, которое пока мало кто проговаривает вслух: любая SaaS-компания в итоге сама станет harness — обвязкой вокруг модели. Не «внедрит ИИ» и не «поставит агента», а превратится в то, через что этот ИИ работает. Разбираем, что из этого следует.

Что вообще такое harness

С термином сразу путаница, потому что его используют в двух разных смыслах.

Узкий смысл. Harness — это фреймворк вроде LangGraph или кодинг-агент вроде Codex, Claude Code или OpenCode. Всё, что оборачивает API модели, у которого нет ни памяти, ни состояния, в инструмент, с которым реально можно что-то делать.

Широкий смысл — тот, который использует автор. Harness — это вся инфраструктура, интерфейсы, контекст и состояние вокруг stateless LLM. Сама модель от этого не меняется. Меняется всё, что её окружает.

Harness может собираться из нескольких вложенных harness. Тот, который ими управляет, автор называет мета-harness. Отдельный интересный случай — «фабрика»: harness, части которого сами являются маленькими harness. Один пишет спецификации, другой пишет код, третий проверяет. А сверху стоит что-то, что решает, что и когда запускать.

Четыре стадии на пути к этому

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

1. Обычный SaaS. Компания продаёт свою услугу по-старому, инженеры пишут код руками.

Harness нет.

2. Инженер работает вместе с агентом. Инженеры садятся за код в паре с агентом. Постепенно так же работают продукт и продажи — просто чтобы закрыть рутину.

Harness управляют люди.

3. Агенты уезжают в фон. Основные задачи переезжают к фоновым агентам, которые работают в облаке. Десяток таких агентов ноутбук не вытянет. Инженеры, продакт и продажи пишут промпты и проверяют результат.

Harness управляют люди — но теперь ими управляют.

4. Агенты решают сами. Задачи уходят проактивным фоновым агентам. Все отделы переходят к проверке результатов. Регулярные проверки сменяются выборочными: никто не смотрит всё подряд, наоборот, алгоритм сам решает, что стоит показать человеку.

Harness управляют людьми.

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

Что меняется, когда вы дошли до четвёртой стадии

Автор считает, что на этом этапе вы фактически превратили свою компанию в harness. Производство работы перешло от людей к обвязке.

• Продукт — это вывод модели. Основные задачи делают агенты. Компания поставляет контекст, интеграции и интерфейсы, через которые человек смотрит результат.
• Отношения между софтом и структурой компании перевернулись. Теперь вопрос не «кому что подчиняется», а «кого и куда поставить, чтобы обвязка вытащила из человека максимум вкуса и суждения». Люди — часть harness, а не его противоположность.
• Активом компании становятся её внутренние накопления. Знания предметной области, инструменты, права доступа, циклы проверки, контекст — всё это и есть бизнес-harness.

По сути, оргструктура превращается в вопрос логистики: где поставить людей, чтобы они приносили максимум пользы.

«Неужели это фабрика брака?»

Первый и самый естественный вопрос: если всё делает ИИ, качество не просядет?

Такое подозрение, по мнению автора, возникает из-за неверной аналогии. Оно исходит из того, что компания работает по модели lights-out — полностью автономного производства, где человеку не остаётся почти ничего.

Основной ответ: обвязка сама должна решать, где человеческий ввод важнее всего. Вот три примера из статьи.

• Продуктовое решение готовит агент. Он раздаёт вопросы менеджерам по итогам встреч с клиентами, а потом собирает из ответов продуктовую демонстрацию для руководителя продукта.
• Предложение функции, всплывшее на встрече с клиентом, превращается в крупное архитектурное решение, которое агент выносит инженеру со вкусом.
• Редизайн интерфейса стартует после сбора отзывов. Агент тестирует несколько вариантов и показывает лучшие тому, кто отвечает за вкус в дизайне.

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

Скепсис тут уместен. Даже с лучшими моделями и хорошо сделанным harness доверить агентам внешний цикл (это планирование и проверка вокруг самого кода) по-прежнему очень трудно. Автор признаёт: в Nora — своём первом агенте-сотруднике — они потратили на это много времени.

При этом ставить на то, что модели так и не смогут это делать, по-видимому, не стоит. Особенно когда всё больше работы по планированию и проверке разбивается на задачи с проверяемым результатом, на которых лаборатории могут обучать модели — это и есть область RLVR.

Harness становится вашей главной компетенцией

Если обвязка производит продукт и сама его продаёт, то именно она и есть ваша профессия.

Разница между компаниями обычно держится на четырёх вещах: доверии, дистрибуции, эффективности и предметной экспертизе. В мире проактивных фоновых агентов именно способность собрать обвязку и будет тем, что удерживает эту разницу.

Она определяет:

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

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

Это уже начинается

Первый признак — внутренние ИИ-инструменты для разработки у самих компаний. Недавно такие инструменты показывали Ramp, Stripe, DoorDash и другие.

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

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

Автор не ждёт, что всё станет внутренним. Разумная схема: компания владеет верхнеуровневым harness — тем, который решает, что строить, и проверяет, что вернулось, — а готовые вендорские продукты подключает под конкретные задачи. Рано или поздно кто-то снаружи хорошо закрыет отрезок «от спецификации до проверенного pull request». Тогда этот кусок можно заменить чужим решением. Свои агенты, которые пишут входную спецификацию и разбирают результат pull request, остаются при вас.

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

Что ждать дальше

Если эта картина мира верна, стоит готовиться к четырём вещам.

• Стартапы, построенные на ИИ, будут обгонять старых игроков в тех нишах, где защитный ров можно легко перенести в harness.
• Внутренних harness будет строить заметно больше — и на стороне разработки, и на стороне продаж.
• Структура компании и отдельные роли перестроятся под своё место в бизнес-harness. Люди, чья работа сейчас сводится к тому, чтобы раздавать промпты, станут частью обвязки.
• Весь софт, которым компания пользуется, должен работать без интерфейса. Тогда внешний harness сможет им управлять. Речь о софте на путях сборки и продажи.

Подробнее о том, как может выглядеть компания из людей-носителей вкуса, — в статье The Transposed Organization. Эта статья во многом опирается на идеи, изложенные там.