Что такое harness engineering
Термин закрепился после поста команды Codex в OpenAI «Harness engineering: leveraging Codex in an agent-first world» в феврале 2026 года. Команда за пять месяцев собрала внутренний продукт размером больше миллиона строк. Код целиком писали агенты, люди не написали руками ни строки.
Главный вывод поста касается работы людей. Первые недели проект двигался медленно. Модель справлялась с задачами, но среда вокруг неё была описана плохо: агент не знал архитектуру, не мог сам проверить результат и повторял одни и те же ошибки. Инженеры перестали писать код и стали строить инструменты, документацию и проверки, через которые агент работает.
Harness выполняет четыре функции:
- Ограничивает. Задаёт, что агенту можно менять, какие команды запускать и куда ему нельзя.
- Информирует. Даёт агенту архитектуру, договорённости команды и требования к задаче.
- Проверяет. Тесты, линтеры, типы и ревью ловят ошибки до человека.
- Исправляет. Возвращает агенту замечания и превращает повторяющиеся ошибки в новые правила.
Модель в этой схеме — сменная деталь. Harness остаётся в репозитории и работает с любой моделью, которую команда выберет завтра.
Чем harness отличается от context engineering и промптов
Эти три понятия часто смешивают. Разница в том, на какой вопрос каждое отвечает.
| Подход | Вопрос | Где живёт результат |
|---|---|---|
| Prompt engineering | Как сформулировать запрос к модели | В голове разработчика и в истории чата |
| Context engineering | Что агент должен увидеть, чтобы решить задачу | В подборе файлов, документации и инструментов на одну сессию |
| Harness engineering | Что система должна запретить, проверить и исправить | В репозитории: правила, спеки, тесты, CI, ревью-агенты |
Context engineering входит в harness как один из слоёв. Хороший контекст повышает шанс, что агент сделает задачу правильно с первого раза. Harness отвечает за случаи, когда агент ошибся: ошибку должна поймать проверка, а исправление должно попасть в правила.
Из чего состоит harness
В проектах Праксора harness складывается из четырёх слоёв над кодовой базой. Каждый слой версионируется в git рядом с кодом.
Правила и рамки
Инструкции агентам под стек и кодовую базу: команды сборки и тестов, стиль кода, запреты, порядок работы с ветками. Обычно это AGENTS.md в корне репозитория и вложенные файлы в модулях. Сюда же относятся права агента: в какие каталоги он пишет, какие команды запускает без подтверждения, к каким сервисам у него есть доступ.
База знаний
Архитектурная карта, контракты между сервисами и журнал решений (ADR). Агент читает её перед задачей, когда правил в AGENTS.md недостаточно. В посте OpenAI команда держала в репозитории архитектурную документацию и отдельный документ с оценкой качества каждого домена. Агент сверялся с ним, когда выбирал, какой код брать за образец.
Спецификации
Требования к задаче с acceptance criteria, привязанными к тестам. Спека нужна, чтобы агент не додумывал требования молча. Подробнее о подходе — в статье про spec-driven development.
Quality gates
Проверки, через которые проходит каждое изменение: тесты, линтеры, типы, архитектурные правила, ревью другим агентом. Типовые задачи проходят цикл автоматически. На изменениях с высокой ценой ошибки стоит ревью человека. Как настроить ревью агентами — в статье AI code review.
Цикл улучшения: дефект чинят в harness
Главная привычка, которую меняет harness engineering: ошибку агента не исправляют руками в коде. Её разбирают и меняют систему, которая её допустила.
Пример из практики Праксора. Ревью-агент заметил, что суммы в сводном отчёте расходятся у части клиентов, хотя базовые тесты зелёные. Разбор конкретных записей показал причину: агрегация шла по серверному UTC вместо местной даты клиента, и сделка в 23:40 попадала в соседние сутки. Команда исправила код и добавила в harness правило «симптом, причина, проверка» и новую проверку в ревью. В следующем продукте агент учитывал это правило с первой задачи.
Так harness накапливает опыт команды. Через несколько месяцев в нём оказываются все грабли, на которые наступали агенты и люди, и новая команда получает их сразу.
Полезные механики цикла:
- Лимит пересдач. Агент сдаёт работу проверяющему агенту. После трёх неудачных пересдач задача уходит человеку, и это сигнал, что в harness чего-то не хватает.
- Разбор ручных правок. По истории git видно, где работал агент и где человек поправил результат руками. Каждая такая правка — кандидат на новое правило или проверку.
- Привязка дефектов к спекам. Раз в неделю команда смотрит, какой спеке соответствовал дефект, и чинит спеку или шаблон спеки.
Где нужен человек: масштаб последствий
Полный контроль каждого изменения съедает выигрыш от агентов. Полная автономия опасна. Задачи делят по тому, что заденет ошибка. В англоязычных материалах это называют blast radius.
- Один модуль. Изменение внутри одного модуля, покрытое тестами. Идёт через автоматический цикл: агент пишет, другой агент ревьюит, CI проверяет.
- Публичный API или данные. Изменение трогает публичный API модуля или схему данных. Агент делает работу, человек принимает её в контрольной точке.
- Другие команды. Изменение задевает другие команды или инфраструктуру. Агент сам отправляет задачу на архитектурное ревью.
Правило «разработчик не ревьюит свой код» действует и для агентов. Одна модель пишет, другая проверяет. Так ошибки одной модели реже проходят незамеченными.
С чего начать в своей команде
- Зафиксировать стартовые метрики. Lead time, частота релизов, доля rework, время на ревью. Без них через три месяца не с чем будет сравнить.
- Написать AGENTS.md. Команды сборки и тестов, структура репозитория, запреты. Короткий файл, который агент читает перед каждой задачей.
- Сделать проверки исполняемыми. Перенести самые частые замечания с ревью в линтеры и тесты.
- Ввести спеку для задач. Шаблон с acceptance criteria и ссылками на тесты.
- Прогнать две-три реальные задачи из бэклога через весь цикл: спека, генерация, проверка, выкладка. Каждую ручную правку разобрать и превратить в изменение harness.
Первую версию harness собирают за несколько дней. Больше времени уходит на договорённости: кто в команде отвечает за правила, кто принимает изменения в базу знаний, как разбирать дефекты.
Частые ошибки
- Чинить код руками после агента. Дефект исправлен, но причина осталась, и агент повторит ошибку в следующей задаче.
- Один огромный файл инструкций. Агент теряет важные правила среди второстепенных. Правила лучше разложить по модулям и вынести детали в базу знаний.
- Правила только в тексте. То, что можно проверить автоматически, должно стать проверкой.
- Harness на одного человека. Если правила знает и правит один энтузиаст, harness перестаёт обновляться, когда тот уходит в отпуск. Нужны 1–3 владельца с выделенным временем.
- Нет замера. Количество сгенерированного кода и PR растёт, а lead time и rework никто не смотрит.
Как Праксор собирает harness
Две недели диагностики и замер стартовых метрик, затем две недели на первую версию harness под ваш стек. После воркшопа пилотная команда работает по новому процессу 2–3 месяца с сопровождением архитектора. Harness и база знаний остаются в вашем репозитории, а 1–3 сотрудника становятся внутренней AI Harness Team. Программа целиком
Вопросы
Harness engineering — это то же самое, что DevOps для агентов?
Пересечение большое: CI, тесты и окружения входят в harness. Но harness включает ещё инструкции агентам, базу знаний, спецификации и цикл, который превращает ошибки агентов в новые правила.
Нужен ли harness, если команда пользуется Cursor или Claude Code по отдельности?
Пока каждый разработчик работает с агентом в своём стиле, эффект зависит от конкретного человека. Harness делает практики общими: правила, проверки и база знаний одинаковые для всех и лежат в репозитории.
Привязан ли harness к конкретной модели или вендору?
Нет. Правила в AGENTS.md, спеки в markdown, тесты и линтеры читает любой агент. Смена модели не требует переделки harness.
Сколько времени занимает первая версия harness?
Сам harness собирается за несколько дней. Чтобы он заработал на команде, обычно нужно 2–3 месяца пилота с разбором дефектов и правкой правил.