Что такое система управления (harness)?

В узком смысле «системой управления» часто называют фреймворки вроде LangGraph или кодирующие агенты наподобие Codex, Claude Code или OpenCode, которые оборачивают stateless LLM API в достаточно инструментов и состояния, чтобы реально получать результаты.

Здесь используется более широкое определение: система управления — это вся инфраструктура, интерфейсы, контекст и состояние, окружающие stateless LLM. Такая система может быть составлена из адаптированных или специализированных подсистем (при этом оркестратор называется «мета-системой управления»). «Программная фабрика» — это система управления, части которой сами являются системами управления: одна пишет спецификации, другая пишет код, третья проверяет результаты, плюс что-то сверху решает, что запускать и когда.

Если принять это более широкое определение, то для множества компаний, занимающихся программными услугами, вероятно, проявится вот такая траектория:

  1. Продают программные услуги, созданные по традиционному SaaS-способу.

    1. Система управления отсутствует.

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

    1. Отдельные люди управляют системами.

  3. Продают программные услуги, многие ключевые задачи переходят на фоновых агентов в облаке (на ноутбуке такое не запустишь). Инженеры, продакты и sales триггерят эти агенты (пишут промпты) и проверяют выход.

    1. Люди оркестрируют системы управления.

  4. Продают программные услуги, многие ключевые задачи выполняют проактивные фоновые агенты, инженеры, продакты и sales в основном проверяют результаты агентов. Постоянные проверки сменяются выборочными. Всё больше агенты сами решают, что делать, вместо того чтобы люди планировали работу заранее.

    1. Системы управления оркестрируют людей.

Четыре этапа эволюции SaaS-компании с системами управления

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

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

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

  • Знание домена компании, её инструменты, полномочия, циклы проверки, контекст — всё это становится бизнес-системой управления.

Звучит как фабрика AI-дерьма

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

Главное средство защиты — система управления должна выбирать, где критична роль человека. Например:

  • Решение о продукте может исходить от агента, который собирает вопросы с репов на встречах с клиентами и синтезирует демо продукта для проверки продакт-лидом

  • Предложение фичи с встречи клиента агент превращает в крупное архитектурное решение, которое показывает человеку, ответственному за вкус, в инжиниринге

  • Редизайн UI начинается с агрегирования обратной связи, и после тестирования нескольких вариантов топ-варианты показывают человеку, ответственному за дизайн-вкус

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

Система управления как интерфейс между автоматизацией и человеческим надзором

Если сомнение всё ещё остаётся — это справедливо. Даже с современными фронтальными моделями и хорошо созданной системой управления, трудно доверить агентам работу с внешним циклом (outer loop) вроде этого. Мы потратили много времени, пытаясь наладить это. Просто не думаю, что стоит ставить на то, что модели не смогут в итоге это сделать, особенно когда всё больше этой работы по планированию и проверке разбивается на задачи с проверяемыми награами, на которых лабы могут учиться.

Чтобы узнать больше о том, как может выглядеть организация из «держателей вкуса», см. The Transposed Organization. Эта статья опирается на идеи из той статьи.

Если системы управления производят и продают продукт, это теперь ваша главная компетенция

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

Система управления теперь определяет, что должно быть истинным, чтобы работа была готова к доставке (~доверие), как быстро и как продукты приземлятся (~распределение), скорость и контекст циклов обратной связи (~эффективность) и как институциональное знание впитывается и поддерживается (~контекст домена).

Системы управления переходят от внутреннего инструмента, который вы рады купить, к чему-то, что вы так же не отдали бы на аутсорс, как свой отдел product-eng или GTM-команду. Это явно отличается от мира до AI, где выходы были в основном ограничены людьми, использующими ПО для выполнения работы.

Это уже начинает происходить

Внутренние AI-инструменты для разработчиков (вроде тех, что мы видели от Ramp, Stripe, DoorDash и других) — это начало этого.

Примеры компаний, разработавших внутренние системы управления

Для AI-увлечённых компаний ожидание, пока поставщик SDLC-инструментов добавит интеграцию, поддержит определённый интерфейс или достигнет уровня экономической целесообразности, всё больше становится узким местом их способности строить и поддерживать продукт. Это особенно верно в краткосрочном периоде для сторонних инструментов, которые пока не могут запустить всю программную фабрику компании целиком (часто потому, что стек слишком специфичен, governance слишком ограничен, поддержка критичных фич слишком медленная или из-за предпочтённой модели затрат).

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

Если каким-то образом весь внешний цикл может быть выполнен сторонней системой управления (то есть, запуск всего бизнеса через проактивные фоновые агенты как сервис), тогда я бы поспорил, что бизнес теперь был commoditized.

Итак, что?

Если это правильная ментальная модель, следует ожидать:

  • Необычно большое количество построения внутренних систем управления как на стороне разработки, так и на стороне продаж

  • Оргструктуры и отдельные роли, переделанные вокруг их места в бизнес-системе управления

  • AI-нейтивные стартапы, бьющие инкамбентов в доменах, где «ров» легко может быть перестроен в систему управления

  • Всё ПО, которое компания использует (на критичных путях сборки или продаж или связанное с ними), должно быть headless, чтобы внешняя система управления могла запустить его