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

Инструменты и петли из предыдущей части сами себя не заведут: их кто-то должен построить, поддерживать и развивать внутри команды. Эта часть — про 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 тяжёл: пока сигналы лежат в логах локального агента, в чьей-то голове и на чьей-то машине, оптимизировать нечего. Пока рабочий процесс не переехал на поверхности, где всё сохраняется, чинить нечего.

Определение готовности другое. Дебуа: 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 программы. Ограничение он тоже называет: консенсус двух команд о единой оснастке требует тяжёлой согласовательной работы, и реалистичный результат — каталог из 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) описывает внедрение ровно как 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. Множитель от перехода от личного контекста к общему: одна правка общего контекста улучшает работу всех команд.

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

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

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

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

В том же разговоре Дебуа называет следующий уровень зрелости после continuous integration и continuous delivery — continuous learning: как быстро организация впитывает новую идею и меняет систему, даже если это означает переписать кодовую базу. Знание накапливается в контексте, скиллах и оснастке — и это и есть moat. «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 вверх, множитель от перехода от личного контекста к общему. Резать бюджет на токены — рефлекс, который ломает обучение организации.