Оснастка для агентов

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

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

Ори Шошан, 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.

Дальше в статье — четыре раздела.

Раздел 1 разбирает саму оснастку: из чего она состоит, чем отличается от промпта и от модели, и почему её экономика считается иначе, чем экономика человеческого ревью — $25 за агентное ревью одного PR против ~$0,30 за целый день работы сотни верификаторов.

Раздел 2 — про agent enablement как дисциплину: что появляется в командах, кто за это отвечает, какие роли и метрики возникают.

Раздел 3 — про среду: изолированные десктопы для агентов, песочницы, репозиторий как объект автоматизации и данные, которые агенту нужно подать иначе, чем аналитику.

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

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

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 зелёный с первого раза. Это финальные ворота, а не рабочий инструмент агента. Если агент регулярно узнаёт о проблеме из 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») считает попытку приучить всех выбирать нужную модель проигрышной игрой: люди не хотят об этом думать, и заранее непонятно, окажется ли задача сложной. Оптимизировать надо вынесенные в отдельный workflow повторяющиеся задачи — там можно прогнать eval на маленькой или открытой модели и принять осознанный размен. Его формулировка размена: «на 5% хуже, но на 80% дешевле — я готов». И вывод: «The work of delegating… is also the work of cost optimization».

Инструменты: whitelist, а не blacklist

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

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

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

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

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

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

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

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

Коротко

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

Agent enablement: новая дисциплина

Что это такое

Патрик Дебуа, AI product engineer в Tessl, доклад «The Rise of Agent Enablement». Его исходная аналогия проста: developer enablement не случается сам собой. Никто не ждёт, что разработчики сами построят себе CI, платформу, документацию и paved roads — для этого выделяют людей и бюджет. С агентами ровно то же, но это ещё не осознано: от команд ждут, что оснастка вырастет сама, если разослать всем лицензии.

Его формулировка того, чем занимается такая функция: «We're not building the thing. We're building the thing that builds the thing».

Дебуа делит работу на три слоя:

• Enable the agents — техника: контекст, инструменты, скиллы, guardrails, среда исполнения. Ответственный уровень — инженер.
• Enable the team — процесс: как команда планирует, ревьюит, ретроспективит с агентами внутри. Уровень — тимлид.
• Enable the org — политика, бюджет, метрики, единые рельсы. Уровень — VP engineering.

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

Чем это отличается от developer experience

Разница не в списке артефактов — он похож. Разница в трёх вещах.

Потребитель другой. DevEx оптимизирует трение человека: сколько шагов до первого запуска, насколько понятна ошибка, приятно ли читать доку. Agent enablement оптимизирует то, что человеку безразлично: полнота машиночитаемого контекста, наличие CLI/API там, где у людей была кнопка, детерминированность вывода.

Обратная связь другая. У DevEx она социальная — опросы, жалобы, NPS. У agent enablement она в логах: где агент затупил, где переспросил, где взял не тот путь. Дру Нокс (Tessl) отдельно называет это третьей причиной, почему harness engineering тяжёл: пока сигналы лежат в логах локального агента, в чьей-то голове и на чьей-то машине, оптимизировать нечего. Пока workflow не переехал на поверхности, где всё сохраняется, чинить нечего.

Определение готовности другое. Дебуа: Definition of Done меняется — не только «код выехал», но и «как сработал агент». Ретро смещается с «были проблемы с кодом» на «были проблемы с системой». На планировании задачи делятся на два потока: достаточно отскоупленные — сразу в агентов, неопределённые — разговор людей. Его вопрос тимлиду: «My agents are team members too — how do you find the goal, the KPI, how do I measure the performance?»

Главная ошибка мышления

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

Честно говоря, это тяжело. Нокс описывает то же самое без прикрас: harness engineering — это unplanned work, и правильная реакция на ошибку агента — выбросить PR, придумать, что бы её предотвратило (тест, скилл, правило), и бросить кости заново. «It's like a slot machine. It's the worst kind of slot machine». И всегда есть аргумент «мы могли зашипить два часа назад, если бы просто поправили руками» — его тяжело нести боссу и клиентам.

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

Кто этим занимается: роли

Дебуа фиксирует несколько сдвигов.

AI product engineer. Граница между «что строить» и «как строить» размывается: тот, кто описывает поведение, всё чаще его же и реализует через агента.

Agent whisperer / context provider. Бывшая coding rockstar переезжает в роль «amazing context provider». Это не понижение — это перенос того же навыка на другой носитель.

Механик, а не автостроитель. Формулировка Роба Уиллоуби (Tessl, «Inside the Dark Factory»): инженер строит и обслуживает среду, в которой крутится фабрика, и дебажит, когда она сломалась. Это инженерия системного уровня — то, что раньше ждали от senior/staff/principal. Теперь это просят с первого дня даже от джунов: у них новый сотрудник добавлял verifiers на второй день работы.

Оговорка, которую Дебуа делает честно: не все хотят уходить от кода. Часть людей уйдёт именно в harness и loops — потому что там остался технический контент.

Владение «вкусом» переезжает в verifiers

СО СЦЕНЫ: Как staff-инженер масштабирует свой вкус

• Кто и где: Роб Уиллоуби, AI engineering lead, Tessl — «Inside the Dark Factory: AI That Ships Code Solo», AI Native DevCon 2026.
• Что показали: раньше staff-инженер удерживал качество своего куска кодовой базы через PR-ревью, доки и внутренние презентации — то есть через собственное время. Теперь он кодирует те же требования в verifiers.
• Цифры: новый сотрудник добавлял verifiers на второй день работы; свыше 100 verifiers прогоняется на каждый PR.
• Что это меняет: verifiers исполняют агенты всех сотрудников, а не только его собственные. Уиллоуби: «Suddenly your impact is now scaled across everyone». Культурно это, по его словам, самое важное — инженеры чувствуют, что вкус и качество остались за ними, а не ушли к модели.

Это же даёт ответ на вопрос «а что делать с сопротивляющимися». У Дебуа есть рабочий приём: инженеру, который говорит «ИИ не может то, что могу я», отвечать «отлично, запиши, что именно ты делаешь, чтобы агенты стали лучше». Их злость на качество вывода конвертируется в контекст и оснастку. Дебуа замечает, что появление технического слоя — harness, loops — заново зажгло тех, кто не подписывался на «промптинг и спеки».

Что получает платформенная команда

Дебуа («The DevOps Godfather on AI's Dark Factory Problem») перечисляет новые объекты, которые появляются у платформы/DevEx:

• skill registry — каталог скиллов с владельцами;
• eval-системы для контекста — способ проверять, что изменение контекста улучшило, а не ухудшило;
• guardrails именно для coding-агентов (не общие корпоративные политики по ИИ);
• identity — кто такой агент с точки зрения доступов;
• MCP gateway;
• agent observability по всей организации.

И условие, без которого этого не появится: нужен явный owner программы. Ограничение он тоже называет — консенсус двух команд о единой оснастке это тяжёлая брокеринг-работа, и реалистичный результат не «одна paved road», а каталог из 3–4 paved roads.

Отдельная боль — sprawl. Каждый пишет свой CLAUDE.md и копипастит из интернета; кто-то шарит скилл, кому-то он нравится на 99%, он его форкает — и дальше непонятно, какой брать. Что нужно, по Дебуа: владелец, версионирование, security-скан, тестируемость, модульность (чтобы расширяли, а не форкали) и регресс-тесты на скиллы и harness при смене модели. «As long as you don't have that testing and that repeatable thing in place, you will have that same problem». Внутри самого Tessl на момент доклада параллельно строилось 5–6 harness — и, по его словам, «выжить должны немногие».

Как это внедряют

Ори Шошан (Cyera) описывает adoption ровно как platform engineering: группа «AI captains» из 10–12 заинтересованных, воркшоп, и платформа, где завести нового агента — это скопировать конфиг-файл и Python-класс. Люди сами называют своих агентов и дают им личность, после чего агент становится «своим», и адопшн растёт. Его формула: «all carrots and no stick» и «Really making it safe is making it really easy». Со старта в 10–12 человек это выросло примерно до 30 агентов.

Найм Дебуа описывает как три части собеседования: (1) задача, где кандидату велят «идти вразнос» с ИИ; (2) разбор — объясни, почему это хорошее решение, тут проверяется инженерия; (3) готов ли делиться и работать в общем — солист или нет. Ищут системного мыслителя и открытость к обучению, не ML-экспертов. Ограничение: одного человека со всеми тремя навыками обычно нет, поэтому важно понимать, где ему нужен ментор.

Метрики и бюджет

Дебуа предлагает две метрики вместо token spend:

1. Сколько human touches всё ещё нужно, чтобы агент сделал правильно — должно падать.
2. Множитель от перехода solo → shared: одна правка общего контекста улучшает работу всех команд.

Его вывод: настоящие герои — те, кто контрибьютит в общие компоненты, а не «token billionaires».

Нокс даёт свой список того же жанра. Вниз: количество manual takeovers, количество человеческих комментариев в PR, количество раз, когда человек сам декомпозировал тикет. Вверх: доля PR, инициированных агентами без участия человека. По качеству порядок такой: сначала «не просаживать», потом «поднимать».

И про бюджет — Дебуа («Patrick Debois Maps the Patterns») предупреждает про рефлекс резать расход на токены: он ломает обучение организации. Правильно — телеметрия и FinOps для кодинг-агентов, отдельная команда на оптимизацию, обучение выбору модели, и лучший контекст/harness, потому что они сами по себе снижают расход. Аналогия: в раннем облаке каждая система была отдельной VM, пока не научились уплотнять. Практический совет — держать два разных бюджета: «на обучение людей» и «на полезное».

Паттерн, который объединяет всё

В том же разговоре Дебуа называет следующий уровень зрелости после continuous integration и continuous delivery — continuous learning: как быстро организация впитывает новую идею и меняет систему, даже если это означает переписать кодовую базу. Знание накапливается в контексте, скиллах и оснастке — и это и есть моат. «How fast can you learn? …the people who contribute to that metric are the ones really helping you».

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

Коротко

• Agent enablement — отдельная функция с явным владельцем, а не «научитесь лучше промптить». Три слоя: агенты (инженер), команда (тимлид), организация (VP) — Дебуа, Tessl.
• Отличие от DevEx: другой потребитель, обратная связь из логов вместо опросов, изменившееся Definition of Done («как сработал агент», а не только «код выехал»).
• Главная ошибка — чинить код вместо системы. Правильная реакция на ошибку агента — выбросить результат и починить то, что её породило (Дебуа, Нокс).
• Вкус staff-инженера кодируется в verifiers и начинает исполняться агентами всей компании — это то, что делает переход культурно приемлемым (Уиллоуби, Tessl).
• Метрики: human touches вниз, доля агентских PR вверх, множитель solo → shared. Резать бюджет на токены — рефлекс, который ломает обучение организации.

Среда: песочницы, десктопы, репозиторий

Оснастка не заканчивается на промпте и наборе инструментов. Агент должен где-то работать, что-то видеть и куда-то класть результат. Этот раздел — про три слоя среды: машину агента, репозиторий как объект автоматизации и данные.

Свой компьютер каждому агенту

Люк Марсден, CEO HelixML, доклад «Giving Every Agent Its Own Desktop». Тезис в одной фразе: «You wouldn't hire a team of software developers and ask them all to share one computer». Вывод — централизованный пул агентских машин на инфраструктуре компании вместо снежинок на ноутбуках.

Аргументы три:

• follow-the-sun — в Токио человек закончил, в Лондоне встал другой и продолжил работу того же агента;
• безопасность — агент не бегает по чьей-то персональной машине с личными кредами;
• воспроизводимость — среда одинаковая, и её чинят один раз для всех.

Возражение «централизация = отдать данные вендору» он снимает сразу: это общий контур, а не чужой. Свой Kubernetes считается.

СО СЦЕНЫ: Пять агентов в одной папке

• Кто и где: Люк Марсден, CEO, HelixML — «Giving Every Agent Its Own Desktop», AI Native DevCon 2026.
• Что показали: собственный инцидент автора при подготовке к встрече с клиентом. Пять параллельных агентов запущены в одном рабочем каталоге.
• Цифры: 5 агентов, 2 инцидента за 2 дня. В первый день один агент сделал git stash работы всех остальных. На следующий день другой сделал rm -rf в git-checkout.
• Что это меняет: это стартовая точка, с которой начинается вся тема изоляции. Параллелизм без изоляции — не оптимизация, а способ терять работу.

Что оказалось нужно кроме изоляции

Марсден описывает путь догфудинга честно, включая то, что чуть его не остановило.

Нормальный десктоп. Чтобы фоновый агент ощущался фоновым, ему нужна не голая консоль: GPU-ускоренные десктопы (mutter в контейнере, технологии из облачного гейминга, аппаратное кодирование видео). Внутри — форкнутый Zed: быстрый, с малым memory footprint, поддерживает ACP, а значит работает и с Codex, и с Claude Code. Каждый агент поднимает свой Chrome через Chrome MCP и не мешает соседям. Его формулировка: «You need an IDE on the inside, but you also need the meta IDE — the control plane for all the agents».

Скорость старта. Точка боли, которая остановила догфудинг: стек собирался в Docker с нуля 40 минут. Решение — ZFS-клоны Docker-окружений, прогретые последним main-коммитом, чтобы каждый агент стартовал с полностью закэшированной среды. Docker-in-Docker технически выдерживает до 16 уровней, у них около трёх; десктопы гасятся после часа простоя. Вывод дословно: нет смысла быстро поднимать песочницы, если агент 40 минут не может ничего сделать.

Интерфейс под реальный режим работы. Разработчик взаимодействует с агентом не весь день, а по несколько минут в час — значит, управление должно работать с телефона. Плюс Figma-подобные множественные курсоры: несколько человек могут парно работать на десктопе одного агента.

Спека как обязательная фаза. У Марсдена один и тот же агент имеет явную фазу планирования и фазу реализации. Спека — это короткий человеческий промпт плюс то, что планировщик вычитал из кода; спеки на 3–4 задачи генерируются за 30–60 секунд. Ревью идёт в Google-Docs-подобном UI, потому что терминал — плохое место для комментирования документов; сами спеки лежат markdown-файлами в git на отдельной ветке, чтобы все агенты видели спеки друг друга. Описание его рабочего дня: «Most of my day now… I find the two lines in the spec where the agent got it wrong».

Аргумент про железо. Отдельный совет Марсдена: взять трёхмесячный бюджет на токены и вместо него купить железо (условные 8× RTX 6000 Pro), гонять рутину на открытых весах и «выбираться» во фронтир-модель только на трудное. По его оценке, открытые модели уровня GLM 5.1 покрывают около 80% нужной работы. Заодно это защита от лока в одну экосистему — при условии, что у вас есть слой переключения агентов и моделей.

Песочница как полный стек

Роб Уиллоуби (Tessl, «Inside the Dark Factory») описывает требование к песочнице иначе, чем «изолируй, чтобы не сломал». У них агенты крутятся в Daytona-песочницах на намеренно «жирной» машине — чтобы поднять весь монорепозиторный тестовый стек: интеграционные тесты, поднятый репозиторий, клики по UI.

Правило простое: агенту доступно всё, что доступно локальному инженеру, минус креды. Побочный эффект оказался важнее основного: агент кладёт видео и скриншоты прямо в PR, и человек проверяет результат глазами, а не заходя по SSH.

Патрик Дебуа и Марсден отмечают ту же тенденцию с другой стороны: IDE возвращается, но уже как поверхность верификации — скриншоты, записи кликов агента, «follow»-режим, где ты пассивно впитываешь знание о кодовой базе. Формулировка Дебуа: «It's the job of the agent to convince you that it did the right thing».

Безопасность автоматизации

Дон Сайм, GitHub Next (создатель F#), доклад «The Agentic Repository Automation Revolution», говорит прямо: «Do not run coding agents directly in GitHub Actions… without a security architecture of some kind».

Его архитектура для агентного шага:

• работает read-only;
• без прямого доступа к секретам;
• в контейнере;
• с очень узким выходным каналом — например, «разрешено создать один issue»;
• выход обрабатывается вторым, не-агентным этапом (модель plan/apply);
• между этапами стоит threat detection;
• shared package caches выключены, исходящая сеть за фаерволом.

И его же наблюдение, которое переворачивает привычную логику: в индивидуальной продуктивности безопасность конфликтует со скоростью, и разработчик просто отключает подтверждения. В автоматизации связь обратная: чем лучше рельсы, тем быстрее может ехать поезд, тем больше вы готовы автоматизировать. «It's like a rail track. The better the quality of the rails, the faster your train can go». Отсюда его тест на докладчика: если кто-то рассказывает про автоматизацию и не говорит про безопасность — задавайте вопросы.

Отдельный сюжет — что делать, когда данные агенту показывать можно, а людям нельзя. Ори Шошан (Cyera) описывает схему «Малдер и Скалли»: агент внутри контролируемого периметра видит всё, но наружу выдаёт только structured validated output из фиксированного словаря, про который доказуемо, что он не течёт. Второй агент снаружи собирает из этого объяснение для людей. Реализовано за 2 дня. Escape hatch остаётся — свободный текст, но только узкой approved-группе, после чего словарь расширяют.

Джеймс Уикетт (Dryrun Security) и Адам Дайч (Commerce) в докладе «Securing AI-native Commerce Without Breaking the Cart» добавляют третий класс риска — периметр агента, который ходит наружу. Prompt injection в agentic-коммерции приходит через метаданные каталога: описания товаров, отзывы, заметки мерчанта. Это third-party risk, а не ваш код. Плюс excessive agency — слишком широкие права на внешние ресурсы. Их наблюдение: классические уязвимости (XSS, SQLi) падают, контекстные (авторизация, бизнес-логика) растут, при том что объём написанного кода за 2,5 года примерно удвоился. Рантайм-контроль сводится к scopes, MFA, human-in-the-middle на любое чувствительное действие и rate limiting.

Репозиторий как объект автоматизации

Дон Сайм предлагает добавить к CI и CD третью букву — CAI, continuous AI. Его диагноз: индустрия перекосилась в individual productivity (copilot-полярность) и недоинвестировала в автоматизацию и непрерывность. Признаки continuous AI: автоматизированное, повторяемое, коллаборативное, интегрированное, auditable. Его личное описание эффекта: «I wake up to code improvements, start my day with code that's better».

Единица автоматизации — agentic workflow: один файл (front matter плюс markdown), который «затвердевает» (hardening) в GitHub Action. В файле лежат триггеры, safe output specification, набор tools и намеренно неоднозначный текстовый промпт. Всё коммитится в репозиторий.

Отсюда его главный образ: репозиторий превращается в фабрику. CI/CD автоматизировал сборку и деплой, теперь на конвейер issues и pull requests ставятся «станки». Можно делать sub-factories — вырезать часть работы по меткам или заголовкам issue. «The repository is a site where humans and agents come together to work collaboratively to get forward velocity». Почему это распространится: приняв GitHub Actions, компания уже дала каждому разработчику право самостоятельно забирать compute, сеть и хранилище без похода к «облачным людям». Теперь к этому добавляются агенты.

Практический пример — его собственный. Workflow repo assist раз в сутки читает свою память и выбирает несколько задач из настраиваемого набора: триаж, предложения улучшений, обновления, метки. Сайм включил его на dormant-репозитории FSharp.Data с большим забытым бэклогом: 3 мажорных релиза, прошли весь бэклог issue — некоторые аж с 2018 года.

Внутри GitHub Next есть спор о форме. Коллега Сайма Pelli завёл сотни отдельных agentic workflows на любой случай — «agent factory»; сам Сайм предпочитает один workflow, делающий много вещей. Оба подхода задокументированы в серии «Meet the Workflow». Из цифр по конкретному workflow семантического рефакторинга функций: 112 смёрдженных PR из 142.

Что ещё относится к репозиторию как к среде:

• Никаких локальных конфигов. Дру Нокс: в Tessl объявили вне закона локальную конфигурацию агентов — всё коммитится, чтобы улучшение одного становилось улучшением для всех. Ограничение: часть остаётся специфичной для репозитория, шарятся style guide, дизайн-система и политики безопасности.
• Control plane: тикет → агент → PR → комментарии. Нокс называет это первым и самым дешёвым шагом: все точки взаимодействия человека с агентом становятся legible, и по ним можно натравить другого агента. Цифра, на которую он ссылается: OpenAI в white paper — 5× рост производительности за 2–3 месяца при переходе от интерактивных сессий к тикетам и PR.
• «Agent it». Самый нудный слой: найти все места, где нужен человек, залогиненный куда-то руками — база, логи, фича-флаги, админка. Каждое такое место — целый класс задач, недоступный агенту. Сюда же CLI/API-доступ к собственному продукту. Предупреждение Нокса: «I promise, it's worse than you think».

Данные: почему нужен data harness

Уилл Мартин, data & AI evangelist в Dremio, доклад «Why AI Agents Need a Data Harness, Not Just a Lakehouse». Тезис: хранилище — это не оснастка. Агенту нужны три свойства данных.

• Accessible — весь эстейт через федерацию, без физического переезда данных.
• Understandable — semantic layer с определениями метрик и колонок. Без него модель «угадает с уверенностью»: определения Q2, revenue и customer различаются даже внутри одной компании.
• Performant — субсекундный ответ.

Последнее выглядит придиркой, но ломается первым. Аналитика «на скорости email» — когда отчёт готовится к утру — на агентах не работает: пайплайны отваливаются по таймауту, а агент в это время жжёт токены. Цифра по их кэшу C3 (данные рядом с compute): падение стоимости до 90% у части клиентов.

Смежный сюжет — «мозг компании». Нокс (ответ на вопрос из зала) даёт свой рейтинг источников: транскрипты встреч (Granola) — лучший bang for buck, Slack тоже неплох, доки в Notion полезны, но быстро протухают. И приём: не вываливать источник целиком, а точечно указывать в тикете «возьми этот транскрипт и сделай по нему». Ограничение он признаёт открытым: решения проблемы устаревшей информации нет, и с агентами она станет хуже.

Ори Шошан добавляет граф знаний и инструмент «найди связанное»: по строке лога поднять PR, который внёс исключение, сами логи и оценку влияния. Агенты хорошо исследуют, но не всегда исследуют всё нужное — они зависят от того, попадётся ли им подсказка. Построение графа оказалось разовой дорогой операцией, а эксплуатация — дешёвой, именно из-за структурности. Его формула: «I try to set up my development environment so that the compiler yells at me when I do something wrong. I do that for my friend the bot too».

Что воспроизводимо малой командой, а что требует платформы

Элемент среды	Малой командой	Требует платформы
Изоляция каждого агента (отдельный воркспейс/контейнер)	да, это первый шаг	—
Переход на «тикет → агент → PR»	да, дешевле всего остального	—
Локальные конфиги вне закона, всё в репозиторий	да	—
Agentic workflow одним файлом в репозитории	да, если вы на GitHub Actions	—
repo assist-подобный ночной workflow	да	—
Полный тестовый стек в песочнице (интеграционные тесты, UI-клики)	частично, зависит от монорепы	скорее да
GPU-десктопы, ZFS-клоны прогретых окружений	нет	да
Своё железо под открытые модели	нет	да
Threat detection между этапами, фаервол на исходящую сеть	частично	да
Semantic layer и федерация данных	нет	да
Agent observability по всей организации, MCP gateway, identity	нет	да

Практический вывод: порог входа проходит не по железу, а по legibility. Перевести работу на тикеты и PR, запретить локальные конфиги и дать каждому агенту отдельный воркспейс можно за неделю и без бюджета. Всё дорогое из таблицы имеет смысл только после этого — иначе вы построите платформу вокруг процесса, сигналы которого никто не видит.

Коротко

• Параллельные агенты в одной папке ломают работу друг друга: 5 агентов, 2 инцидента за 2 дня — git stash чужой работы и rm -rf в checkout (Марсден, HelixML). Изоляция при этом бесполезна без скорости старта: 40-минутная сборка обесценивает быстрые песочницы.
• Песочница должна поднимать полный стек, а не только компилировать: тогда агент прикладывает к PR видео и скриншоты, и проверка идёт глазами (Уиллоуби, Tessl).
• В автоматизации безопасность и скорость связаны прямо, а не обратно: чем лучше рельсы, тем быстрее поезд (Сайм, GitHub Next). Read-only, без секретов, узкий safe output, второй не-агентный этап.
• Репозиторий — единица автоматизации: agentic workflow одним файлом, sub-factories по меткам, ночной repo assist (3 мажорных релиза на dormant-репозитории FSharp.Data).
• Данным нужна своя оснастка: федерация, semantic layer против «уверенной догадки» и субсекундная скорость — иначе агент жжёт токены в таймаутах (Мартин, Dremio).

Тёмная фабрика: где кончается человек

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

Цифры

СО СЦЕНЫ: Kikimora, внутренняя фабрика Tessl

• Кто и где: Роб Уиллоуби, AI engineering lead, Tessl — «Inside the Dark Factory: AI That Ships Code Solo», AI Native DevCon 2026.
• Что показали: внутренняя фабрика под кодовым именем Kikimora забирает тикеты из Linear, гоняет агента в песочнице, ведёт PR через ботов-ревьюеров и CI и мёрджит результат. «Тёмная» — потому что в логи в момент работы никто не смотрит, только post-hoc.
• Цифры: 65–70% всех PR компании идут через фабрику; ~40% продовых PR; 516 PR за неделю, когда вся компания была на выездном оффсайте; ~600–700 PR в неделю в целом при ~24 инженерах. Отдельно по коду самой фабрики: человек когда-либо смотрел в PR около 5% — то есть 95% кода фабрики никто не видел. Рекорд по автомёрджу: 150 PR за выходные на двоих.
• Что это меняет: это уже не «агент помогает писать код». Это производственная система, у которой есть пропускная способность, очередь и режим отказа — и её надо инженерить как систему, а не как инструмент.

Уиллоуби объясняет название дословно: «It's called a Dark Factory because we're not looking at the logs as it's operating».

Начали они с двух правил, которые Дру Нокс перечисляет в докладе «Harness Engineering: The New Discipline of Agentic Dev»: (1) больше никакого написанного человеком кода, (2) больше никаких интерактивных сессий с кодинг-агентом. Второе вызвало в зале реакцию, которую он описывает как «Two people collapsed out of shock». Но на практике, по его словам, это оказалось малым шагом: люди и так запускали агента, уходили в другую вкладку и потом ревьюили результат — просто ревью шло в чате, а не в PR.

Правило автомёрджа

Самое ценное в докладе Уиллоуби — не цифры, а правило, которым они объясняют политику мёрджа:

Если мы не можем это автомёрджить, значит, у нас нет верификации, дающей уверенность.

Фраза звучит как бравада, а работает как диагностический инструмент. Разберём, что за ней стоит.

Первое: автомёрдж — это не разрешение, а измерение. Обычная логика — «мы доверяем агенту настолько, что готовы мёрджить». Их логика обратная: невозможность автомёрджа означает, что вы не знаете, работает ли код, — и человеческое ревью в этой ситуации не решение, а способ не признавать проблему. Человек в PR не проверяет, что интеграционные тесты покрывают маршрутизацию; он смотрит на дифф. Если ваша уверенность держится на том, что «Вася посмотрел», у вас нет верификации — у вас есть Вася.

Второе: правило применяется по зонам, а не глобально. У Tessl автоматически мёрджится код самой фабрики, research-часть и то, что строит GTM-команда. Продовый код — то, что видит пользователь, — требует человеческого ревью. То есть правило не «мы мёрджим всё», а «в каждой зоне мы честно отвечаем, есть ли у нас верификация, и не притворяемся».

Третье: решение о зоне тоже автоматизируется, но остаётся человекочитаемым. У них есть change risk analyzer — агент, который прогоняет PR против согласованной с командой политики и решает, нужен ли человеческий ревью. Принципиально, что политика — человекочитаемый скилл, а не непрозрачный классификатор: её можно обсуждать и тюнить на ретро. Оговорка Уиллоуби на момент разговора: они всё ещё ревьюят всё, чтобы откалибровать классификатор.

Побочный эффект оказался культурным: люди начали сами дробить свои PR, потому что маленький и изолированный PR уедет без человека. Нокс отвечает этим же на вопрос из зала о начальнике, который выкатил PR на 100 тысяч строк без обсуждения: культуру меняют не увещеваниями, а кодификацией. Целевой размер PR у них — 200–300 строк; если маленький сфокусированный PR классифицируется как low risk и уезжает автомёрджем, люди сами начнут дробить свои двадцатитысячные диффы. Его же оговорка: «это частичные ответы, культурную часть мы всё ещё выясняем».

Четвёртое: accountability не переезжает. Уиллоуби фиксирует это отдельно — ответственность остаётся на том, кто завёл тикет. «Dark Factory сделала» не снимает accountability ни с кого.

Пятое: реакция на прорыв — fix forward, а не откат. Когда в автомёрдж проезжает что-то нежелательное, вопрос не «как откатить PR», а «что мы не проверили, раз это прошло» — и добавить verifier или тест. И к этому прилагается сильная оверкоммуникация: команда фабрики шлёт в свой Slack-канал в 10–15 раз больше сообщений, чем другие команды, будучи меньше по размеру. Причина простая: кодовая база меняется способами, которых никто не отслеживает вручную. Итоговая формула Уиллоуби: «Autonomy is earned, not enabled».

Автономия и автоматизация — разные оси

Нокс отдельно разводит понятия, которые в разговорах постоянно слипаются.

Автономия — сколько раз человеку приходится поправить агента, чтобы получить правильный ответ. Автоматизация — насколько вы вообще разрешаете агенту работать без надзора.

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

Третья ось — качество, и по нему у Нокса порядок такой: сначала не просаживать, потом поднимать.

Спор: где стоит человек

Здесь материал расходится, и расхождение содержательное. Три позиции.

Tessl: автомёрдж как тест на зрелость верификации. Позиция описана выше. Человек стоит там, где верификация ещё не построена, — и это временное состояние, которое надо сокращать.

GitHub Next: PR — жёсткие человеческие ворота, и это не обсуждается. Дон Сайм в «The Agentic Repository Automation Revolution» говорит, что в GitHub Agentic Workflows агенты никогда не мёрджат pull request. PR — точка, где человеческий надзор гарантирован конструкцией. При этом он же считает нормальным сознательно тормозить фабрику под человеческие и организационные нужды: «It's always okay to slow down the factory» — домашнюю фабрику тоже не гоняют ночью.

Патрик Дебуа: не тёмная, а тусклая. В разговоре «The DevOps Godfather on AI's Dark Factory Problem» он снимает саму бинарность. Реалистично это dim factory: спектр от микроменеджмента до автономного апрува, и уровень риска выбирается отдельно для каждой фичи. Не все фичи станут автономными — и вместо погони за автономией он предлагает инвестировать в аудит, provenance (кто менял код), verifiers и situational awareness при отказах. Про сопротивление у него есть точное наблюдение: «"It will not work here" — what they're actually signaling is: we're not ready yet».

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

Практически это означает: вопрос «мёрджить ли автоматически» не имеет общего ответа, но имеет проверяемый признак. Если вы не можете назвать, какая проверка поймала бы конкретный класс ошибки, — человек нужен. Если можете и всё равно держите человека — вы платите за страх, а не за качество.

Провал: переписать систему по одной верификации

Самый полезный кусок в докладе Уиллоуби — эксперимент, который не сработал.

Гипотеза была такая: если слой верификации достаточно силён и описывает поведение, а не реализацию, систему можно переписать с нуля на другом языке, дав агенту только верификацию. Проверяли на переписывании самой фабрики на Elixir. Агенту дали интеграционные и end-to-end тесты, формальную модель и свойства.

Получилось «что-то» — и это «что-то» вскрыло слепые зоны:

• маршрутизация по меткам Linear проверялась только юнит-тестами — то есть верификация была привязана к реализации, а не к поведению;
• стекинг PR не покрывался end-to-end вообще;
• батчинг CI-сигналов не покрывался тоже.

Новую реализацию включали дважды, и оба раза она ломала чужие PR. Вывод Уиллоуби: «Even after all the investments on verification we thought we had made, we had some pretty big blind spots».

Ценность этого эксперимента не в том, что переписывание провалилось. Ценность в том, что это дешёвый способ измерить качество своей верификации. Обычно вы узнаёте о дыре в покрытии, когда через неё проехал баг. Здесь дыра проявляется сразу и списком: всё, что новая реализация сломала, — это то, что ваша верификация не описывала. Если правило «нет автомёрджа = нет верификации» звучит для вас слишком абстрактно, то этот эксперимент — его исполняемая версия.

Контрпример из того же доклада показывает, как выглядит обратный исход. У них была гонка очереди: комментарии PR попадали в очередь дважды, два агента в разных песочницах отвечали на один и тот же элемент, возникали race conditions и конфликтующие коммиты. Чинили и регрессировали снова и снова — около 60 PR за 2–3 дня ушло в попытки. Решение — формальная модель поведения очереди на Quint, проверяемая на каждом PR; модель вместе с фабрикой сделали примерно за день, после чего рецидивов не было. Комментарий Уиллоуби: «I wouldn't have known how to do that in a pre-agent world. Just flat out».

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

Границы автономии: что отдают, а что нет

Что отдают полностью	Что оставляют человеку
Код самой фабрики, research, GTM-инструменты (Tessl)	Продовый код, который видит пользователь (Tessl)
Триаж, метки, обновления, предложения улучшений (Сайм, repo assist)	Мёрдж pull request — всегда (GitHub Agentic Workflows)
Ночные maintenance-агенты в низкорисковых зонах (Нокс)	PR в продовых путях — идут человеку (Нокс)
Классификация риска PR по человекочитаемой политике	Согласование самой политики риска
Декомпозиция и последовательность подзадач внутри фичи	Постановка фичи и accountability за тикет
Работа с данными за периметром через фиксированный словарь (Шошан)	Свободный текст наружу — только approved-группе

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

И меняется круг тех, кто может отгрузить код: у Tessl человек из people ops залил первый продовый PR, а глава юридического отдела ходила с ноутбуком и шипила код. Оговорка Нокса: запускать это надо в облаке, а не на чьём-то ноутбуке.

Возражение про слоп

Главное возражение против фабрики — «скорость ценой качества». Нокс отвечает аргументом про бэклог: большинство багов известны и лежат P2, потому что чинить дорого. С фабрикой ёмкость такова, что бэклог как понятие исчезает, включая нишевые кейсы, до которых никогда не доходили руки. Показательно: те же пять «линз» ревью на человеческих PR вызывали жалобы «слишком много замечаний», а на агентских просто исправляются. Его формула: «If an agent can identify a problem, it can be fixed». Цифры у него косвенные — по его словам, у Intercom снизилось число багов, проходящих ревью, за счёт масштабирования усилий на ревью.

Дон Сайм закрывает смежное возражение — «агенты съедят всю работу»: автомобиль породил поездки, которых не было, фабрика — товары, которых не было. Его пример: continuous accessibility. Нанять отдельного accessibility-инженера нельзя, а прогнать агента по работающему приложению — можно.

Как туда попадают

Нокс настаивает, что правильный вопрос не «строить ли фабрику», а «на сколько процентов вы фабрика». Схема, которую он предлагает: выбрать workflow → положить в коробку, понятную агенту → погонять интерактивно и набрать уверенность → автоматизировать. Монолитная трёхмесячная перестройка обречена — индустрия за это время изменится. «It's much easier if one piece doesn't work to just roll it back, rip it out and try something else». Реалистичная траектория, о которой он говорит: через полгода вдруг оказывается, что 40–50% PR никто из людей не смотрит.

Ловушка, которую он же называет: команды делятся на два лагеря — те, кто всегда выбирает «дошипить» и навсегда застревают в локальном максимуме, и дисциплинированные, которые проваливаются в многомесячный провал скорости, пока переносят всю работу во внутренний тулинг. Раннее введение петли ломает эту дилемму, потому что петля масштаба «пара PR в день», а не «квартальная инициатива».

Коротко

• 65–70% PR через фабрику, ~40% продовых, 95% кода самой фабрики человек никогда не видел в PR, 150 PR за выходные на двоих — это работающая производственная система, а не демо (Уиллоуби, Tessl).
• Правило «не можем автомёрджить — значит, нет верификации» работает как диагностика: человеческое ревью на месте отсутствующей проверки маскирует проблему, а не решает её.
• Автономия и автоматизация — разные оси. «Ревью стало бутылочным горлышком» — это разблокированная автономия при незакрытой автоматизации.
• Спор реальный: Tessl мёрджит автоматически там, где верификация доказана; GitHub Agentic Workflows не мёрджат PR агентами никогда; Дебуа предлагает спектр с риск-аппетитом на фичу. Общего ответа нет, есть проверяемый признак — можете ли вы назвать проверку, которая поймала бы конкретный класс ошибки.
• Эксперимент с переписыванием на Elixir по одной верификации провалился дважды и вскрыл слепые зоны (маршрутизация только в юнит-тестах, стекинг PR и батчинг CI без end-to-end) — это дешёвый способ измерить своё покрытие.
• Ответственность не переезжает на фабрику: она остаётся на том, кто завёл тикет.

С чего начинать оснастку

Если свести весь материал к одному утверждению, оно будет таким: порядок сборки оснастки идёт от верификации к автономии, а не наоборот. Все, кто показывал работающие цифры, шли именно в этом направлении. Все, кто описывал провалы, — начинали с автономии и потом пытались подпереть её проверками.

Порядок сборки

Шаг 0. Legibility — сделать работу видимой

• Перевести взаимодействие на «тикет → агент → PR → комментарии».
• Запретить локальную конфигурацию агентов: всё в репозиторий.
• Зачем: пока сигналы в логах на чьём-то ноутбуке, чинить нечего.
• Цена: неделя, ноль бюджета. Дешевле всего остального.
• Источник: Dru Knox (Tessl); OpenAI white paper — 5× за 2–3 месяца.

Шаг 1. Изоляция — дать каждому агенту свой воркспейс

• Отдельный контейнер/каталог/десктоп. Никаких пяти агентов в одной папке.
• Зачем: без этого параллелизм не ускоряет, а уничтожает работу.
• Источник: Luke Marsden (HelixML) — 5 агентов, 2 инцидента за 2 дня.

Шаг 2. Детерминированная верификация — inner loop

• Компилятор, типы, линтеры, юнит- и интеграционные тесты.
• Всё, что можно сделать детерминированным, делать детерминированным.
• Педантичность теперь дешёвая: исполнять правила будет не человек.
• Источник: Dru Knox (Tessl).

Шаг 3. Verifiers — то, что в regex не выражается

• Одно утверждение = один verifier. Триггер — glob по файлам.
• Оценка — LLM-as-judge, один вызов на утверждение.
• Правило: увидел ошибку агента — не правь руками, заведи проверку.
• Источник: Dru Knox, Rob Willoughby (Tessl). Больше 100 verifiers на PR, ~$0,30/день.

Шаг 4. Песочница с полным стеком

• Всё, что может локальный инженер, минус креды.
• Прогретые окружения: старт секунды, не 40 минут.
• Агент кладёт скриншоты и видео в PR — проверка глазами, не по SSH.
• Источник: Rob Willoughby (Tessl), Luke Marsden (HelixML).

Шаг 5. Outer loop — дорогие ворота на границе PR

• Агентное ревью, агентный QA, mutation testing.
• Норма — зелёный с первого раза. Красный outer loop = проверка стоит не там.
• Источник: Dru Knox (Tessl). ~$25 на PR.

Шаг 6. Meta loop — петля, которая чинит петли

• Ночной разбор логов, PR-комментариев и упавших CI.
• Промоушен повторяющихся замечаний в verifiers (shift left).
• Правило: объяснил агенту дважды — это долг в оснастке.
• Источник: Dru Knox, Rob Willoughby (Tessl).

Шаг 7. Risk classification — кто решает, нужен ли человек

• Агент прогоняет PR против человекочитаемой политики.
• Политика — обсуждаемый скилл, не непрозрачный классификатор.
• Калибровка: сначала ревьюить всё и сверять с решением классификатора.
• Источник: Rob Willoughby, Dru Knox (Tessl).

Шаг 8. Автомёрдж — только в зонах с доказанной верификацией

• Начинать с внутреннего тулинга, а не с продового пути.
• Реакция на прорыв — fix forward: что мы не проверили, раз это прошло.
• Источник: Rob Willoughby (Tessl). «Autonomy is earned, not enabled».

Обрати внимание на два свойства этого списка. Первое: шаги 0–1 не требуют бюджета и не требуют разрешения. Второе: шаг 8 не является целью. Дон Сайм (GitHub Next) вообще его не делает — в GitHub Agentic Workflows агенты не мёрджат PR никогда, и это осознанная конструкция, а не отставание. Патрик Дебуа предлагает выбирать уровень автономии на каждую фичу отдельно. Список описывает порядок, в котором элементы становятся возможны, а не обязательную дистанцию.

Что проверить сегодня

Пять вопросов, которые дают честную картину за полчаса.

1. Где хранится история того, как агент ошибся вчера? Если ответ «в терминале Васи» — вы на шаге 0, и всё остальное преждевременно.
2. Какое замечание вы написали в PR третий раз за месяц? Оно должно было стать verifier'ом после второго. Это самый дешёвый первый verifier, который у вас есть.
3. Назовите проверку, которая поймала бы последний баг, доехавший до прода. Если не называется — у вас нет верификации в этой зоне, и человеческое ревью её не заменяет. Оно её маскирует.
4. Что сломается, если два агента запустятся в одном каталоге? Если ответ неизвестен — проверять не надо, надо изолировать.
5. Сколько мест в вашей системе требуют человека, залогиненного руками? Доступ к базе, к логам, к админке, к фиче-флагам. Каждое такое место — целый класс задач, недоступный агенту. Нокс предупреждает: их больше, чем кажется.

Чего не делать

Не начинать с автомёрджа. Это последний шаг, а не первый. Правило Tessl читается наоборот: не «мы смелые, поэтому мёрджим», а «мы мёрджим то, что умеем проверять, и честно признаём, где не умеем».

Не затевать монолитную перестройку. Нокс: трёхмесячная перестройка обречена, индустрия за это время изменится, и откатить единый кусок нельзя. Правильный масштаб петли — пара PR в день.

Не резать бюджет на токены как первый шаг оптимизации. Дебуа: это ломает обучение организации. Оптимизировать надо вынесенные в отдельные workflow повторяющиеся задачи, где можно прогнать eval и принять осознанный размен — «на 5% хуже, но на 80% дешевле».

Не давать агенту широкий доступ вместо узкого набора инструментов. Ори Шошан (Cyera): whitelist из 50–60 узких tools с известной attack surface, bash не дают. И обязательный escape hatch — иначе агент начинает использовать инструменты не по назначению, а это худший режим отказа: снаружи его не видно.

Не запускать агентов в CI без архитектуры безопасности. Дон Сайм формулирует это как прямой запрет. Read-only шаг, без прямого доступа к секретам, узкий safe output, второй не-агентный этап на применение.

Не считать, что «фабрика сделала» снимает ответственность. Уиллоуби: accountability остаётся на том, кто завёл тикет.

Не превращать оснастку в свалку. Скиллы и хуки под конкретные слабости текущей модели живут пару месяцев и выбрасываются при апгрейде. Долгоживёт описание workflow, стандартов и политик. Нужен регулярный eval «с плагином / без плагина» и регресс-тест на саму оснастку при смене модели.

Что мерить

Не token spend. Две связки метрик из материала.

От Дебуа: сколько человеческих касаний ещё нужно, чтобы агент сделал правильно — должно падать; и множитель solo → shared — насколько одна правка общего контекста улучшает работу всех команд. Его вывод: герои — те, кто контрибьютит в общие компоненты, «not the token billionaires».

От Нокса: вниз — manual takeovers, человеческие комментарии в PR, случаи ручной декомпозиции тикета; вверх — доля PR, инициированных агентами без участия человека. По качеству: сначала не просаживать, потом поднимать.

И один индикатор, который стоит держать отдельно: сколько раз вы объяснили агенту одно и то же. Всё, что больше единицы, — это несделанная работа по оснастке.

Последнее

В материале есть фраза, ради которой стоило всё это разбирать. Роб Уиллоуби сказал её про свою фабрику, где 95% кода никто не смотрел: «Autonomy is earned, not enabled».

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

Поэтому вопрос «готовы ли мы отдать это агенту» всегда переводится в другой: какая проверка поймает нас, если он ошибётся. Если на него есть ответ — автономия уже заработана. Если нет — её нельзя выдать, сколько бы смелости у команды ни было.