Чому вам потрібно вивчати Інженерію підключень? Повний аналіз 5 продуктів, 3 шкіл та 5 універсальних принципів

система розбору Harness Engineering 5 продуктів, 3 школи (OpenAI / Anthropic / ThoughtWorks), 5 універсальних принципів, і чому «Занепад Harness» змушує вас кожні 6 місяців відрізати половину дизайну. Ця стаття походить з X-статті @sairahul1, зібрана та перекладена Dynamic Zone.
(Попередній огляд: Вступ до Harness Engineering (AI-управління інженерією): Новий стандарт програмування OpenAI, що допоможе легко досягти Lv.1)
(Додатковий фон: Генеральний директор YC ділиться секретами AI: Майбутнє належить тим, хто зможе побудувати системи інформативного складного відсотка)

Зміст статті

Перемикач

    1. Визначення Harness
    1. Метафора ОС
    1. Що саме змінилося в 2026 році
    1. Файли AGENT.md / CLAUDE.md
    1. JSON Feature Lists (система відстеження прогресу)
    • Чому саме JSON, а не Markdown?
    1. Стандарт ініціалізації сесії
    1. Контракти спринту (Sprint Contracts)
    • Чому це важливо
    1. Структуровані шаблони задач (Structured Task Templates)
    1. Школа OpenAI: пріоритет навколишнього середовища
    • Їхній підхід
    • Докази
    1. Школа Anthropic: розділення «роботи» і «оцінки»
    • Їхнє рішення: 3 спеціалізовані агенті
    • Результати (A/B тестування)
    1. Школа ThoughtWorks: матриця 2×2
    • Їхній інсайт: класифікація контролю harness за двома осями
    • Матриця 2×2
    1. Принцип 1: Контекст важливіший за інструкцію
    1. Принцип 2: Планування і виконання мають бути розділені
    1. Принцип 3: Цикл зворотного зв’язку — незамінний
    1. Принцип 4: Робити можна лише одну річ за раз
    1. Принцип 5: Кодова база сама є документом
    • Практичне значення
    1. Занепад Harness (Harness Decay) — це реально
    • Це і є занепад Harness
    1. Створення для видалення (Build to Delete)
    1. Реальність витрат
    • Але тут говорять про те, що зазвичай не обговорюють
  • Повний виклад
    • Що таке harness
    • 5 продуктів harness
    • 3 школи
    • 5 універсальних принципів
    • парадоксальні моменти

У лютому 2026 року, команда OpenAI створила 1 мільйон рядків виробничого коду.

Вони не писали жодного рядка вручну.

Це писали агенти AI.

Людський дизайн — це система, яка робить агентів надійними.

Цю систему тепер називають — Harness Engineering.

За кілька тижнів Anthropic опублікувала 3 релевантні статті. ThoughtWorks систематизувала її у рамки. Philipp Schmid з Hugging Face прямо назвав її «найважливішою дисципліною 2026 року».

За 90 днів з’явилася нова інженерна галузь. І поза командою AI infra майже ніхто не зрозумів.

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

1. Визначення Harness

Найпростіше визначення від ThoughtWorks:

Агент = Модель + Harness

Harness — це все, що окрім моделі.

  • Обмеження, що тримають агента на правильному шляху
  • Зворотний зв’язок для виявлення помилок
  • Документи, що вказують агенту, де він знаходиться
  • Інструменти, якими він може користуватися

Зняти harness → залишиться сирий мовний модель, що «вгадує» у вашому коді.

Додати правильний harness → отримати систему, здатну генерувати виробничий код.

Це слово походить від упряжі. Harness — це вуздечка, сідло, упряж — спрямовує сильну, але непередбачувану силу тварини у корисний напрям.

Ви не робите тварину розумнішою, ви створюєте обладнання, що робить її силу корисною.

2. Метафора ОС

Найкраща технічна метафора від Philipp Schmid: уявіть це як комп’ютер.

| Роль | | --- | | Модель | Центральний процесор (потужність) | | Контекстне вікно | ОЗП (обмежена, швидко вичерпна робоча пам’ять) | | Harness | ОС (керує тим, що і коли бачить CPU) | | Агент | Застосунок, що працює зверху |

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

Більшість працює «без операційної системи». Тому їхні агенти виходять з ладу на виробництві.

3. Що саме змінилося в 2026 році

LangChain використовує ту саму модель і запускає її двічі на Terminal Bench 2.0:

| Harness | | --- | Оцінка | | --- | --- | | Старий harness | 52.8% | | Новий harness | 66.5% |

Та сама модель. Різний harness. Різниця 13.7 процентних пунктів.

Vercel навпаки — зменшила кількість інструментів агента на 80%. Результат? Краще, а не гірше.

Найбільш неприємна правда 2026 року:

  • Агент ніколи не був складною частиною
  • Harness — це саме воно

Якщо 2025 — рік, коли AI агент довів, що може писати код, то 2026 — рік, коли відкрили, що «оточення» важливіше за «модель».

4. Файл AGENT.md / CLAUDE.md

Найзагальніший продукт harness.

Розкидані по всьому кодовому базі markdown-файли. Агент кожного разу починає сесію з їхнього читання — як onboarding для нового співробітника.

Що в них?

  • Контекст проекту
  • Стандарти коду
  • Архітектурні рішення
  • Інструкції «як ми тут працюємо»
  • Поточні задачі

OpenAI називає це AGENT.md. Anthropic — CLAUDE.md. Cursor — .cursorrules.

Різні назви, однаковий принцип. Кожен основний модуль — окремий файл. Оновлюється з розвитком проекту.

Без нього: агент кожного разу — сліпий запуск. З ним: агент кожного разу — з інформацією.

5. JSON Feature Lists (система відстеження прогресу)

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

Файл JSON.

Кожен запис — це:

  • Одна функція
  • Як перевірити її виконання
  • Статус Pass / Fail

Агент читає його на початку сесії — вибирає найвищий пріоритет Fail → реалізує → позначає Pass → комітить → повторює.

Чому саме JSON, а не Markdown?

Anthropic виявила: ймовірність перезапису JSON агентом нижча, ніж Markdown.

Дрібниці, але у сценарії автономної роботи 6 годин — це критично.

6. Стандарт ініціалізації сесії

Кожна сесія починається однаково. Обов’язково.

7-кроковий процес запуску Anthropic:

  1. Перевірка робочого каталогу
  2. Читання git log і файлів прогресу
  3. Вибір найпріоритетнішого незавершеного з feature list
  4. Запуск dev-сервера
  5. Запуск базової E2E перевірки
  6. Реалізація функції
  7. Коміт з описовим повідомленням і оновлення прогресу

Без цього: перші 20 хвилин агент намагається з’ясувати поточний стан, повторює одне й те саме. З ним: агент одразу працює з інформацією.

7. Контракти спринту (Sprint Contracts)

Перед написанням будь-якого рядка коду — дві агенти спершу домовляються.

Агент-генератор пропонує:

  • Що робити
  • Як перевірити успіх

Агент-оцінювач перевіряє:

  • Чи повна пропозиція?
  • Чи чіткі критерії успіху?

Обидва погоджуються — починається реалізація.

Це — дизайн-рев’ю. Але обидва — AI.

Чому це важливо

Якщо агенти одночасно планують і виконують — результати ненадійні. Навіть AI, що планує — значно покращує якість виходу.

8. Структуровані шаблони задач (Structured Task Templates)

Перед будь-яким кодом, harness аналізує реальний кодовий базу.

Він створює заземлену карту впливу:

  • Реальні шляхи файлів (не фантазії)
  • Імена існуючих символів
  • Використовувані шаблони
  • Конкретні критерії приймання

Після цього — починається реалізація.

Звучить очевидно. Але більшість команд пропускає цей крок.

Агент здогадується структуру файлів, вигадує API, що не існує, створює щось, що не пасує до коду.

Спершу — заземлений контекст, потім — виконання → якість виходу значно вища.

9. Школа OpenAI: пріоритет навколишнього середовища

Команда Codex OpenAI має дивну проблему:

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

На такому масштабі неможливо робити покроковий код-рев’ю. Тому вони не роблять.

Замість цього — повністю проектують середовище так, щоб агент з самого початку видавав «перевіряємий» результат.

Їхній підхід

  • Строге управління залежностями (Types → Config → Repo → Service → Runtime → UI)
  • Весь код розкиданий у AGENT.md
  • Агент під’єднаний до CI/CD pipeline

Філософія: Проектуй середовище. Потім запускай агента.

Докази

Sora Android app. 4 інженери. 28 днів. Перший у Play Store. 99.9% без збоїв.

Codex щотижня обробля 70% внутрішніх PR.

10. Школа Anthropic: розділення «роботи» і «оцінки»

Anthropic стикається з іншим питанням:

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

Самооцінка — не працює. Агент одночасно і студент, і викладач, і ставить собі «відмінно» по всіх пунктах.

Їхнє рішення: 3 спеціалізовані агенті

| Агент | | --- | | Planner | Перетворює 2 речення prompt у повну специфікацію продукту | | Generator | Реалізує один sprint за раз | | Evaluator | Автоматизоване тестування у браузері, імітуючи реального користувача |

Інсайт: зробити «незалежного» evaluator більш вибагливим — легше, ніж змусити generator бути більш критичним до себе.

Результати (A/B тестування)

| Налаштування | | --- | | Вартість | | Час | | Результат | | --- | --- | --- | --- | | Один агент (без harness) | $9 | 20 хвилин | Погане додаток | | Повний harness | $200 | 6 годин | Робочий софт + гарний інтерфейс |

11. Школа ThoughtWorks: матриця 2×2

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

Їхній інсайт: класифікація harness за двома осями

Ось 1: коли працює?

  • Feedforward = перед діями агента (настанови)
  • Feedback = після дій агента (сенсори)

Ось 2: як працює?

  • Обчислювальний = детермінований, мілісекундний (linter, type checker, тестовий набір)
  • Інференційний = з LLM, секундний (code review agent, семантичний аналіз)

Матриця 2×2

| | | --- | | Feedforward | настанови | | Feedback | сенсори | | --- | --- | --- | | Обчислювальний | типова система, лінтер, архітектурні правила | тестовий набір, покриття, мутаційне тестування | | Інференційний | специфікація, обмеження | LLM code reviewer, поведінковий валідатор |

Feedforward і feedback — обидва потрібні. Не можна використовувати лише один.

12. Принцип 1: Контекст важливіший за інструкцію

Різні команди, однакові відкриття:

  • OpenAI: дає карту, а не 1000-сторінковий посібник
  • Anthropic: JSON список функцій + прогрес-файл, щоб агент знав, де він
  • Red Hat: перед будь-якою задачею аналізує реальний кодовий баз
  • ThoughtWorks: називає «Feedforward»

Зв’язати агента з «поточним станом світу» — важливіше, ніж абстрактно казати, що робити.

Зв’язати з реальними файлами → адаптувати код до бази. Виходити з розпливчастих описів → уявних API.

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

13. Принцип 2: Планування і виконання мають бути розділені

  • OpenAI: людина проектує середовище, агент виконує
  • Anthropic: відповідальний Planner агент перед запуском Generator
  • ThoughtWorks: жорсткий розподіл між плануванням і реалізацією
  • Red Hat: фази 1 (карта впливу) і 2 (реалізація) — із жорстким розмежуванням

Кожна школа виявила: одночасне планування і виконання агентом — ненадійно.

Планування — не обов’язково має робити людина, але має бути окремим кроком, і його результат має бути перевірений перед початком.

14. Принцип 3: Цикл зворотного зв’язку — незамінний

  • OpenAI: агент інтегрований у CI/CD і моніторинг
  • Anthropic: окремий Evaluator агент + автоматизація у браузері
  • ThoughtWorks: формалізовано як «сенсори», що попереджають — без зворотного зв’язку, лише feedforward — не можна гарантувати ефективність інструкцій

Три школи — однаковий принцип, три підходи:

| Школа | | --- | джерело зворотного зв’язку | | --- | --- | | OpenAI | автоматичне тестування + CI | | Anthropic | інший LLM | | ThoughtWorks | об’єднання обох підходів |

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

Без зворотного зв’язку harness — це просто команда з кількох кроків.

15. Принцип 4: Робити можна лише одну річ за раз

  • OpenAI: розбиває ціль на дрібні блоки, глибина пріоритету
  • Anthropic: обов’язково — «один feature за sprint», завершити — і закомітити
  • ThoughtWorks: етапи життєвого циклу (pre-integration → post-integration → continuous monitoring)

Якщо агент намагається зробити багато —:

  • Витрачає контекст
  • Втрачає цілісність
  • Тихо відмовляється від вимог

Загальна практика Anthropic: читати прогрес → обрати один feature → реалізувати → закомітити → повторювати.

«Принцип поступового руху вперед» — спільна риса всіх успішних harness.

16. Принцип 5: Кодова база сама є документом

  • OpenAI: AGENT.md — вбудований у репозиторій
  • Anthropic: список функцій, файли прогресу, історія git — механізм безперервної інтеграції
  • ThoughtWorks: оцінка «harnessability» — читабельність кодової бази для агента

Ніхто не буде окремо підтримувати базу знань для агента. Репозиторій — єдина істина.

Якщо правило, обмеження або архітектурне рішення не в кодовій базі — агент його не знає.

Практичне значення

  • Команди, що інвестують у структуру коду, — безкоштовно отримують кращий агент
  • Грязний репозиторій + AI агент = масштабований хаос

17. Занепад Harness (Harness Decay) — це реально

Коли Anthropic оновила Opus з 4.5 до 4.6 — розбиття sprint (спочатку — обов’язковий етап) стало зайвим.

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

З березня до квітня компоненти harness, що раніше були критичними, перетворилися на навантаження.

Після запуску Opus 4.7 — модель почала самостійно перевіряти свої виходи, роль Evaluator зменшилася.

Це і є занепад Harness

Кожен компонент у harness містить припущення «модель не може зробити це». Якщо модель покращується — ці припущення застарівають — компоненти стають зайвими.

| Версія моделі | | --- | Стани harness | | --- | --- | | Opus 4.5 | Розбиття sprint + оцінка кожного спринту | | Opus 4.6 | Без розбиття sprint + однократна оцінка (економія 38%) | | Opus 4.7 | Самоперевірка моделі → роль evaluator зменшується |

Створення для видалення (Build to Delete)

Philipp Schmid пропонує: «Build to delete».

Коли проектуєте кожен компонент harness — робіть його таким, щоб його можна було легко видалити.

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

| Команда | | --- | Рефакторинг за 6 місяців | | --- | --- | | Manus | 5 разів рефакторили harness | | LangChain | 3 рази за рік | | Vercel | видалили 80% інструментів — і покращили продуктивність |

Це не ознака поганої архітектури. Це — природна реакція на швидкий розвиток моделей.

Мертві компоненти harness щодня витрачають токени і не дають користі — просто марна трата.

19. Реальність витрат

Чесні дані A/B тестів Anthropic:

| Налаштування | | --- | Витрати | Час | Результат | | --- | --- | --- | --- | | Один агент (без harness) | $9 | 20 хвилин | Зламаний інтерфейс, неправильна фізика | | Повний harness (Opus 4.5) | $200 | 6 годин | Робочий софт, гарний UI, правильна фізика |

В 22 рази дорожче — для реального продукту, а не просто демонстрації.

Чи варто? Залежить від того, скільки коштує вашому команді зіпсований реліз.

Тут говорять про те, що зазвичай не обговорюють

Комбінація harness + модель — це еволюційний процес.

$200 harness після оновлення моделі — стає $124.

| Тренд | | --- | | Краща модель = простий harness = дешевше запускати = швидше вихід |

Переможці 2026 року — це не ті, хто пише найкращий код.

Вони — ті, хто проектує найкращі «обмеження».

І готові їх відкидати, коли вони перестають приносити прибуток.

Повний виклад

Що таке harness

  1. Агент = Модель + Harness
  2. Модель = CPU, Harness = ОС
  3. Той самий модель, кращий harness → +13% продуктивності

5 продуктів harness

  1. CLAUDE.md / AGENT.md — onboarding файл агента
  2. JSON список функцій — відстеження прогресу + тестовий набір
  3. Стандарт ініціалізації сесії — 7 кроків запуску
  4. Контракти спринту — домовленість перед початком кодування
  5. Структурований шаблон задач — реальні шляхи файлів, реальні шаблони

3 школи

  1. OpenAI: дизайн середовища, запуск агента
  2. Anthropic: розділення «роботи» і «оцінки»
  3. ThoughtWorks: матриця 2×2 feedforward/feedback

5 універсальних принципів

  1. Контекст важливіший за інструкцію
  2. Планування і виконання мають бути розділені
  3. Цикл зворотного зв’язку — незамінний
  4. Робити можна лише одну річ за раз
  5. Кодова база — це документ

Парадоксальні моменти

  1. Занепад Harness — те, що працювало минулого місяця, тепер зменшується у цінності
  2. Створено для видалення — регулярно тестуйте і видаляйте мертві компоненти
  3. Реальність витрат — краща модель = простий harness = дешевше запускати

Переможці 2026 року — це не ті, хто пише найкращий код. Вони — ті, хто проектує найкращі «обмеження» — і готові їх відкидати, коли вони перестають бути вигідними.

Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • Прокоментувати
  • Репост
  • Поділіться
Прокоментувати
Додати коментар
Додати коментар
Немає коментарів
  • Закріплено