Harness стал популярным — но люди так и не поняли, кого он на самом деле собирается поглотить

Palo Alto утром, кофе только что принесли, Алан Уокер наклонился и прочитал статью о harness от Anthropic, поднял голову и сказал всего одно:

“Многие думают, что это модель немного улучшилась. Ошибка, это процесс начинает предавать человека.”

Эта статья на поверхности говорит об инженерном дизайне, о планировщике, генераторе, оценщике, о том, как заставить Claude работать несколько часов подряд, создавать более сложные продукты.

Большинство людей на этом останавливаются. Они подумают:

О, оказывается, агент стал сложнее, prompt стал длиннее, рабочий процесс стал более детализированным.

Но Алан говорит, что на самом деле стоит смотреть не на поверхностные функции, а на то, куда перемещается власть.

Ранее, чтобы выполнить сложную задачу, нужно было, чтобы кто-то разбирал требования, кто-то исполнял, кто-то проверял, кто-то переделывал, кто-то подстраховывал.

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

Harness не является дополнением. Harness — это когда машина начинает вырастать “управляющий уровень”.

Вот в чем на самом деле его пугающая суть.

01 Не инструмент, а «уровень, управляющий инструментом»

Когда многие видят harness, первая реакция: разве это не просто еще один фреймворк для агентов?

Это понимание слишком поверхностное.

Суть обычного инструмента заключается в том, чтобы подчиняться командам и выполнять их. Вы нажимаете, оно делает. Если вы не говорите, оно не двигается.

Но harness уже не подчиняется этой логике. То, что он на самом деле делает, это программирует уровень разделения труда, который раньше скрывался в человеческих командах:

Кто будет понимать требования, кто разобьет на стадии, кто будет исполнять, кто будет проверять, кто будет иметь право вернуть на доработку после обнаружения проблемы.

То есть, Anthropic не добавляет больше функций, а записывает сам процесс “как организовать работу” в систему.

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

Много людей умеют писать код.

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

А harness как раз касается этой самой ценной части.

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

Отдельная модель — это просто рабочая сила, Harness начинает касаться структуры компании.

Когда AI не просто умеет работать, но также начинает разделять задачи, передавать их и нести ответственность, это уже не просто “обновление инструмента”.

02 Не умнее, а менее подвержен провалу

Самое запутывающее в модели — это то, что она всегда кажется очень умной в коротких задачах.

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

Совсем не так.

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

С людьми в проектах происходит то же самое. Самое страшное не в том, что они не могут, а в том, что к концу все начинает путаться:

Требования забываются,

Цели начинают расплываться,

Логика становится несогласованной,

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

Ключевая проблема, о которой говорилось в статье Anthropic, по сути именно в этом:

Модель постепенно теряет фокус в долгосрочных задачах. Чем длиннее контекст, тем более запутанным становится состояние, тем легче попасть в иллюзию “все почти готово”.

Ценность Harness не в том, чтобы сделать её более ловкой, а в том, чтобы сделать её менее рассеянной, менее абстрактной, менее легкой для обмана.

Разделение на стадии, передача задач, установление контрактов, независимая оценка, откат при неудаче — все эти кажущиеся деталями процесса на самом деле решают одну и ту же основную проблему:

Интеллект может быть нестабильным, но доставка не должна зависеть от удачи.

Так что, чтобы действительно понять harness, нужно сначала осознать одну вещь:

Будущее, действительно ценное, это не тот, кто время от времени может показать впечатляющий демо.

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

Уметь писать — не удивительно.

Достигнуть конца, не обрушившись, — вот что удивительно.

Вдруге не стоит ничего, стабильная доставка стоит.

Алан говорит, что самое холодное в статье Anthropic — это не планировщик и не генератор, а оценщик.

Почему?

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

Пока нет внешних ограничений, они легко дают самооценку “в целом неплохо”, “основное завершено”, “ключевая функция уже имеется”.

Проблема в том, что такая оценка часто не является ложью, а представляет собой систематическую самообман.

Почему многие проекты в человеческих компаниях в итоге терпят провал?

Потому что работающие чаще всего находят себе оправдания.

Те, кто делают, говорят, что уже почти закончили,

Те, кто проверяют, не хотят углубляться,

Таким образом, “почти готовый” продукт проходит все этапы и в итоге взрывается в руках пользователей.

Жесткая позиция Anthropic заключается в том, что они разделяют этот процесс:

Работающий — это одна роль,

Ошибка — это другая роль.

Первый отвечает за продвижение, второй — за сомнение.

Логика здесь очень глубокая:

Как только права на производство и права на оценку разделяются, система начинает действительно формировать замкнутый цикл.

Более того, что еще более страшно, Anthropic не просто позволяет оценщику сказать несколько раз “я думаю, что здесь не так”. Они структурируют процесс “поиска ошибок”:

Функции нужно тестировать, страницы нужно щелкать, интерфейсы нужно проверять, состояние базы данных нужно просматривать, качество дизайна также разбивается на оцениваемые параметры.

Что это означает?

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

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

Как только вопрос “это действительно работает?” становится процессуализированным, многие защитные механизмы опыта начинают давать сбои.

Многие позиции в прошлом были действительно ценными не потому, что они могли производить, а потому, что имели право сказать, “это считается готовым или нет”.

Сейчас эта власть начинает ослабевать из рук людей.

03 Самая жесткая позиция — это не позволять себе хвалить себя

Алан говорит, что самое холодное в статье Anthropic — это не планировщик и не генератор, а оценщик.

Почему?

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

Пока нет внешних ограничений, они легко дают самооценку “в целом неплохо”, “основное завершено”, “ключевая функция уже имеется”.

Проблема в том, что такая оценка часто не является ложью, а представляет собой систематическую самообман.

Почему многие проекты в человеческих компаниях в итоге терпят провал?

Потому что работающие чаще всего находят себе оправдания.

Те, кто делают, говорят, что уже почти закончили,

Те, кто проверяют, не хотят углубляться,

Таким образом, “почти готовый” продукт проходит все этапы и в итоге взрывается в руках пользователей.

Жесткая позиция Anthropic заключается в том, что они разделяют этот процесс:

Работающий — это одна роль,

Ошибка — это другая роль.

Первый отвечает за продвижение, второй — за сомнение.

Логика здесь очень глубокая:

Как только права на производство и права на оценку разделяются, система начинает действительно формировать замкнутый цикл.

Более того, что еще более страшно, Anthropic не просто позволяет оценщику сказать несколько раз “я думаю, что здесь не так”. Они структурируют процесс “поиска ошибок”:

Функции нужно тестировать, страницы нужно щелкать, интерфейсы нужно проверять, состояние базы данных нужно просматривать, качество дизайна также разбивается на оцениваемые параметры.

Что это означает?

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

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

Как только вопрос “это действительно работает?” становится процессуализированным, многие защитные механизмы опыта начинают давать сбои.

Многие позиции в прошлом были действительно ценными не потому, что они могли производить, а потому, что имели право сказать, “это считается готовым или нет”.

Сейчас эта власть начинает ослабевать из рук людей.

04 Первые, кого съедают, не программисты, а “пойдет”

Как только люди видят такую статью, многие рефлекторно спрашивают: программисты, наверное, потеряют работу?

Алан говорит, что такой вопрос слишком поверхностный и ленивый.

Первая волна, которую поглотит harness, — это не какая-то профессия.

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

Требования неясны, сначала делаем;

По дороге делаем не так, позже исправляем;

Результат средний, но работает;

Документация неясна, но в команде все понимают;

Сначала запускаем, потом исправляем проблемы.

Проще говоря, это целый набор рабочих практик, основанных на неопределенности и человеческой гибкости.

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

Но то, что делает Harness, как раз противоположно.

Он сужает пространство неопределенности.

Он сужает пространство для оправданий.

Он сужает пространство для выживания на основе “я думал”, “почти”, “должно сработать”.

Сначала определите, что значит “готово”, затем разрешите начать работу;

Если не удовлетворяет, верните;

Если не прошел проверку, продолжайте;

Не нужно ощущений, нужны доказательства.

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

Harness не поглощает программистов, сначала поглощается неопределенность.

Не каждый будет заменен, но каждая позиция, зависящая от неопределенности, будет сначала обесценена.

Ранее многие профессии существовали благодаря информационному разрыву, в будущем многие профессии погибнут из-за стандартного отклонения.

05 Почему она стала популярна именно сейчас

Многие спрашивают, почему такие рабочие процессы раньше тоже существовали, а сейчас вдруг все начали серьезно относиться?

Потому что раньше базовая модель была недостаточно сильной.

Скажем прямо:

Ранее многие такие фреймворки выглядели красиво, но работали громоздко, в результате чего оказывались недостаточно надежными.

Вы настраивали кучу процессов, создавали кучу ролей, писали кучу правил, в итоге просто упаковывали ненадежную модель в более сложную и ненадежную систему.

Таким образом, многие люди естественно теряли терпение к агентам, рабочим процессам, каркасам.

Не потому, что направление неверное, а потому что платформа не достигла этого уровня.

Сейчас все иначе.

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

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

Вот почему harness сейчас вдруг кажется “немного реальным”.

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

Алан точно подметил:

Способности модели — это двигатель, Harness — это трансмиссия.

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

Но когда двигатель уже достаточно силен, трансмиссия начинает определять, кто может выехать на高速, а кто все еще сидит на месте, жмя на педаль.

Таким образом, это не просто технологическая модификация, а сигнал от отрасли:

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

06 “Человек подразумевается в центре”

В конце концов, Алан поставил чашку и сказал самое холодное из всего, что он сказал в тот день:

“Ранее человек следил за работой программного обеспечения, а теперь программное обеспечение следит за работой программного обеспечения.”

Почему эта фраза так бьет по сердцу?

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

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

Он разбирает задачи,

он следит за прогрессом,

он оценивает качество,

он координирует доработки,

он выстраивает финальную защиту.

Этот “человек, подразумевающийся в центре”, может быть программистом, может быть PM, может быть TL, может быть ответственным за дизайн, может быть QA, а может быть проектным менеджером.

Имена не важны.

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

То, что действительно трогает в harness, — это именно эта центральная позиция.

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

Оказывается, некоторые процессы можно выполнять системно,

Оказывается, некоторый надзор можно осуществлять системно,

Оказывается, некоторую приемку можно делать системно,

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

Когда это становится все более очевидным, позиция человека не исчезнет сразу, но начнет углубляться.

Из подразумеваемого центра она превратится в исключение;

С полного контроля она станет лишь обработкой крайних вопросов;

Из хозяина процесса она станет наблюдателем процесса.

Вот что на самом деле поглощает harness.

Не программистов.

Не менеджеров по продукту.

Не QA.

А за этими ролями стоит более глубокое предположение:

Человек по умолчанию находится в центре процесса.

И как только эта предпосылка начинает ослабевать, вся остальная история меняется.

В эпоху инструментов сравнивают, кто лучше использует инструменты.

В эпоху Harness сравнивают, кто быстрее принимает:

что он больше не находится в центре системы по умолчанию.