Управление файлами cookie
Настройки файлов cookie
Файлы cookie, необходимые для корректной работы сайта, всегда включены.
Другие файлы cookie можно настроить.
Другие файлы cookie можно настроить.
Почему вокруг харнесса столько шума? Как ИИ меняет рутину разработчиков
Примерное время чтения: 5 минут
Хотите всегда быть в курсе событий на рынке IT? Подписывайтесь на наш Telegram-канал!
Еще недавно разговор об ИИ в разработке в основном сводился к сравнению моделей: какая лучше пишет код, понимает большой проект и реже ошибается. С появлением агентов этого стало недостаточно. Теперь еще важно, в какой среде находится агент, — результат от результата работы LLM теперь во многом зависит от качества окружения и среды вокруг этого самого ИИ-агента.
Эта самая инженерная и инфраструктурная среда вокруг ИИ-агента — харнесс (harness), или буквально «обвязка», по аналогии с test harness в тестировании. Это вся среда, которая определяет, как агент работает с проектом. Смысл этой обвязки в том, чтобы дать агенту возможность разобраться в задаче, найти нужную информацию, внести изменения и проверить результат.
Агент — система на базе LLM, которая умеет работать с инструментами разработки: читать файлы, искать по репозиторию, выполнять команды, менять код и запускать проверки. Одна и та же модель в разных агентах (или разных «обвязках») способна показывать разный результат.
Я Евгения Журавишкина, разработчик Selecty
Основной инструмент — n8n. Собираю автоматизации и интеграции, работаю с JavaScript, API и базами данных.
Основной инструмент — n8n. Собираю автоматизации и интеграции, работаю с JavaScript, API и базами данных.
В статье расскажу, что может входить в харнесс, чем он отличается от context engineering, в каких задачах действительно нужен и на что стоит обратить внимание при настройке среды вокруг ИИ-агента. А еще — как меняется роль айтишников с приходом нейросетей (спойлер: теперь все чаще нужно не писать код, а менеджерить агентов и выстраивать рабочую обвязку).
Содержание
Что такое харнесс
Харнесс включает все, через что агент взаимодействует с проектом: доступ к файлам и терминалу, оркестрация, поиск по коду, документацию, инструкции, тесты, линтеры, ограничения прав, механизмы сохранения состояния и обратной связи, результаты выполненных команд.
Приведу примеры, что может быть частью обвязки:
Приведу примеры, что может быть частью обвязки:
- После изменения кода агент автоматически получает результат компиляции и тестов.
- Архитектурное правило не просто записано в инструкции, но и проверяется статическим анализом.
- Если системе нужен доступ к определенным директориям или опасным операциям, она обязательно запрашивает подтверждение.
- Доступ к документации, ее использование в качестве источника правил и контекста, когда система перенаправляет ИИ-агента к нужным разделам доки. Сама по себе документация — еще не харнесс, а вот параметры и правила доступа к ней — уже да.
Почему харнесс — это не просто context engineering
Инженерия контекста, или context engineering — подход, который определяет, как выбрать, организовать и передать агенту именно ту информацию, которая нужна ему на текущем шаге. Например, какие файлы он увидит, какие инструкции прочитает, какую документацию найдет и что из предыдущей работы попадет в его текущий контекст.
Харнесс куда шире: это не только контекст, но и инструменты, оркестрация, доступ к проекту, проверки, ограничения и запреты, механизмы обратной связи и способы получения контекста.
Харнесс куда шире: это не только контекст, но и инструменты, оркестрация, доступ к проекту, проверки, ограничения и запреты, механизмы обратной связи и способы получения контекста.
- В рамках статьи я рассматриваю context engineering как один из механизмов, из которых складывается хороший harness. Дать агенту архитектурное правило в контексте — это context engineering. А добавить статическую проверку, которая технически не позволит это правило нарушить, — уже часть харнесс.
Когда просто хорошего промпта недостаточно и нужен харнесс
Для конкретной задачи, если она возникает единожды и не особо сложная, недостающие правила обычно добавляют прямо в запрос. В промпте указывают, какие файлы изучить, ограничения учесть, тесты запустить, какие существующие решения использовать. Когда одни и те же инструкции приходится повторять постоянно, разумнее поменять саму среду, в которой работает агент.
Примеры, когда от промпт-инжиниринга стоит перейти к выстраиванию харнесс:
Примеры, когда от промпт-инжиниринга стоит перейти к выстраиванию харнесс:
- Агент регулярно добавляет запрещенную зависимость. Лучше настроить автоматическую проверку и не допускать такого вообще, чем отлавливать одну и ту же ошибку на каждом ревью.
- Агент забывает запускать определенный набор тестов. Их прохождение можно сделать условием завершения задачи.
- При запуске агента нужно каждый раз по новой объяснять ему архитектуру проекта. Возможно, нужную информацию стоит зафиксировать в документации и сделать доступной из репозитория.
Что меняется для информационной безопасности
Харнесс определяет, как агент взаимодействует с проектом: какими инструментами пользуется, какие данные получает и какие действия выполняет. Ограничения доступа и подтверждение опасных операций тоже задаются в этой среде.
Агент получает довольно серьезные возможности: может читать файловую систему, выполнять команды, работать с Git, обращаться к внешним сервисам и использовать доступные процессу переменные окружения. Я бы рассматривала его как еще одного участника инфраструктуры, которому нужно определить права.
Агент получает довольно серьезные возможности: может читать файловую систему, выполнять команды, работать с Git, обращаться к внешним сервисам и использовать доступные процессу переменные окружения. Я бы рассматривала его как еще одного участника инфраструктуры, которому нужно определить права.
- В настройках среды должны быть ответы на эти (и не только!) вопросы: какие директории доступны ИИ-агенту? Разрешен ли выход в интернет и установка пакетов? Может ли он выполнять команды без подтверждения или отправлять изменения в удаленный репозиторий?
Если агент получает доступ к базе знаний, его права там не должны быть шире, чем у разработчика, иначе нейросеть сможет получить внутренние документы и использовать их при выполнении задачи. Если агент не должен видеть определенные данные, технически ограничьте к ним доступ.
Для потенциально опасных операций я бы оставляла подтверждение человека. Агент может самостоятельно выполнять разрешенные действия, а перед операцией с высокой ценой ошибки он должен останавливаться и запрашивать согласование.
Для потенциально опасных операций я бы оставляла подтверждение человека. Агент может самостоятельно выполнять разрешенные действия, а перед операцией с высокой ценой ошибки он должен останавливаться и запрашивать согласование.
Разработка движется в сторону harness engineering
В феврале 2026 года OpenAI описала эксперимент с Codex: команда создавала продукт с пустого Git-репозитория и договорилась вообще не писать код вручную. Код приложения, тесты, конфигурацию CI, документацию и внутренние инструменты генерировал ИИ-агент.
Значительная часть работы инженеров заключалась в проектировании харнесса: нужно было организовать среду, в которой Codex мог разобраться в проекте, выполнить задачу и проверить себя. Изменения в эту среду по заданиям команды тоже вносил ИИ-агент.
Через пять месяцев в репозитории было около миллиона строк кода. Команда, выросшая за это время с трех до семи инженеров, открыла и слила примерно 1500 пул-реквестов, в среднем около 3,5 в день на инженера. По грубой оценке самой OpenAI, это примерно в десять раз быстрее, чем получилось бы при ручной разработке.
Особенно интересно, как OpenAI прокомментировала сдвиг, который произошел в работе инженеров. Задачи инженеров сместились от написания кода к проектированию среды, постановке задачи и построению обратной связи, в то время как ИИ-агенты выполняют работу внутри этой среды.
Значительная часть работы инженеров заключалась в проектировании харнесса: нужно было организовать среду, в которой Codex мог разобраться в проекте, выполнить задачу и проверить себя. Изменения в эту среду по заданиям команды тоже вносил ИИ-агент.
Через пять месяцев в репозитории было около миллиона строк кода. Команда, выросшая за это время с трех до семи инженеров, открыла и слила примерно 1500 пул-реквестов, в среднем около 3,5 в день на инженера. По грубой оценке самой OpenAI, это примерно в десять раз быстрее, чем получилось бы при ручной разработке.
Особенно интересно, как OpenAI прокомментировала сдвиг, который произошел в работе инженеров. Задачи инженеров сместились от написания кода к проектированию среды, постановке задачи и построению обратной связи, в то время как ИИ-агенты выполняют работу внутри этой среды.
- По сути, разработка превращается из «классической» версии с написанием кода в harness engineering — проектирование среды и инфраструктуры вокруг ИИ-агентов. При этом harness engineering не заменяет хорошие модели и хорошие промпты, а надстраивается над ними.
Евгения Журавишкина
Разработчик Selecty
Читайте также