Модель одна, результат разный

Разница между командой, которая получает от кодинг-агентов работающий код в продакшене, и командой, которая получает шум, почти никогда не в модели. Модель у всех одна и та же — с точностью до недели релиза. Разница в том, что построено вокруг неё: какие инструменты агент видит, какой контекст ему подаётся, где стоят границы и что происходит с ошибкой после того, как она случилась.

Ори Шошан, tech lead в Cyera, в разговоре «The Agent Trick That Stopped Hallucinations Cold» отвечает на вопрос «что определяет качество агента» без обиняков: «It is the harness. Yeah. It is the harness kind of with the tools». Его картина мира такая: модель — это операционная система, сверху лежат инструменты и оснастка, а контекст зажат между ними. Оснастка — это набор tools, системный промпт, контекст и интерфейс запуска (у них — Slack и Sentry). Именно она вносит в поведение агента ограничения и детерминизм, которых у модели самой по себе нет. У Cyera на этой конструкции живёт около тридцати агентов, построенных примерно тридцатью разработчиками, с несколькими сотнями пользователей внутри компании.

Дру Нокс, head of product & design в Tessl, назвал свой доклад «Why Your Coding Agents Need a Harness, Not a Prompt» — и это не риторический приём. Его тезис: работа сместилась с написания кода на построение и наблюдение за петлями, которые сами проверяют код. Цитата из доклада: «Instead of focusing on writing code… you focus on building and monitoring loops that are themselves reviewing the code».

Насколько далеко это заходит, видно по цифрам Tessl, которые приводит Роб Уиллоуби, AI engineering lead: 65–70% всех PR компании проходят через внутреннюю агентную фабрику, а из кода самой фабрики человек когда-либо смотрел в PR около 5%. Остальные 95% никто не видел. Так работает компания примерно на 24 инженера.

Дисциплина, которая всё это описывает, ещё не устоялась даже терминологически. Нокс рассказывает, что за две недели название его доклада менялось четыре раза: harness engineering, loop engineering, software factories, meta engineering — примерно про одно и то же. За 2,5 недели после написания доклада появилось три новых термина. Мы будем называть это оснасткой — по смыслу это ближе всего к тому, что в цеху надевают на станок, чтобы он делал деталь одинаково при каждом запуске.

Патрик Дебуа, AI product engineer в Tessl и один из тех, кого называют отцом DevOps, формулирует ту же мысль на уровне организации: «We're not building the thing. We're building the thing that builds the thing». И настаивает, что это отдельная функция. Одной просьбы «научитесь лучше промптить» здесь мало: как developer enablement не случается сам собой и требует команды, так и agent enablement.

Серия состоит из четырёх частей: сама оснастка, agent enablement как дисциплина, среда исполнения и тёмная фабрика с планом старта.

Оговорка про цифры. Всё, что приведено в серии, названо самими спикерами со сцены или в подкасте. Часть цифр они сами помечают как оценочные — где это так, я это указываю. Там, где спикеры друг другу противоречат, я показываю противоречие и оставляю выбор читателю.

Harness: почему промпта недостаточно

Что вообще считать оснасткой

Самое операциональное определение даёт Ори Шошан (Cyera, «The Agent Trick That Stopped Hallucinations Cold»). У них harness — это конфигурация агента целиком: набор инструментов, системный промпт, контекст и интерфейс запуска. Модель в этой схеме — операционная система, поверх неё лежат tools и harness, а контекст зажат между ними. Роль оснастки — вносить ограничения и детерминизм: модель по своей природе вероятностна, оснастка сужает пространство, в котором она может ошибиться.

Гай Поджарни (Tessl, подкаст «The Tessl Agent: Build Your Software Factory on Autopilot») даёт ту же конструкцию с продуктовой стороны: продукт в эпоху агентов состоит из четырёх компонент — набор tools, набор skills (упакованная экспертиза), harness (UX и связка) и control center для коллаборации. Его аргумент против позиции «мы просто отдадим tools, а harness пусть будет чужой»: без своего harness вендор не видит, что именно пошло не так у пользователя, и не может это починить.

Отсюда первое разграничение. Промпт — это одно сообщение внутри одного запуска. Модель — это то, что ты не контролируешь и что сменится через три месяца. Оснастка — это всё остальное, и она твоя. Промпт живёт до конца сессии, оснастка живёт в репозитории.

Три петли

Дру Нокс (Tessl, «Why Your Coding Agents Need a Harness, Not a Prompt») раскладывает оснастку на три вложенные петли.

Inner loop — то, что агент гоняет сам, пока пишет PR: компиляция, линтеры, юнит-тесты, типы. Это то, что даёт автономию — способность агента дойти до правильного ответа без того, чтобы человек его поправлял.

Outer loop — дорогие проверки на границе PR, которые бессмысленно гонять в цикле: агентное код-ревью, агентный QA (агент прокликивает продукт), mutation testing. Это то, что даёт автоматизацию — возможность вообще не смотреть на результат.

Meta loop — петля, которая наблюдает за первыми двумя и чинит их. Она даёт качество.

Ключевая мысль Нокса: работа инженера переезжает в третью петлю. «Instead of focusing on writing code… you focus on building and monitoring loops that are themselves reviewing the code».

Inner loop: можно быть занудным так, как раньше было нельзя

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

Роб Уиллоуби (Tessl, «Inside the Dark Factory») говорит об этом же с другой стороны: «Agents are fine with annoying and finicky. They can very happy to go bang their heads against the wall». Занудная проверка, которая для человека — трение, для агента просто сигнал.

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

Outer loop: то, что заменяет человеческое ревью

На границе PR ставится то, что дорого и медленно. Нокс отдельно оговаривает режим работы: в идеале outer loop зелёный с первого раза. Это финальные ворота. Рабочим инструментом агента остаётся inner loop. Если агент регулярно узнаёт о проблеме из outer loop — проверка стоит не там, где должна, и её надо сдвигать влево.

Meta loop: ошибиться можно только один раз

Meta loop сидит в фоне, читает логи агентов, комментарии в PR и упавшие CI-чеки — и сам предлагает правки в inner и outer loop. Принцип Нокса: «Never tell the agent more than once how to do a thing before it gets codified». Второй раз объяснять одно и то же — баг в оснастке.

У Уиллоуби это оформлено в процесс: каждую ночь идёт automatic promotion — комментарии из агентного ревью анализируются на предмет того, можно ли превратить их в дешёвую детерминированную проверку и сдвинуть влево.

Verifiers — дешёвые LLM-линтеры

Именно на границе inner и outer loop у Tessl живёт конструкция, вокруг которой держится вся экономика. Verifier — это одно утверждение на естественном языке: по конкретному диффу оно разрешается в «да» или «нет». Примеры из доклада: «каждый JSX-элемент имеет ARIA-атрибут», «логгер используется только наш».

Устройство важнее формулировки:

• триггер детерминированный — glob-паттерн по файлам, никакой модели в решении «применять ли проверку»;
• оценка — LLM-as-judge по диффу;
• один LLM-вызов на один verifier, чтобы модель не жонглировала конфликтующими приоритетами.

Ограничение Нокс проговаривает сразу: всё, что можно сделать полностью детерминированным, надо делать детерминированным. Verifier — это для «вкуса», который не выражается в regex.

Уиллоуби добавляет разделение ролей, которое стоит запомнить: agentic review ловит неизвестное, verifiers — известное. Catch-all агентное ревью находит то, чего вы не предвидели. Verifier гарантирует, что уже опознанная ошибка не повторится никогда.

Экономика: $25 против $0,30

СО СЦЕНЫ: Почему ревью надо разбирать на verifiers

• Кто и где: Дру Нокс, head of product & design, Tessl — «Why Your Coding Agents Need a Harness, Not a Prompt», AI Native DevCon 2026.
• Что показали: сравнение двух способов проверять PR — полный агентный ревью против набора узких verifiers на том же материале.
• Цифры: полный агентный ревью одного PR — порядка $25 (оценка на Claude Code). Свыше 100 verifiers на каждый PR — порядка $0,30 за целый день ревью. Сам Нокс помечает цифры как «directionally correct, don't hold me to it».
• Что это меняет: главный вопрос — что можно вытащить из дорогого ревью в дешёвую проверку и сдвинуть влево. Разрыв в стоимости достигает двух порядков.

Цифры звучат несопоставимо, и это правда так, но сравнивать их напрямую нельзя: $25 — за один PR, $0,30 — за день работы всей батареи верификаторов. Чтобы посчитать экономику у себя, разложи её на три вопроса.

Первый: сколько у вас PR в неделю и куда это движется. У Tessl — порядка 600–700 PR в неделю на ~24 инженера, причём три-четыре недели подряд объём рос на 30% к предыдущей неделе. При таком профиле $25 за PR превращаются в бюджет, который видно из бухгалтерии. При 30 PR в неделю бюджет не складывается, и оптимизировать пока нечего.

Второй: какая доля замечаний повторяется. Verifier окупается тем, что кодифицирует уже опознанный класс ошибок. Если ваши комментарии в PR каждый раз разные, вы ещё в фазе catch-all агентного ревью. Батарея verifier'ов понадобится позже. Если одно и то же замечание вы пишете третий раз — по принципу Нокса это уже долг.

Третий: где именно проверка срабатывает. Один и тот же чек в inner loop и в outer loop стоит принципиально разного. В inner loop он экономит цикл целиком. В outer loop он обнаруживает уже потраченную работу.

Слой	Что там стоит	Порядок стоимости	Что даёт
Inner loop	компилятор, линтеры, юнит-тесты, verifiers	~$0,30 в день на батарею из >100 verifiers	автономия
Outer loop	агентный ревью, агентный QA, mutation testing	~$25 на PR	автоматизация
Meta loop	анализ логов, PR-комментариев, упавших CI	фоновая	качество

Отдельный сюжет — оптимизация модели. Нокс (подкаст «The Tessl Agent») считает попытку приучить всех выбирать нужную модель проигрышной игрой: люди не хотят об этом думать, и заранее непонятно, окажется ли задача сложной. Оптимизировать надо вынесенные в отдельный рабочий процесс повторяющиеся задачи — там можно прогнать eval на маленькой или открытой модели и принять осознанный размен. Его формулировка размена: «на 5% хуже, но на 80% дешевле — я готов». И вывод: «The work of delegating… is also the work of cost optimization».

Инструменты: whitelist вместо blacklist

У Ори Шошана (Cyera) оснастка на уровне инструментов устроена так: единственное, чего агенту не дают, — bash. Вместо него 50–60 узких инструментов с известной поверхностью атаки. Общий для всех агентов набор вышел на плато около 60 tools.

И обязательный элемент, который легко пропустить: escape hatch — инструмент, которым агент говорит «я хотел сделать X, но не могу». Без него агент начинает использовать имеющиеся инструменты не по назначению, и Шошан называет это худшим режимом отказа: его не видно снаружи, он вскрывается только при чтении thinking-токенов.

Второй элемент его оснастки — форма вывода. Агент выдаёт список блоков, где каждое утверждение снабжено ссылкой на источник. Это даёт две вещи: цитаты, которые можно проверить, и возможность прогнать каждое утверждение отдельной моделью с чистым контекстом, спросив «подтверждается ли это данными». Галлюцинаций резко меньше — потому что в проверяющем запросе нет шума. Его формулировка: «Attention is the scarce resource».

Что из оснастки переживёт смену модели

Здесь Нокс даёт полезное разделение (ответ на вопрос из зала). Скиллы и хуки, написанные ради затыкания конкретных слабостей текущей модели, живут пару месяцев и выбрасываются при обновлении. Долгоживёт только описание рабочих процессов, стандартов и политик — то, что понадобится любому уровню интеллекта. «Eventually you'll be left with mostly just describing your workflows, your standards, your policies».

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

Когда за это вообще браться

Нокс называет порог явно: harness engineering имеет смысл, когда вы уже держите несколько параллельных сессий и агент регулярно решает лёгкие и средние задачи с первого раза. До этого порога вы будете строить оснастку вокруг проблемы, которой у вас ещё нет. И честная оговорка от него же: у приёма есть цена — организационная трансформация и поддержка руководства. Вечера с конфигами для этого мало.

Коротко

• Оснастка — это конфиг агента целиком: инструменты, системный промпт, контекст, интерфейс запуска. Промпт живёт до конца сессии, оснастка живёт в репозитории (Шошан, Cyera).
• Три петли: inner даёт автономию, outer — автоматизацию, meta — качество. Работа инженера переезжает в третью (Нокс, Tessl).
• Verifier — одно утверждение, детерминированный триггер, один LLM-вызов. Agentic review ловит неизвестное, verifiers — известное (Нокс и Уиллоуби, Tessl).
• Разрыв в стоимости между дорогим ревью и дешёвыми проверками — около двух порядков ($25 за PR против порядка $0,30 за день), поэтому стратегия — переносить проверки влево.
• Инструменты — whitelist с известной поверхностью атаки и обязательный escape hatch: без него агент использует инструменты не по назначению, и этого не видно снаружи.