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

Ещё недавно спор про coding-агентов сводился к тому, какая модель лучше пишет код. Сейчас интереснее другой вопрос: почему команда, у которой агент генерирует в разы больше diff’ов, не получает пропорционального роста поставленной ценности? Ответ всё чаще звучит не про модель, а про среду вокруг неё: контекст, права, тесты, аудит, наблюдаемость и точки остановки.

Это и есть harness engineering — проектирование инженерной обвязки, в которой агент работает. Не «промпт получше», а исполняемая среда: какие команды можно запускать, какие файлы нельзя менять, какие проверки независимы от агента, что логируется, когда требуется человек и как воспроизвести сессию.

Главный тезис: узкое место сместилось с генерации на доверие, проверку и сопровождение агентных изменений. Ниже — разбор, почему зелёный CI перестал быть доказательством, из чего состоит harness, где он ломается и что проверять в первую очередь.

1. Verification debt: зелёный CI больше не доказательство

Начнём с боли, которая проявляется раньше всего. Агент создаёт изменения быстрее, чем команда успевает их понять, проверить и принять ответственность за merge. Это не «медленное ревью» в старом смысле. Это долг: изменения приняты, но не поняты; тесты зелёные, но не доказывают поведение; ответственность формально есть, а фактического понимания нет.

Цифры из разных срезов 2026 года показывают одну и ту же картину. В опросе Qodo (500 разработчиков и 300 engineering-лидеров) и разработчики, и руководители назвали review/validation AI-кода главной проблемой delivery pipeline — по 26% в обеих группах. Sonar фиксирует, что 96% разработчиков не полностью доверяют функциональной корректности AI-кода, при этом 58% используют AI для business-critical сервисов. Temporal: 85,5% хотя бы частично доверяют выводам агентов, но лишь 24,7% доверяют полностью; безопасность — главный барьер полной автономии для 39,5%.

Дальше — телеметрия, которая объясняет цену. Faros AI при высокой AI-адопции наблюдал churn +861%, incidents-to-PR +242,7%, рост дефектов на разработчика с 9% до 54%, median review time +441,5%, PR без ревью +31,3%. Harvard working paper на данных 718 компаний: LOC на работника +30%, но разрешение issues/epics статистически не выросло; время PR→merge +49%, доля PR на доработку почти удвоилась. Bain: разработчики выполняют на 21% больше задач, но время на ревью AI-вывода выросло примерно на 91%.

Это опросы и телеметрия, а не лабораторный эксперимент. Но причинно-следственная связь читается: генерация масштабируется вычислениями, а ревью — людьми, контекстом и вниманием. Если насос стал мощнее, а труба та же, давление растёт не там, где ждали. Verification debt накапливается не в момент генерации, а в момент merge: команда принимает изменение, которое не может уверенно проверить.

Граница применимости: в маленьких командах с коротким циклом обратной связи и сильными тестами эффект может быть мягче. В legacy-системах с неявными инвариантами — жёстче. Проверять стоит не по одному числу, а по набору: review time, revert rate, incident rate, доля PR на доработку, churn. Если генерация растёт, а merge latency и incidents растут быстрее — вы уже платите verification debt.

2. Harness как инженерный объект, а не «обвязка»

Prompt engineering заканчивается там, где начинается исполнение. Harness — это то, что превращает модель в инженерного агента: инструменты, доступ к файлам, shell, тесты, политики, sandbox, логи, память и human gates. В исследовании Code as Agent Harness это описано как исполняемая основа: reasoning, action, environment modeling, verification, memory и multi-agent coordination. Код здесь — не только результат, но и среда, в которой агент действует.

Практически harness отвечает на вопросы:

• какие команды агент может запускать, а какие только предлагать;

• какие файлы и директории защищены от записи;

• какие тесты считаются oracle, а какие агент может добавлять;

• что логируется: tool calls, file writes, shell-команды, внешние доступы;

• когда нужен human approval и кто владеет merge-решением;

• как воспроизвести сессию в чистом контейнере.

Таблица компромиссов:

Псевдокод policy gate:

python

def pre_merge_gate(diff, risk_score, changed_paths):
    if any(path in PROTECTED_TESTS for path in changed_paths):
        if modifies_assertions(diff) or removes_tests(diff):
            return Block("protected tests changed")
    if risk_score > HUMAN_APPROVAL_THRESHOLD:
        return RequireHuman("high blast radius")
    if not has_machine_readable_evidence(diff):
        return Block("no reproducible evidence")
    return Allow()

Антипаттерн — «AGENTS.md и надежда». Команда пишет большой файл правил, считает, что harness готов, а на деле правила не исполняются. Harness — это не документ, а набор ограничений и проверок, которые нельзя обойти промптом. Если правило можно нарушить, но нельзя обнаружить нарушение — это не guardrail, а пожелание.

Наблюдаемость здесь не «лог ради лога». Нужен machine-readable отчёт: какие команды запускались, какие тесты прошли, какие файлы изменены, какие внешние доступы были. Без этого нельзя ни разобрать инцидент, ни сравнить harness-версии. Воспроизводимость — pinned commit, Docker/контейнер, фиксированный harness, опубликованные trajectories и verifier output.

3. Контекст и правила: AGENTS.md — не серебряная пуля

Соблазн очевиден: дать агенту весь репозиторий, индексы, память и большой файл правил. Но контекст — это не бесплатный ресурс. AGENTbench показал тонкую картину: агенты обычно следуют упомянутым в AGENTS.md инструментам и инструкциям, но избыточные или ненужные требования могут ухудшать решение задачи и увеличивать стоимость. LLM-сгенерированные context files в среднем снижали success rate и увеличивали inference cost более чем на 20%; developer-written файлы давали небольшой прирост, но также увеличивали число шагов и стоимость.

При этом adoption широкий. Galster et al. на 2 853 GitHub-репозиториях зафиксировали, что context files доминируют, AGENTS.md становится де-факто межинструментным стандартом, но Skills, Subagents, Hooks и MCP применяются редко. Qodo: 42,6% разработчиков используют централизованные context/rules-системы, но лишь 35% говорят, что агенты всегда следуют организационным стандартам; 43% лидеров называют недостаточный контекст существенным пробелом.

Здесь есть противоречие, которое не стоит сглаживать: context files стали стандартом де-факто, но их ценность не автоматическая. Совместная интерпретация: важны минимальность, точность и способ enforcement. Если правило можно выразить проверкой — лучше выразить его проверкой. «Пиши чистый код» — это не harness. «Линтер, тесты, запрет менять protected tests, обязательный review test diff» — это harness.

Практический вывод: контекст должен быть коротким и операциональным. Вместо пересказа wiki — ссылки на канонические документы и исполняемые проверки. Вместо «всегда используй библиотеку X» — allowlist зависимостей и CI-проверка. Вместо «не ломай архитектуру» — архитектурные тесты и import boundaries. Граница: для исследовательских задач с высокой неопределённостью жёсткие правила могут мешать; там нужен более свободный harness, но с более сильным human gate.

4. Тесты как oracle: агент не должен быть судьёй

Самая опасная failure mode — не «агент не умеет», а «агент меняет поведение и чинит тесты под новое, неверное поведение». Addy Osmani называет это главной агентной failure mode: зелёный CI после массового редактирования тестов ничего не доказывает. Практическая рекомендация — читать test diffs раньше кода и использовать mutation testing.

Это не частная проблема. OpenAI в июле 2026 отозвало рекомендацию использовать SWE-Bench Pro после аудита, оценившего примерно 30% public tasks как broken — из-за overly strict tests, underspecified prompts, low-coverage tests и misleading prompts. DeepSWE показала, что verifier из merged PR может отклонять корректные альтернативные решения или пропускать неполные: расхождение независимого judge с verifier составило 32,4% для SWE-Bench Pro против 1,4% для DeepSWE.

Вывод: вопрос не «можно ли агенту трогать тесты», а какая независимая oracle определяет правильность. Альтернативы:

• Protected tests — существующие тесты нельзя ослаблять; агент может предлагать новые, но не менять assertions. Плюс: простая защита. Минус: inherited tests могут быть слишком узкими, flaky или противоречить заданию.

• Hand-written functional verifiers — проверяют наблюдаемое поведение, а не структуру патча. Плюс: устойчивее к альтернативным решениям. Минус: дорого писать и поддерживать.

• Mutation testing — проверяет, что тесты ловят изменения поведения. Плюс: выявляет слабые тесты. Минус: стоимость прогонов.

• Независимый judge — отдельная модель или человек. Плюс: может оценить альтернативы. Минус: сам небезупречен; расхождение с verifier может быть высоким.

Границы: для legacy-кода с неявными инвариантами ни один из вариантов не даёт полной гарантии. Проверять стоит на практике: если агент массово редактирует тесты, а CI зелёный — это красный флаг, а не успех. Если verifier отклоняет корректное альтернативное решение — это тоже failure mode. Поэтому нужны несколько прогонов, доверительные интервалы и оценка не только pass rate, но и cost, latency, tool calls и regressions.

5. Длинный горизонт, состояние и мультиагентность

Чем длиннее задача, тем важнее состояние. Temporal называет tracking state главной помехой более активному использованию агентов — 35,7% ответов, выше debugging и стоимости токенов; 41,1% сталкиваются с агентными проблемами ежедневно или чаще. Агент теряет цель, дублирует работу, забывает принятые решения или не знает, что изменилось в репозитории после начала задачи.

NL2Repo-Bench подтверждает это экспериментально: при генерации целого Python-репозитория из спецификации лучшие системы не превышали 40,5% среднего test pass rate. Типовые отказы — преждевременное завершение из-за самоуверенности, потеря глобальной архитектурной согласованности, хрупкое управление зависимостями и межфайловая несогласованность. Это не «модель глупая», это failure mode длинного горизонта: среда не удерживает состояние и не проверяет согласованность.

Мультиагентность выглядит как ответ, но часто создаёт новую проблему. October Bus появился именно потому, что при нескольких агентах человек становится integration layer: копирует контекст, проверяет, кто владеет задачей, и вручную передаёт diffs. Проект предлагает durable messages, task ownership, receipts, leases и human escalation, но сам признаёт, что это draft 0.1, а не production standard. SAP описывает production-деплой shared organizational memory: capture через hooks, human approval, curation, security gates, provenance и retrieval через MCP. Авторы прямо отмечают, что memory poisoning и injection risk не устранены полностью.

Trade-off: multi-agent может покрывать больше деталей, но стоит «much more» — это отмечают и в обсуждении dynamic workflows Anthropic, где lead agent сам строит оркестрацию и запускает subagents. Противоположная позиция: сначала построить надёжный single-agent loop — маленькие diffs, строгий CI, воспроизводимые проверки, понятные права. Для одного репозитория и одной сессии часто полезнее session store, permissions и reproducible tests, чем координационная шина.

Граница: multi-agent оправдан, когда задача действительно распадается на независимые подзадачи с чёткими контрактами. Если контрактов нет, координация становится дороже самой работы. Проверять стоит на метриках: cost per merged change, review effort, revert rate, incident rate. Если multi-agent увеличивает pass rate, но удваивает review burden — вы оптимизируете не ту метрику.

6. Воспроизводимость и evals: результат принадлежит связке

Команды не могут доверять одному leaderboard-числу. Результат принадлежит связке «модель + harness + окружение + scoring». OpenHands подчёркивает, что scaffold choice может стоить 11–15 пунктов производительности. OpenAI показала, что даже «улучшенный» benchmark может содержать около трети сломанных задач. Исследование Don’t Blame the Large Language Model: при фиксированной модели 35 релизов Qwen Code не дали статистически значимого роста resolve rate; поздние версии потребляли почти вдвое больше токенов и tool calls.

При этом harness можно улучшать измеримо. Agentic Harness Engineering описывает замкнутый цикл с component/experience/decision observability: pass@1 на Terminal-Bench 2 вырос с 69,7% до 77,0% за десять итераций при фиксированной модели. Это важный сигнал: наблюдаемость и falsifiable harness-изменения могут давать больше, чем «слепые» обновления модели.

Что проверять в первую очередь:

• pinned commit, Docker/контейнер, фиксированный harness;

• опубликованные trajectories, patch и verifier output;

• несколько прогонов и доверительные интервалы;

• функциональные verifier’ы вместо тестов, наследуемых из одного конкретного PR;

• оценка cost, latency, tool calls и regressions, а не только pass rate.

Антипаттерн — сравнивать harness-версии по одному прогону на одном наборе задач. Граница: строгие evals дороги, но дешевле, чем инциденты в проде. Если вы не можете воспроизвести сессию, вы не можете утверждать, что улучшили harness, а не подкрутили условия.

7. Практика: что делать разработчику и архитектору

Начните с вопроса: где в вашем процессе агентное изменение становится непроверяемым? Дальше — чек-лист.

• Есть ли protected tests и запрет на ослабление assertions?

• Читаются ли test diffs раньше code diffs?

• Есть ли machine-readable отчёт о командах, тестах и tool calls?

• Есть ли policy gates, которые нельзя обойти промптом?

• Определён ли human gate по риску, а не «на каждую строку»?

• Воспроизводится ли сессия в чистом контейнере?

• Сравниваются ли harness-версии на нескольких прогонах?

• Метрики: cost per merged change, review effort, revert rate, incident rate, architectural drift?

• Есть ли allowlist инструментов и внешних доступов?

• Есть ли план на memory poisoning и injection risk?

• Для multi-agent: есть ли task ownership, receipts, leases и escalation?

• Для legacy: есть ли независимая oracle, а не только inherited tests?

Мини-кейс. Команда внедряет агента в legacy-сервис. Первый шаг — не «дать весь репозиторий», а ограничить blast radius: маленькие diffs, protected tests, запрет на изменение CI-конфига, audit log, human approval для high-risk путей. Второй — отделить oracle: functional verifier’ы на ключевые сценарии, mutation testing на критичные модули. Третий — измерять не pass rate, а cost per merged change и review effort. Если через две недели review time вырос, а revert rate нет — скорее всего, вы добавили генерации, но не добавили проверяемости.

Типичные антипаттерны:

• «AGENTS.md на 500 строк» вместо исполняемых правил;

• «AI-review» как единственный арбитр корректности;

• «разрешить агенту править тесты, чтобы CI был зелёным»;

• «multi-agent, потому что модно», без контрактов и ownership;

• «обновить harness и замерить один раз»;

• «оптимизировать pass rate», забывая про review burden и incidents.

Выводы

1. Узкое место — verification, а не generation. Рост генерации не превращается в рост поставленной ценности, если review time, churn и incidents растут быстрее.

2. Harness — первоклассный инженерный объект. Контекст, права, тесты, наблюдаемость и точки остановки нужно проектировать, версионировать и измерять.

3. AGENTS.md полезен, но не достаточен. Правила должны быть минимальными, точными и, где возможно, исполняемыми.

4. Агент не должен быть финальным судьёй. Нужна независимая oracle: protected tests, functional verifiers, mutation testing, несколько прогонов.

5. Длинный горизонт и shared state — наименее решённая часть. NL2Repo-Bench и практика October Bus показывают, что координация и память остаются хрупкими.

6. Multi-agent — не значение по умолчанию. Сначала надёжный single-agent loop с маленькими diffs и строгим CI; multi-agent — только при реальной декомпозиции.

7. Метрики должны быть инженерными. Cost per merged change, review effort, revert rate, incident rate и architectural drift важнее одного pass rate.

Открытые вопросы

Как измерять качество harness, а не только модели? Где проходит граница human-on-the-loop: какие изменения действительно требуют человека, а какие можно отдать policy gates? Как строить независимую oracle для legacy-кода, где инварианты не описаны? Как защищаться от memory poisoning, не превращая память в бесполезный склад? И главное: если генерация продолжит дешеветь, а ревью — нет, какие архитектурные решения изменят это соотношение?

Буду рад услышать, какие harness-практики у вас уже работают, а какие ломаются на реальных репозиториях. Особенно интересны кейсы, где пришлось откатить агентные изменения не из-за ошибки модели, а из-за того, что среда не дала достаточно доказательств корректности.