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

Palo Alto вранці, кава тільки-но подана, Алан Уокер опустив голову і натрапив на статтю про harness від Anthropic, підняв голову і лише сказав:

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

Ця стаття на поверхні говорить про інженерний дизайн, говорить про planner, generator, evaluator, говорить про те, як змусити Claude працювати кілька годин безперервно, створюючи складніші продукти.

Більшість людей на цьому зупиняються. Вони вважають:

О, виявляється, агент став більш складним, prompt став довшим, робочий процес став детальнішим.

Але Алан каже, що насправді варто дивитися не на поверхневі функції, а на те, куди переміщається влада.

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

Зараз Anthropic не намагається зробити модель більш схожою на розумного працівника, а починає передавати всю систему, що належить людям, на рівень організаційної влади, наглядової влади і прийняття.

Harness - це не плагін. Harness - це машина, яка починає виростати в “управлінський рівень”.

Ось де насправді знаходиться його жахливість.

01 Це не інструмент, а “управлінський рівень”

Багато людей, побачивши harness, спочатку реагують: це ж просто ще одна агентська структура?

Це розуміння занадто поверхневе.

Суть звичайного інструмента полягає в тому, щоб виконувати команди. Ви натискаєте, і він діє. Ви не говорите, він не рухається.

Але harness вже не підпорядковується цій логіці. Він насправді робить так, що структурна розподіл, яка раніше була прихована в людських командах, стає програмним забезпеченням:

Хто розуміє вимоги, хто розбиває їх на етапи, хто виконує, хто перевіряє, хто має право повернути на доопрацювання після виявлення проблеми.

Іншими словами, Anthropic не просто додає більше функцій, а переписує саму суть організації роботи в систему.

Чому це важливо? Тому що найскладніше в минулому не було копіювати окремі навички, а організаційні здібності.

Багато людей вміють писати код.

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

А harness звертається саме до цього найдорожчого аспекту.

Інструменти підвищують ефективність, організація визначає результати.

Одинокий модель лише робоча сила, Harness починає торкатися структури компанії.

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

02 Це не розумніше, а менш імовірно, що все зірветься

Найзаплутаніший аспект моделі полягає в тому, що вона завжди виглядає досить розумною в коротких завданнях.

Запитайте її питання, вона відповідає логічно; попросіть її написати код, і вона часто виглядає цілком гідно. Тому багато людей помилково вважають: якщо короткі завдання вона може виконати, довгі завдання не більш ніж продовжити.

Це зовсім не так.

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

Люди також стикаються з цим, працюючи над проектами. Найстрашніше не те, що ви не можете це зробити, а те, що в кінці все починає плутатися:

Вимоги стають неясними,

Цілі стають розмитими,

Логіка втрачає послідовність,

Врешті-решт, найбільшою спеціалізацією стає написання звіту, який виглядає так, ніби все завершено.

Основна проблема, згадана в статті Anthropic, полягає в тому:

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

Цінність Harness полягає не в тому, щоб зробити його більш гнучким, а в тому, щоб не дозволити йому бути таким розсіяним, таким невагомим і таким легким для обману.

Розбиття на етапи, передача, укладення контракту, незалежна оцінка, повернення у разі невдачі - все це, здавалося б, деталі процесу, насправді вирішує одну й ту ж базову проблему:

Розуміння може бути нестабільним, але поставки не можуть покладатися на удачу.

Тому, щоб справді зрозуміти harness, спочатку потрібно зрозуміти наступне:

В майбутньому справжня цінність полягає не в тому, хто іноді може створити вражаючий демо.

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

Вміти писати - це не дивина.

А от довести до кінця без краху - ось що дійсно дивно.

Осяяння не має великої вартості, стабільна поставка - ось що цінно.

Алан каже, що найхолодніше місце в цій статті Anthropic - це не planner, не generator, а evaluator.

Чому?

Бо великі моделі мають дуже схожий на людський недолік: те, що вони роблять, завжди здається їм прийнятним.

Якщо немає зовнішніх обмежень, вони легко дають оцінку “загалом непогано”, “в основному готово”, “основні функції вже реалізовані”.

Проблема в тому, що така оцінка часто не є брехнею, а є систематичним самообманом.

Чому багато проектів у людських компаніях зрештою провалюються?

Бо ті, хто працює, зазвичай найкраще знаходять виправдання для себе.

Ті, хто робить, кажуть, що вже майже готово,

Ті, хто приймає, не хочуть поглиблюватися,

І так “майже готовий” продукт проходить перевірку і врешті-решт вибухає у руках користувачів.

Anthropic дуже жорстко розділяє цю справу:

Той, хто працює, - це одна роль,

Той, хто перевіряє, - це інша роль.

Перша відповідає за просування, друга - за сумніви.

Логіка за цим дуже глибока:

Якщо права на виробництво та оцінку розділені, система починає формувати справжнє замкнуте коло.

І ще більше лякає те, що Anthropic не просто дозволяє evaluator сказати кілька слів “мені тут щось не подобається”. Вона намагається структурувати “перевірку помилок”:

Функції потрібно тестувати, сторінки натискати, інтерфейси перевіряти, стан бази даних переглядати, якість дизайну також розбивається на оцінювальні параметри.

Що це означає?

Це означає, що багато суджень, які раніше таємничилися людським фактором, починають поступово розбиватися на процеси, стандарти та пороги.

Найперше, що автоматизується, це не фізична праця, а пошук помилок.

Якщо “цей продукт взагалі працює” стає процесом, багато людей, які покладалися на досвід, почнуть втрачати свої позиції.

У минулому багато посад були цінними не через виробництво, а через право говорити “цей продукт можна вважати готовим”.

Зараз ця влада починає поступово виходити з рук людей.

03 Найжорсткіший удар - це не дозволити йому хвалити себе

Алан каже, що найхолодніше місце в цій статті Anthropic - це не planner, не generator, а evaluator.

Чому?

Бо великі моделі мають дуже схожий на людський недолік: те, що вони роблять, завжди здається їм прийнятним.

Якщо немає зовнішніх обмежень, вони легко дають оцінку “загалом непогано”, “в основному готово”, “основні функції вже реалізовані”.

Проблема в тому, що така оцінка часто не є брехнею, а є систематичним самообманом.

Чому багато проектів у людських компаніях зрештою провалюються?

Бо ті, хто працює, зазвичай найкраще знаходять виправдання для себе.

Ті, хто робить, кажуть, що вже майже готово,

Ті, хто приймає, не хочуть поглиблюватися,

І так “майже готовий” продукт проходить перевірку і врешті-решт вибухає у руках користувачів.

Anthropic дуже жорстко розділяє цю справу:

Той, хто працює, - це одна роль,

Той, хто перевіряє, - це інша роль.

Перша відповідає за просування, друга - за сумніви.

Логіка за цим дуже глибока:

Якщо права на виробництво та оцінку розділені, система починає формувати справжнє замкнуте коло.

І ще більше лякає те, що Anthropic не просто дозволяє evaluator сказати кілька слів “мені тут щось не подобається”. Вона намагається структурувати “перевірку помилок”:

Функції потрібно тестувати, сторінки натискати, інтерфейси перевіряти, стан бази даних переглядати, якість дизайну також розбивається на оцінювальні параметри.

Що це означає?

Це означає, що багато суджень, які раніше таємничилися людським фактором, починають поступово розбиватися на процеси, стандарти та пороги.

Найперше, що автоматизується, це не фізична праця, а пошук помилок.

Якщо “цей продукт взагалі працює” стає процесом, багато людей, які покладалися на досвід, почнуть втрачати свої позиції.

У минулому багато посад були цінними не через виробництво, а через право говорити “цей продукт можна вважати готовим”.

Зараз ця влада починає поступово виходити з рук людей.

04 Першими постраждають не програмісти, а “майже готово”

Лише побачивши цю статтю, багато людей автоматично реагують: чи не закінчаться програмісти?

Алан каже, що це питання занадто поверхневе і занадто ліниве.

Першими, хто постраждає від harness, не є певна професія.

Воно спочатку знищить спосіб життя, який існує протягом тривалого часу і дуже поширений у майже всіх знаннєвих роботах:

Вимоги неясні, спочатку працюємо;

Коли щось піде не так, виправимо пізніше;

Результат середній, але працює;

Документація не написана чітко, але команда все розуміє;

Запуск відбувається, а проблеми вирішуються потім.

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

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

Harness робить зовсім інше.

Воно стискає невизначеності.

Воно стискає простір для виправдань.

Воно стискає простір для “я вважаю”, “майже”, “мабуть”.

Спочатку визначте, що означає “завершено”, перш ніж дозволити почати;

Якщо не відповідає вимогам, повертаємо;

Якщо не пройшло перевірку, продовжуємо;

Не потрібно відчуттів, потрібні докази.

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

Harness не знищує програмістів, спочатку знищить невизначеність.

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

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

05 Чому воно стало популярним саме зараз

Багато людей запитують, чому раніше ніхто не робив подібні робочі потоки, чому зараз всі почали серйозно ставитися до цього?

Тому що раніше базова модель була недостатньо сильною.

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

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

Ви створили купу процесів, купу ролей, написали купу правил, а в підсумку просто обгорнули ненадійний модель у більш складну ненадійну систему.

Тому раніше багато людей втрачали терпіння щодо agent, workflow, scaffold.

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

Зараз все по-іншому.

Якщо модель перетинає певний поріг, багато процесів, які раніше виглядали як декорації, вперше починають вивільняти справжню цінність.

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

Ось чому harness зараз раптово виглядає “трохи реально”.

Це не те, що його концепція з’явилася сьогодні, а те, що модель нарешті стала достатньо сильною, щоб скористатися перевагами процесів.

Алан дуже точно сказав:

Модельна здатність - це двигун, Harness - це коробка передач.

Раніше без хорошого двигуна навіть краща коробка передач була б просто прикрасою.

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

Тому ця хвиля не просто технологічна мода, а сигнал про більш глибокі зміни в галузі:

Майбутня конкуренція полягає не лише в тому, хто має кращу модель, а в тому, хто першим інтегрує модель у виробничу систему.

06 “Люди за замовчуванням стоять посередині”

Наприкінці Алан поклав чашку і сказав найхолоднішу фразу того дня:

“Раніше люди стежили за програмним забезпеченням, а тепер програмне забезпечення стежитиме за програмним забезпеченням.”

Чому ця фраза так вражає?

Тому що вона вказує на те, що harness насправді переписує не певну роль, а більш базовий принцип, який раніше майже ніхто не сумнівався:

У цифровій праці за замовчуванням має бути людина, що стоїть посередині.

Вона розбиває завдання,

вона стежить за прогресом,

вона оцінює якість,

вона координує переробки,

вона несе останню відповідальність.

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

Ім’я не важливе.

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

Harness насправді зачіпає саме цю центральну позицію.

Воно не говорить, що сьогодні відразу потрібно вигнати людей, а поступово доводить:

Виявляється, деякі завдання можна виконувати системно,

виявляється, деякий нагляд можна здійснювати системно,

виявляється, деякі перевірки можна виконувати системно,

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

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

З центру за замовчуванням стане виняткове втручання;

з постійного контролю - лише обробка країв;

з господаря процесу - перетворення на спостерігача процесу.

Ось що насправді поглинає harness.

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

Не продакт-менеджерів.

Не QA.

А те, що стоїть за цими ролями:

Люди за замовчуванням є центром процесу.

А коли ця передумова починає розхитуватися, далі історія змінюється.

В епоху інструментів важливо було, хто краще користується інструментами.

В епоху Harness важливо, хто раніше прийме:

він більше не є природно в центрі системи.