Harness Engineering: Побудова систем навколо AI-агентів (2026)

TL;DR

Що таке Harness Engineering?

Harness engineering — це дисципліна побудови систем, інструментів, обмежень та циклів зворотного зв'язку навколо ШІ-агентів для кодингу, щоб зробити їх надійними та продуктивними.

Термін був введений Мітчеллом Хашимото (співзасновником HashiCorp) і набув широкої популярності, коли OpenAI опублікувала свою статтю про Codex на цю тему на початку 2026 року.

Основна ідея проста:

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

Модель забезпечує інтелект. Harness робить цей інтелект корисним. Кращий harness часто важливіший за кращу модель.

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

У 2025 році кожна команда впровадила ШІ-агентів для написання коду. У 2026 році перемагають ті команди, які спроектували середовище для своїх агентів, а не просто обрали найкращу модель.

Керівний принцип Мітчелла Хашимото:

"Щоразу, коли ви виявляєте, що агент припускається помилки, ви витрачаєте час на розробку рішення, яке гарантує, що агент ніколи більше не зробить цієї помилки."

Це не промпт-інженерія. Це системна інженерія для ШІ.

Докази: Harness > Модель

LangChain провели контрольований експеримент на Terminal Bench 2.0. Не змінюючи базову модель, вони покращили точність свого агента з 52.8% до 66.5% — покращення на 26% — лише шляхом вдосконалення harness.

Зміни включали:

• Покращені файли контексту (AGENTS.md)


• Обмеження структурованого виводу


• Цикли самоперевірки


• Оптимізація інструментів

7 компонентів Harness

1. Контекстна інженерія

Контекстна інженерія — це фундамент. Саме тут ви надаєте агенту карту вашої кодової бази, ваші конвенції та обмеження.

• Файли CLAUDE.md / AGENTS.md у корені вашого репозиторію
• Карти директорій та архітектурні огляди
• Правила стилю коду та конвенції іменування

# CLAUDE.md example
## Architecture
- src/app/ — Next.js app router pages
- src/lib/ — shared utilities and API clients
- src/components/ — React components (co-located styles)

## Rules
- Use server components by default
- Never import from node_modules directly in components
- All API calls go through src/lib/api.ts

2. Архітектурні обмеження

Замість того, щоб сподіватися, що агент обере правильну архітектуру, нав'яжіть її.

• Жорсткі шаруваті архітектури, перевірені лінтерами
• Структурні тести, які не проходять, якщо порушені патерни
• Обмеження імпорту через правила ESLint або власні скрипти

3. Інструменти та MCP-сервери

Агентам потрібні інструменти, щоб бути ефективними. Найкращі системи harness надають доступ до внутрішніх інструментів через:

• CLI-обгортки — віддавайте перевагу відомим CLI (git, docker, npm), а не власним інструментам
• MCP (Model Context Protocol) сервери — дозволяйте агентам викликати ваші внутрішні API, бази даних та сервіси
• Доступ до файлової системи — обмежений конкретними директоріями для запобігання випадковим пошкодженням

4. Субагенти та контекстні фаєрволи

Тривалі сесії агентів накопичують контекст, що з часом погіршує продуктивність — це називається деградацією контексту (context rot).

Рішення: субагенти з контекстними фаєрволами.

• Розбивайте складні завдання на окремі підзавдання
• Кожне підзавдання виконується у власній сесії зі свіжим контекстом
• Передавайте між агентами лише структуровані результати, а не всю переписку

1. Initializer Agent — планує роботу, створює список функцій
2. Coding Agent — реалізує кожну функцію окремо

5. Хуки та зворотний тиск (Back-Pressure)

Автоматизовані цикли зворотного зв'язку, які виловлюють помилки до того, як вони накопичаться:

• Pre-commit хуки — перевірка типів, лінтинг, форматування
• Test runners — агенти повинні запускати тести після кожної зміни
• Build verification — швидке завершення роботи при помилках збірки

6. Цикли самоперевірки

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

• Запуск тестів після змін
• Перевірка успішності збірки
• Перевірка відповідності результату специфікації
• Скріншот та порівняння (для завдань з UI)

7. Документація прогресу

Для тривалих завдань (30+ хвилин):

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

Реальні результати

Команда OpenAI Codex

3 інженери створили мільйон рядків коду без жодного рядка, написаного вручну, протягом 5 місяців. У середньому вони робили 3.5 злитих PR на інженера в день — пропускна здатність, яка неможлива без зрілого harness.

Їхній harness включав: суворі конвенції комітів, автоматизоване тестування кожного PR та CI/CD пайплайни, адаптовані для агентів.

Stripe "Minions"

Внутрішня система Stripe генерує понад 1,000 злитих PR на тиждень за допомогою ШІ-агентів. Їхній harness включає:

• Чітко визначені межі завдань
• Обов'язкове код-рев'ю людьми
• Автоматизоване регресійне тестування
• Автоматизація відкатів (rollbacks)

Двоагентна архітектура Anthropic

Anthropic опублікувала свій підхід до ефективних harness для тривалих завдань:

• Структуровані списки функцій як формат передачі завдань між агентами
• Відстеження прогресу на основі Git, щоб агенти могли відновити роботу після переривання
• Чіткі критерії виходу, щоб агенти знали, коли зупинитися

Як почати будувати свій Harness

Крок 1: Створіть файл контексту

Додайте CLAUDE.md (або AGENTS.md) у корінь вашого проекту:

# Project: [Назва вашого проекту]

## Stack
[Фреймворк, мова, база даних, хостинг]

## Architecture
[Структура директорій з короткими описами]

## Rules
[5-10 суворих правил, яких агент повинен дотримуватися]

## Common Tasks
[Як запускати тести, збірку, деплой]

Крок 2: Додайте структурні обмеження

# Приклад: правило ESLint, що забороняє прямий імпорт БД у компоненти
# .eslintrc — правило no-restricted-imports

Налаштуйте pre-commit хуки, які автоматично перевіряють ваші правила.

Крок 3: Побудуйте цикли перевірки

Переконайтеся, що ваш агент може:

1. Запускати тести (npm test, pytest тощо)


2. Перевіряти типи (tsc --noEmit, mypy)


3. Лінтувати (eslint ., ruff check)

Крок 4: Обмежте сесії агента

Не давайте агенту весь ваш беклог. Замість цього:

• Одна функція на сесію
• Одне виправлення багу на сесію
• Чіткі критерії прийняття для кожного завдання

Крок 5: Ітеруйте Harness

Щоразу, коли агент припускається помилки:

1. Визначте першопричину
2. Додайте правило, обмеження або хук, який запобігає цьому
3. Перевірте виправлення

Harness Engineering vs. Prompt Engineering

Промпт-інженерія все ще корисна, але це лише мала частина картини. Harness engineering — це мультиплікатор.

Нова роль: Harness-інженер

Інженерія розділяється на дві частини:

1. Побудова середовища — створення структури, інструментів, обмежень та циклів зворотного зв'язку
2. Управління роботою — планування, рев'ю та оркестрація паралельних сесій агентів

Не плутати з: Harness.io

Якщо ви шукали "Harness Engineering", маючи на увазі DevOps-платформу — Harness.io це зовсім інша річ. Це CI/CD платформа на базі ШІ, що оцінюється у $5.5 млрд (станом на грудень 2025 року), яка пропонує безперервну інтеграцію, доставку, фіча-флаги, управління хмарними витратами та тестування безпеки.

Хоча Harness.io та harness engineering мають спільну назву, вони вирішують різні проблеми. Хоча є цікавий перетин: AI-DevOps від Harness.io можна вважати застосуванням принципів harness engineering до пайплайну розгортання.

Підсумок

Модель — це двигун. Harness — це автомобіль. Ніхто не виграє гонку, маючи лише двигун.

Якщо ви використовуєте ШІ-агентів для кодингу у 2026 році і не інвестуєте у свій harness, ви втрачаєте більшу частину вигоди. Почніть із файлу контексту, додайте обмеження, побудуйте цикли перевірки та ітеруйте щоразу, коли щось ламається.

Команди, які шиплять найшвидше, не використовують кращі моделі. Вони використовують кращі harnesses.