Первый замер цикла задачи готов. Самая показательная цифра - не время агента, а 23+ часа ожидания между prep и выдачей WO. Узкие места - нечетко распланированный рабочий день человека ("затянул" день - а в спринте уже горит) и инертность в принятии решений (много гипотез "если бы да кабы"). С агентом вариантов стало больше, и каждый - best practice со своим контекстом применения.

Задача:

Работаем на R2: на первых задачах трудно держать "агентов в узде" и получать точечный результат на крупных объемах без инженера (R3+). Пример - полигон PlayBiz: 500+ файлов, ~100 компонентов, полный перевод React 18+ на Next.JS, докеризация, CI/CD, SEO/GEO.

Результат на лицо: AR-приемки с минимальными правками (diff <0.5% от сгенерированного объема, причем большая часть: cli-команды, не код).

Замер:

Наш цикл задачи: prep-cycle-time -> lag-between-prep-cycle-time-wo-issued -> impl-cycle-time -> lag-between-impl-cycle-time-ar-created -> accept-cycle-time -> rework-iterations -> token-cost -> deploy-cycle-time.

deploy-cycle-time - время от закрытия задачи до попадания в следующий плановый релиз. Тут также важно считать не календарные сутки, а рабочее время (простая разница между двумя временными точками = мусорная метрика): выходные и нерабочие часы в минус. Простой в 10 дней - не 240 часов: без поправки не понять, укладывается ли изменение в утвержденный спринт. Конфликты слияния попадают в диапазон. Per-task метрики продуктовых проверок - отдельный слой, в цикл не входят.

Цифры:

- WO-001 (архитектура/код): prep 0.7 ч, impl 3.5 ч (из них rework после первичной приемки 1.2 ч), accept 0.2 ч (две сессии), token-cost 477.9 (₽).

- WO-002 (инфра/докеризация/тесты/SEO/GEO): prep 0.67 ч, impl 0.38 ч, token-cost 25.0 против 477.9 у WO-002.

- lag между prep и wo-issued: 0.1 ч против 23.12 ч - передача на следующий день. Время сжигается не агентами, а простоями человека.

Главный инсайт: уровень проработки KB и артефактов должен соответствовать уровню планирования рабочего дня всех участников БП.

Rework-iterations = 1: приемка нашла критичные несоответствия, агент исправил их внутри WO по направлению инженера. Ручной дифф небольшой: XPE - продуктовое, SWE - техническое.

Что сработало:

- Смысловая карта юнитов вместо формальной: реальные логические группы кода с описанными связями, а не "папки с ответственностью".

- Паспорта юнитов с правилами и контрактами: инварианты, "невидимые" из кода.

- Подробные SPEC/WO и декомпозиция крупной SPEC на несколько WO: порядок, юниты и файлы, явный whitelist и пары "запрет -> легитимная альтернатива".

Моя текущая позиция: к R3+ готовимся, но пока человек останется в цикле. Когда dev-метрики "расплываются", а среда имеет неопределенности, сдерживать самодеятельность агентов трудно. Шаги агента уже не контролируем - контролируем контуры (архитектура - уровень R4). Но по факту это все еще R2: до human-on-the-loop рано.

Нововведения:

1. Диапазонные метрики времени на всех артефактах: остановка закрывает диапазон с причиной или по стандартному событию (перерыв, конец дня).

2. Агенты сами пишут диапазоны имплементации, меняют метки времени (ISO 8601) и статусы артефактов.

3. В WO агент подробно отчитывается; инженерные артефакты агентам недоступны.

4. Запрет на правку KB и карты проекта. Вместо прямых правок - механизм эволюции KB: агент предлагает изменения в формате Наблюдение + Категория + Куда бы легло + Предложение + Повторяемость. Работает на удивление хорошо.

Следующий шаг:

Прогон на полигоне legacy: IM / CMS / CRM / ERP / WMS, 8к+ файлов. Задача: кастомные формы и расчеты логистики/упаковки/погрузки стройматериалов - без Figma. Прототипы описательным языком -> скрины-прототипы и use-cases БЛ -> утверждение ЛПРами -> агентная разработка по скринам (и фронт и бэк!).

Вопрос к аудитории:

Легко сказать: у нас human-on-the-loop! А насколько он реален - признаетесь? 😉

#IT #AI #ИИ #XDLC #SDD #агенты #метрики #автоматизация