Harness Engineering: что нужно знать каждому AI-инженеру в 2026 году

Источник: https://x.com/sairahul1/status/2063544956158185927

Автор: Rahul

В феврале 2026 года небольшая команда OpenAI выпустила 1 миллион строк production-кода.

Они не написали вручную ни одной строки.

Код написали AI-агенты.

Люди спроектировали систему, которая сделала агентов надежными.

У этой системы теперь есть название.

Harness Engineering.

За несколько недель Anthropic опубликовала об этом 3 статьи.

ThoughtWorks формализовала фреймворк.

Филипп Шмид из Hugging Face назвал это «самой важной дисциплиной 2026 года».

Новая инженерная дисциплина материализовалась за 90 дней.

И почти никто за пределами AI-инфраструктурных команд пока ее не понимает.

Эта статья объясняет все.

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

Сохраните это. Вы прочитаете материал дважды.

ЧАСТЬ 1: ЧТО ТАКОЕ HARNESS НА САМОМ ДЕЛЕ (Концепция, которая меняет взгляд на AI)

1. Определение harness

Самое простое определение пришло от ThoughtWorks:

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

Harness — это все, что не является моделью.

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

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

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

Название пришло из конной упряжи.

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

Вы не делаете лошадь умнее. Вы проектируете снаряжение, которое делает ее силу полезной.

1. Аналогия с операционной системой

Филипп Шмид дал лучшую техническую рамку:

Думайте об этом как о компьютере.

→ Модель = CPU (сырая вычислительная мощность)

→ Контекстное окно = RAM (ограниченная, энергозависимая рабочая память)

→ Harness = Операционная система (управляет тем, что и когда видит CPU)

→ Агент = Приложение, работающее поверх этого

Ваша модель мощная.

Но без ОС, которая управляет памятью, планирует задачи и обеспечивает правила, — это просто кремний.

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

Именно поэтому их агенты проваливаются в production.

1. Что изменилось в 2026 году

LangChain дважды прогнал одну и ту же модель на Terminal Bench 2.0.

Та же модель. Другой harness.

→ Старый harness: результат 52,8%

→ Новый harness: результат 66,5%

Vercel пошла в противоположном направлении.

Они убрали 80% инструментов своего агента.

Результат? Производительность стала лучше.

Не хуже.

Неудобная правда 2026 года:

→ Агент никогда не был самой сложной частью.

→ Самая сложная часть — harness.

Если 2025-й был годом, когда AI-агенты доказали, что могут писать код…

То 2026-й — год, когда мы обнаружили: среда важнее модели.

ЧАСТЬ 2: 5 АРТЕФАКТОВ HARNESS (Как harness выглядит на практике)

1. Файлы AGENT.md / CLAUDE.md

Самый универсальный артефакт harness.

Markdown-файлы, распределенные по вашей кодовой базе.

Агент читает их в начале каждой сессии — как onboarding-документацию для нового инженера, который присоединился к команде.

Что в них помещают:

→ Контекст проекта

→ Соглашения по написанию кода

→ Архитектурные решения

→ Инструкции в духе «как мы здесь делаем вещи»

→ То, что сейчас находится в работе

OpenAI называет их AGENT.md.

Anthropic называет их CLAUDE.md.

Cursor использует .cursorrules.

Разные названия. Один принцип.

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

Без них агент начинает каждую сессию вслепую. С ними — начинает каждую сессию информированным.

1. JSON-списки фич (трекер прогресса)

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

Как он узнает, что уже сделано?

Через JSON-файл.

Каждая запись определяет:

→ Фичу

→ Как проверить, что она работает

→ Статус Pass / Fail

Агент читает это в начале сессии. Выбирает самую приоритетную проваленную фичу. Реализует ее. Отмечает как проходящую. Коммитит. Повторяет.

Почему JSON, а не Markdown?

Anthropic обнаружила, что агенты реже случайно перезаписывают JSON, чем Markdown.

Маленькая деталь. Очень важная в 6-часовых автономных прогонах.

1. Рутины инициализации сессии

Каждая сессия начинается одинаково.

Каждая. Без. Исключений.

7-шаговая boot-последовательность Anthropic:

1. Подтвердить рабочую директорию
2. Прочитать git-логи и файлы прогресса
3. Проверить список фич на самый приоритетный незавершенный пункт
4. Запустить dev-сервер
5. Выполнить базовую end-to-end-проверку
6. Реализовать одну фичу
7. Закоммитить с описательным сообщением + обновить прогресс

Без этого:

Агент тратит первые 20 минут на выяснение того, что уже существует.

Каждая сессия заново изобретает колесо.

С этим:

Агент мгновенно начинает с нужным контекстом и сразу переходит к работе.

1. Sprint contracts

До того как агент напишет хотя бы одну строку кода:

Два агента договариваются.

Агент-генератор предлагает:

→ Что он будет строить

→ Как будет проверяться успех

Агент-оценщик проверяет:

→ Полное ли предложение?

→ Понятны ли критерии успеха?

Только после согласия обеих сторон начинается реализация.

Это design review.

Только оба участника — AI.

Почему это важно?

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

Шаг планирования — даже если его выполняет AI — резко повышает качество результата.

1. Структурированные шаблоны задач

Перед любым кодингом:

Harness анализирует реальную кодовую базу.

Он выдает grounded impact map:

→ Реальные пути к файлам (а не галлюцинированные)

→ Реальные имена символов, которые действительно существуют

→ Существующие паттерны, которым нужно следовать

→ Конкретные критерии приемки

Затем начинается реализация.

Звучит очевидно.

Но большинство команд это пропускают.

Агент угадывает структуру файлов. Придумывает API-эндпоинты, которых не существует. Строит то, что не вписывается в кодовую базу.

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

ЧАСТЬ 3: ТРИ ЛАГЕРЯ (Три команды уперлись в одну стену — и построили три разные лестницы)

1. OpenAI: environment-first

У команды Codex в OpenAI была абсурдная проблема.

1 миллион строк production-кода. Ноль написано вручную.

В таком масштабе невозможно код-ревьюить каждую строку.

Поэтому они этого не делали.

Вместо этого:

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

Их подход:

→ Строгие потоки зависимостей (Types → Config → Repo → Service → Runtime → UI)

→ Файлы AGENT.md по всей кодовой базе

→ Агенты, напрямую подключенные к CI/CD-пайплайнам

Философия: спроектируйте среду. Затем отпустите агента.

Доказательство: Android-приложение Sora. 4 инженера. 28 дней. #1 в Play Store. 99,9% без крашей.

Codex еженедельно обрабатывал 70% внутренних pull request.

1. Anthropic: отделить исполнителя от судьи

У Anthropic была другая проблема.

Когда они просили агента оценить собственный результат:

Он уверенно хвалил работу.

Даже когда для человека-наблюдателя качество было очевидно посредственным.

Самооценка не работает.

Агент был и учеником, и учителем.

И ставил себе одни пятерки.

Их решение: три специализированных агента.

→ Planner — превращает промпт из 2 предложений в полную продуктовую спецификацию

→ Generator — реализует фичи по одному спринту за раз

→ Evaluator — использует browser automation, чтобы тестировать запущенное приложение как реальный пользователь

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

Результат: одиночный агент (без harness): $9, 20 мин

→ сломанное приложение Full harness: $200, 6 часов

→ рабочее ПО с отполированным UI

1. ThoughtWorks: фреймворк 2×2

ThoughtWorks пришла с другого угла.

Они не строили продукт.

Они наблюдали, как 50+ инженерных команд проваливаются на одних и тех же вещах.

Их инсайт: классифицировать каждый контроль harness по двум осям.

Ось 1: когда он запускается?

→ Feedforward = до действия агента (направляет)

→ Feedback = после действия агента (сенсоры)

Ось 2: как он работает?

→ Computational = детерминированно, миллисекунды (линтеры, type checkers, test suites)

→ Inferential = использует LLM, секунды (агент код-ревью, семантический анализ)

Матрица 2×2:

→ Computational Feedforward: системы типов, линтеры, архитектурные правила

→ Computational Feedback: наборы тестов, анализ покрытия, mutation testing

→ Inferential Feedforward: документы спецификаций, описания ограничений

→ Inferential Feedback: LLM code reviewers, валидаторы поведения

Ни feedforward, ни feedback по отдельности не работают.

Нужны оба.

ЧАСТЬ 4: 5 ПРИНЦИПОВ, С КОТОРЫМИ СОГЛАСНЫ ВСЕ ЛАГЕРЯ (Три команды не координировались. Они пришли к этому независимо.)

1. Принцип 1: контекст сильнее инструкций

OpenAI: «Дайте карту, а не руководство на 1000 страниц».

Anthropic: JSON-списки фич и файлы прогресса, чтобы агенты всегда знали, где они находятся.

Red Hat: анализ реальной кодовой базы до генерации любых задач.

ThoughtWorks: «Feedforward».

Разные слова. Одно открытие.

Показать агенту текущее состояние мира стабильно эффективнее, чем абстрактно говорить ему, что делать.

→ Привязка к реальным путям файлов

→ код, который вписывается в кодовую базу

→ Работа от расплывчатого описания

→ галлюцинированные пути файлов и придуманные API

Урок: прежде чем агент что-то напечатает, убедитесь, что он точно знает, где находится.

1. Принцип 2: планирование и исполнение должны быть разделены

OpenAI: люди проектируют среду, агенты исполняют.

Anthropic: выделенный агент Planner запускается до того, как Generator коснется кода.

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

Red Hat: Фаза 1 (impact map) и Фаза 2 (реализация) с жестким gate между ними.

Каждый лагерь обнаружил это независимо:

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

Шаг планирования не обязательно должен делать человек.

Но это должен быть отдельный шаг, а его результат нужно проверить до начала реализации.

1. Принцип 3: петли обратной связи обязательны

OpenAI: агенты подключены к CI/CD и observability-системам.

Anthropic: выделенный агент Evaluator с browser automation.

ThoughtWorks: формализовали это как «сенсоры». Предупредили, что подходы только с feedforward никогда не подтверждают, действительно ли работают направляющие.

Три подхода к одному принципу:

→ OpenAI использует автоматические тесты и CI

→ Anthropic использует другую LLM

→ ThoughtWorks говорит использовать оба слоями

Они расходятся во мнении, кто дает обратную связь.

Но не спорят о том, нужна ли она.

Harness без обратной связи — это просто промпт с лишними шагами.

1. Принцип 4: одна вещь за раз

OpenAI: разбивает цели на более мелкие строительные блоки, работает depth-first.

Anthropic: принудительно задает one-feature-per-sprint с коммитом после каждой.

ThoughtWorks: фазовый lifecycle (pre-integration → post-integration → continuous monitoring).

Агенты, которые пытаются делать слишком много сразу:

→ Исчерпывают контекст

→ Теряют связность

→ Молча пропускают требования

Рутина Anthropic:

Прочитать прогресс → выбрать ОДНУ фичу → реализовать → закоммитить → повторить

Принудительная инкрементальность универсальна для каждого успешного harness.

1. Принцип 5: кодовая база И ЕСТЬ документация

OpenAI: встраивает файлы AGENT.md в репозиторий.

Anthropic: хранит списки фич, файлы прогресса и git-историю как механизм непрерывности для агента.

ThoughtWorks: измеряет «harnessability» — насколько кодовая база понятна агентам.

Никто не ведет отдельную базу знаний для агента.

Репозиторий — единый источник истины.

Если соглашения, ограничения или архитектурного решения нет в кодовой базе — агент о нем не узнает.

Практическое следствие:

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

→ Грязные репозитории + AI-агенты = хаос, только в масштабе.

ЧАСТЬ 5: ПАРАДОКС — СТРОИТЬ, ЧТОБЫ УДАЛЯТЬ (Самая контринтуитивная истина в harness engineering)

1. Деградация harness реальна

Когда Anthropic обновилась с Opus 4.5 до Opus 4.6:

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

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

Компонент harness, который был несущим в марте, к апрелю стал overhead.

Затем вышел Opus 4.7.

Модель начала проверять собственные результаты.

Описание работы агента Evaluator начало сокращаться.

Это и есть деградация harness.

Каждый компонент harness кодирует предположение о том, чего модель не умеет.

По мере улучшения моделей → эти предположения устаревают → компонент становится overhead.

Opus 4.5: декомпозиция на спринты + оценка каждого спринта

Opus 4.6: без декомпозиции на спринты + single-pass evaluation (экономит 38% стоимости)

Opus 4.7: модель начинает самопроверку → роль evaluator сокращается еще сильнее

1. Build to Delete

Совет Филиппа Шмида:

«Build to delete».

Проектируйте каждый компонент harness так, чтобы его можно было удалить.

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

Если не меняется — удаляйте.

Manus рефакторила свой harness 5 раз за 6 месяцев. LangChain реструктурировала его 3 раза за 1 год. Vercel убрала 80% инструментов → получила лучшую производительность.

Это не признаки плохой инженерии.

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

Мертвые компоненты harness стоят токены в каждом отдельном прогоне. Ноль дополнительного качества. Чистые потери.

1. Реальность стоимости

Честные цифры из A/B-теста Anthropic:

→ Одиночный агент (без harness): $9, 20 минут

→ рабочий UI, сломанная core-функциональность

→ Полный harness (Opus 4.5): $200, 6 часов

→ рабочее ПО, отполированный UI, корректная физика

Это рост стоимости в 22 раза.

За функционирующий продукт вместо демо, которое правильно выглядит только на скриншотах.

Дорого это или дешево — полностью зависит от того, сколько вашей команде стоит сломанный релиз.

Но вот о чем никто не говорит:

Комбинация harness + model развивается.

Harness за $200 стал harness за $124 после одного обновления модели.

Линия тренда:

→ Лучшая модель = более простой harness = более дешевый прогон = более быстрый результат

Инженеры, которые побеждают в 2026 году, не пишут лучший код.

Они проектируют лучшие ограничения.

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

ЗАКЛЮЧЕНИЕ

Все, что вы только что узнали:

Что такое harness:

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

→ 2. Модель = CPU. Harness = Операционная система.

→ 3. Та же модель, лучший harness = +13% производительности

5 артефактов harness:

→ 4. CLAUDE.md / AGENT.md — onboarding-документация для агентов

→ 5. JSON-списки фич — трекер прогресса + набор тестов в одном

→ 6. Рутины инициализации сессии — одинаковый 7-шаговый boot каждый раз

→ 7. Sprint contracts — агенты договариваются до кодинга

→ 8. Структурированные шаблоны задач — реальные пути файлов, реальные паттерны

Три лагеря:

→ 9. OpenAI: спроектировать среду, отпустить агента

→ 10. Anthropic: отделить исполнителя от судьи

→ 11. ThoughtWorks: фреймворк feedforward/feedback 2×2

5 универсальных принципов:

→ 12. Контекст сильнее инструкций

→ 13. Планирование и исполнение должны быть разделены

→ 14. Петли обратной связи обязательны

→ 15. Одна вещь за раз

→ 16. Кодовая база — это документация

Парадокс:

→ 17. Деградация harness — то, что работало в прошлом месяце, вредит в этом

→ 18. Build to delete — тестируйте и удаляйте мертвые компоненты

→ 19. Реальность стоимости — лучшая модель = более простой harness = более дешевый прогон

Инженеры, которые побеждают в 2026 году, не пишут лучший код.

Они проектируют лучшие ограничения.

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

Если это было полезно:

→ Сделайте репост, чтобы материал дошел до разработчиков в вашей сети

→ Подписывайтесь на @sairahul1, чтобы получать больше такого каждую неделю

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

Я пишу об AI, создании продуктов и о том, что действительно работает в 2026 году.