Harness Engineering: среда для автономного агента

Harness — это не промпт и не модель помощнее. Это среда вокруг агента: набор источников правды, которые он читает на старте и по ходу. Идея та же, что в уроке про harness-инженерию, но взгляд не на in-app цикл, а на саму разработку — как привести проект в состояние, где кодинг-агент ведёт задачу почти без надзора. Среда собирается из пяти слоёв — от глобального (как ты вообще работаешь с агентом) до проектного (правила именно этого репозитория) и кросс-сессионной памяти. Чем больше слоёв на месте, тем меньше агент додумывает и тем реже ломается на ровном месте.

Харнес превращает «задачу» в маршрут из четырёх фаз: A — постановка и рамки (одна нить = одна задача, проверка рецептов, при необходимости план); B — дизайн (эскиз до кода, ADR на решения, чтение уроков границы); C — цикл реализации (TDD, прогон sensors, live-update, /wrong, эскалация); D — закрытие (verify, ритуал, doc-sync, commit, handoff). Это не строгая линия 0→24. Человек подключается ровно в четырёх точках — дать задачу, апрувнуть эскиз, сказать «неправильно», сказать «коммить». Всё остальное агент ведёт сам. Покрутите эксплорер ниже: фильтруйте по фазам, открывайте детали шага и прогоняйте сценарии — большая фича, багфикс, docs-правка, коррекция, эскалация.

Самый частый провал харнеса — спутать «записано в правилах» с «реально соблюдается». Барьер форсится механически: pre-commit и CI не дадут зашипить код, не прошедший проверку. Конвенция держится только на дисциплине агента — описана в AGENTS.md, но никто не проверит. Условный шаг срабатывает по триггеру и часто пропускается. Хорошая новость: барьеры — готовые кросс-стековые инструменты. Границы импортов держат dependency-cruiser / import-linter, мёртвый код — knip / ts-prune, циклы — madge, вложенность и размер — eslint (max-depth, max-lines). Что не покрыто — добавляешь своим скриптом-проверкой в pre-commit. На что нельзя поставить барьер, на то нельзя положиться надолго.

Ядро автономности — lessons-ledger: механизм, который превращает твои коррекции в код, а не в забытый чат. Сказал агенту «неправильно» → команда /wrong запускает normalize, которая разводит развилку. Computational-урок (ошибку можно поймать машиной) → правка сенсора: новое правило линтера, проверка типа. Inferential-урок (нужно суждение) → markdown-файл, который агент читает перед задачей на этой границе. Отдельный шаг maintain промоутит созревшие inferential-уроки в сенсоры. Метрика здоровья — сколько уроков выпущено в барьеры, а не размер тетрадки: цель — чтобы знание затвердевало в машинные проверки, а не копилось текстом.

/wrong "<mistake>"
  → normalize:
      machine-catchable? → sensor       # computational (barrier)
      needs judgement?   → lessons/<boundary>/  # inferential (nudge)
  → maintain: matured inferential → promote → sensor
health metric = lessons promoted to sensors, NOT notebook size

Этот рецепт — хаб. За ним идёт серия, где каждая фаза rollout-плана разворачивается в отдельный рецепт с копируемыми промптами. Входная дверь — «четыре режима разработки с ИИ» (A/B/B+/C): мета-решение, сколько ИИ вообще нужно проекту. Не всем нужен полный agent-first — харнес обязателен для режимов B+/C и почти не нужен для A/B. Ниже — карта серии: от выбора режима и аудита до тиражирования. Каждая строка — отдельный рецепт; идите по фазам по порядку или сразу к нужной.

С чего начать, чтобы не утонуть? Порядок — от дешёвого и бесспорного к дорогому и спорному. Сначала ADR: зафиксировать выбор инструментов — это для людей, без сопротивления. Потом Definition of Done — один чек-лист, что значит «готово». Потом sensors — превратить DoD в машинные барьеры (pre-commit + CI). И только потом lessons-ledger — он окупается, когда барьеры уже есть и есть что в них промоутить. Каждый слой полезен сам по себе. Не нужно строить всё сразу: один реальный барьер сегодня ценнее идеального плана на квартал.