Сегодня AI уже способен массово писать код — например, с помощью Claude Code или Codex. Но ключевая задача в этой сфере изменилась: теперь важно не просто генерировать код, а обеспечить стабильное, безопасное и повторяемое внедрение AI в крупных проектах. Для этого появилось понятие Harness Engineering — инженерной среды вокруг модели.
HackerNoon выделяет 5 элементов контроля в рамках Harness Engineering: Context, Skills, Boundaries, Verification, Learning. Birgitta Böckeler из Thoughtworks определяет harness как всё в AI‑агенте, кроме модели (Agent = Model + Harness). По её мнению, хороший внешний каркас решает две задачи: повышает вероятность корректного результата с первого раза и обеспечивает обратную связь для самокоррекции. Это снижает нагрузку на проверку и повышает качество системы.
Böckeler выделяет два направления контроля:
* guides (предвходящий контроль) — направляет агента до начала работы;
* sensors (обратная связь) — анализирует результат после работы и помогает самокоррекции.
По способу выполнения контроль делится на:
* детерминированный (computational) — выполняется CPU (тестирование, lint, анализ типов и структуры). Он быстрый и надёжный;
* инференциальный (inferential) — семантический анализ, проверка кода с помощью LLM. Он медленнее, дороже и менее стабилен, но даёт более богатую семантическую оценку.
Важно сочетать обратную связь и предвходящий контроль: без обратной связи агент будет повторять ошибки, без предвходящего контроля не сможет оценить эффективность правил.
HackerNoon описывает harness как среду работы агента. Она определяет, что агент может найти, какие инструменты и права имеет, какие процессы пройти и какие проверки выполнить. Цель среды — не предоставить агенту неограниченную самостоятельность, а сделать правильные действия более простыми, а опасные — более сложными.
Рассмотрим подробнее элементы контроля:
Context (контекст). Система должна быть понятной. Код‑репозиторий должен содержать информацию о границах сервисов, ответственных лицах, API, договорах данных, руководствах по эксплуатации, ограничениях и текущих планах. Вместо многостраничных инструкций рекомендуется использовать краткий входной файл, ссылающийся на структурированные источники с контролем версий. OpenAI использует подход с входным файлом примерно из 100 строк, ведущим к более подробным документам.
Skills (навыки). Речь идёт о превращении экспертных практик в повторно используемые возможности. Навык включает набор процедур, контекст, разрешённые инструменты, ожидаемые результаты и проверку качества. Примеры навыков: миграция баз данных, изменение API, обновление зависимостей, расследование инцидентов, проверка готовности к выпуску, анализ затрат в облаке. Например, навык миграции базы данных должен включать анализ совместимости, план отката, тестирование миграции и проверку наблюдаемости.
Boundaries (границы). Агент должен иметь ровно те права, которые необходимы для выполнения задачи. Например, агент по устранению неполадок — только права на чтение данных телеметрии, агент по генерации кода — возможность записи в ветку, но не слияния, агент по развёртыванию — возможность подготовки изменений с обязательным ручным утверждением перед изменением производственной среды. Здесь применяется принцип минимальных привилегий к агентам.
Verification (проверка). Приоритет отдаётся детерминированным проверкам. Необходимо оперативно выполнять быстрые и повторяемые проверки (тестирование, проверка типов, lint, policy‑as‑code, сканирование безопасности, проверка архитектурных правил) при каждом изменении. Вопросы, на которые детерминированные инструменты не могут ответить (например, соответствует ли дизайн намерению, описывает ли документ риски), передаются на проверку ИИ. Порядок такой: детерминированные проверки → самокоррекция агента → человеческое решение. Рекомендуется записывать сообщения об ошибках пользовательского lint в виде указаний по исправлению («положительное внедрение подсказок»). Следует «сдвигать проверку влево» (keep quality left) — выявлять проблемы как можно раньше.
Learning (обучение). Повторяющиеся ошибки должны превращаться в системные улучшения. Например, если агент многократно ошибается при использовании API — создать правило проверки; если нарушает границы модулей — добавить структурный тест; если выявляются одни и те же риски при развёртывании — улучшить процесс выпуска.
Böckeler также описывает «рулевое управление» (操舵迴路): человек направляет агента через итерации, а AI помогает улучшать сами направляющие механизмы. Например, AI может помогать составлять структурные тесты или создавать черновики правил на основе наблюдаемых закономерностей.
Важно правильно оценивать эффективность работы системы. Нельзя измерять её по количеству строк кода, числу подсказок или количеству PR, созданных агентом. Нужно смотреть, стала ли система доставки лучше. Для оценки можно использовать такие показатели:
* процент первого успешного прохождения проверки (доля изменений агента, которые проходят проверку без серьёзных доработок);
* уровень ручного вмешательства;
* частота дефектов и откатов;
* частота нарушений архитектуры;
* время от одобренного плана до безопасного слияния;
* уровень покрытия доказательствами (есть ли тесты и описание рисков для изменений);
* актуальность направляющих механизмов.
Подход соответствует напоминанию DORA: важно не то, кто написал больше кода, а то, стал ли процесс доставки более стабильным и надёжным.
По мнению Böckeler, люди обеспечивают согласование с целями организации, понимание того, что является «хорошим», и чувство ответственности. Агент не обладает социальной ответственностью, интуицией и организационными знаниями. Задача направляющих механизмов — формализовать опыт старших инженеров в виде чётких правил, но это возможно лишь до определённого предела. Хорошие направляющие механизмы не должны стремиться к полному устранению человеческого участия — они должны направлять усилия людей туда, где требуется принятие решений.
Конкурентное преимущество будет у направляющих механизмов, а не у моделей: модели будут становиться мощнее и взаимозаменяемыми, а среда, обеспечивающая надёжную доставку, — это собственный актив команды. Самая сложная задача — «поведенческие направляющие» (行為支架): подтверждение того, что приложение действительно работает в соответствии с требованиями. Сейчас многие высокоавтономные команды полагаются на техническое задание и тесты, сгенерированные AI, но доверять тестам, написанным AI, недостаточно.
Подписаться в Макс
