Оценка сроков фичи, когда код пишет ИИ-агент: моя формула продюсера

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

Как оценить сроки фичи, если код пишет ИИ-агент

Оценка сроков фичи с ИИ-агентом - это расчёт не времени написания кода, а времени приёмки: сколько задач ты успеваешь проверить вживую за час, сколько раз агент переделывает и сколько уходит на разбор задачи до старта. Код почти бесплатен по времени. Срок задаёт твоя пропускная способность как проверяющего.

Звучит как кокетство, но вот цифра из моей же сессии. 27 июля 2026 я гонял конвейер агентов на ДнД-боте: агент-разработчик чинит, агент-QA проверяет на живом проде. За ~6 часов закрылось 20 задач с живой проверкой. Из этих 6 часов 7 прогонов QA съели ≈4,4 часа. Разработчик в это время в основном ждал.

То есть больше 70% срока - проверка. Оценивать "сколько агент будет писать" бессмысленно, это самая короткая часть.

Формула продюсера: из чего складывается срок

Формула продюсера для фичи с ИИ-исполнителем - это сумма четырёх слагаемых: разбор задачи человеком, число задач, делённое на темп приёмки, поправка на переделки и хвост из найденных по пути багов. Каждое слагаемое меряется по логам прошлых волн, а не по ощущениям.

Срок = Разбор + (N / V) × (1 + r) + Хвост
 
Разбор - спека или диагноз до старта агентов (делаешь ты сам)
N      - сколько задач получилось после нарезки
V      - темп приёмки: задач в час с живой проверкой
r      - доля рефикс-петель (сколько раз агент переделывает на задачу)
Хвост  - деплой, стабилизация, баги, которые всплыли по ходу

Мои замеры по двум волнам на ДнД-боте выглядят так:

Видно, что V плавает больше чем вдвое. 13 августа три задачи заняли ~2 часа, потому что посреди волны случился инцидент и пришлось выбирать между вариантами починки. Поэтому V - это не константа, а диапазон, и брать его надо из своих волн.

Отдельно про "Разбор". В разборе той июльской сессии я записал скрытую предпосылку успеха: диагноз-ревизию эпика ДО конвейера, с file:line в заметках к каждой задаче. Без неё фиксы не укладывались бы в 12-38 тысяч токенов вывода на задачу и не проходили бы QA с первого раза. Разбор короткий по времени, но если его пропустить, r улетает в небо. Как ставить такую задачу агенту, чтобы не переделывать, я расписывал в шаблоне брифа для ИИ-агента.

Как я оценивал волну из 20 фиксов на ДнД-боте

Мой рабочий кейс - волна из 20 задач на ИИ-мастере DnD: баги денег за квесты, словари, поведение NPC. Срок по формуле разошёлся с фактом меньше чем на час, потому что считал срок от приёмки, а не от кода, и разбор задач сделал отдельно до старта агентов.

Прежний ритм у меня был 1-6 задач за сессию в обычном чате с агентом, плюс отдельная сессия QA. Рекорд - 6 багов. Конвейер дал 20 задач и 5 деплоев за ~6 часов, 19 PR, 2 рефикс-петли. Итого ×3-4 по закрытиям.

По формуле это выглядит так: 20 задач / 3,3 в час × 1,1 ≈ 6,7 часа. Факт - около 6. Тут честно оговорюсь: 3,3 в час я посчитал по этой же сессии, так что сходимость частично подогнана. Ценность в другом: в следующих волнах я ставлю V и r из прошлой, а не из головы.

Где сломалось. Обе рефикс-петли пришлись на одну задачу (dnd-h40s, канал словарей и LLM-подтверждений). Это подтвердило правило, которое я потом записал в скилл конвейера: словарно-прозовые задачи стабилизируются за 2 итерации, вторую QA-итерацию закладываешь в план сразу. То есть для таких задач r = 1, а не 0,1. Мелочь, а без неё оценка врёт на треть.

И ещё деталь, которую не выдумаешь: агент-разработчик dnd-h40s прожил 3 часа, час из них простаивал, кэш протух, и на перезапись ушло 5,5M токенов кэш-записи. С тех пор у меня TTL агента 60 минут после отчёта: нет рефикса за час - отпускаем, рефикс получает новый агент с диагнозом из трекера. На сроке это не видно, а на цене задачи - очень.

Про приёмку как отдельный навык подробно писал в статье про мясной мешок в агентском пайплайне - здесь важна только её цена во времени.

Сколько на самом деле живут мои эпики

Срок фичи с агентом зависит от того, сколько в ней неизвестного, а не от числа подзадач. По моему трекеру задач хорошо описанные эпики закрываются за минуты или часы, а эпики с исследованием и рефакторингом растягиваются на недели при сопоставимом числе подзадач.

Вот окна закрытия подзадач по экспорту трекера (beads) за осень 2026. Это время от первой закрытой подзадачи до последней, не чистые рабочие часы: старт работы в экспорт не попадает.

Посчитать такое у себя можно за минуту. Скрипт берёт выгрузку закрытых задач и группирует подзадачи по эпику:

import json, collections
from datetime import datetime
 
epics = collections.defaultdict(list)
for line in open("closed-beads.jsonl"):
    b = json.loads(line)
    if "." in b["id"]:
        epic = b["id"].rsplit(".", 1)[0]
        epics[epic].append(datetime.fromisoformat(b["closed_at"].replace("Z", "+00:00")))
 
for epic, ts in sorted(epics.items(), key=lambda x: -len(x[1])):
    span = max(ts) - min(ts)
    print(f"{epic}: {len(ts)} подзадач, окно {span}")

Самый показательный - dnd-2g0e. Это переезд обработчика хода с 17 тысяч строк в одном куске на модули. 1 октября я писал игрокам, что осталось два шага. Корневая задача закрылась 8 октября, ещё через неделю, а связанные баги дочищались до 13-го. Классика закона Хофштадтера: всё занимает больше, чем ты ожидаешь, даже если учитываешь закон Хофштадтера (Wikipedia). Как я страховал этот переезд записанными ходами, рассказывал в статье про трос из 66 слепков.

Как оценить сроки фичи пошагово

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

1. Сделай разбор. Для бага - диагноз с file:line, для фичи - спека с критерием готовности. Время на разбор оцени отдельно, это человеческие часы, агент их не сократит.
2. Нарежь на задачи, которые агент закрывает надёжно. По исследованию METR (март 2025), горизонт задач, которые модели решают с вероятностью 50%, удваивается примерно каждые 7 месяцев; у Claude 3.7 Sonnet он был около 50 минут человеческой работы (arXiv 2503.14499). На 80% надёжности горизонт заметно короче (arXiv 2505.05115). Мне нужна не половина успехов, поэтому режу мельче, чем "модель вроде бы потянет".
3. Возьми V из последних 2-3 волн. Нет логов - проведи одну пробную волну на 3-5 задачах и замерь. Без этого любая цифра - гадание.
4. Поставь r по типу задачи: механика и код с тестами - 0,1, словари, промпты и прозовые ответы модели - 1 (вторая итерация сразу в плане).
5. Посчитай три сценария и сведи формулой PERT, о ней ниже. Хвост добавь сверху: у меня каждый QA-прогон приносит ~3 новых бага с диагнозом, и часть из них блокирует релиз.

Формула PERT для задач ИИ-агента

Формула PERT - это взвешенная оценка срока по трём сценариям: E = (O + 4M + P) / 6, где O - оптимистичный срок, M - наиболее вероятный, P - пессимистичный. Разброс оценивают как σ = (P − O) / 6. Метод придумали в ВМС США в конце 1950-х для программы Polaris (PMStudyCircle).

С агентами PERT ложится на формулу продюсера естественно: три сценария - это три разных V и r из твоих волн. Пример для фичи на 12 задач, где M я беру условным средним между двумя волнами:

E = (4,0 + 4 × 6,5 + 13,4) / 6 ≈ 7,2 часа, σ ≈ 1,6 часа. Плюс разбор и хвост. Назвать "7 часов" и уложиться в два вечера - уже нормальная продюсерская оценка, а не "ну там агент за полчаса напишет".

Почему не довериться ощущению, что с ИИ всё быстрее? В рандомизированном исследовании METR (июль 2025) 16 опытных разработчиков решали 246 задач в своих репозиториях. С ИИ они работали на 19% дольше, хотя до старта ждали ускорения на 24%, а после всё ещё считали, что ускорились на 20% (InfoWorld). Ощущение скорости и скорость - разные вещи, поэтому V только из логов.

Когда формула продюсера не работает

Формула продюсера не работает для фич, где ещё нет ответа "что делаем": новые механики, исследования, переписывание архитектуры. Там темп приёмки нечем мерить, потому что непонятно, что принимать. Такой работе нужен таймбокс с точкой решения, а не срок.

Моя граница простая: если задачу нельзя описать до file:line или до проверяемого критерия готовности - это не задача на оценку, а исследование. Даю ему фиксированный бюджет (вечер, два дня) и в конце решаю: режем на задачи или выкидываем.

Это совпадает с тем, что я записал в разборе конвейера ещё в июле: конвейер уместен для волн диагностированных багов, а фичевые эпики "брейншторм → спека → план" через него не гоняются. Конвейер подключается после, на реализации и стабилизации. Ритм такой: фичевый блок, потом волна стабилизации, потом следующий блок. Как раскладывать эти блоки на квартал, разбирал в статье про роадмап пет-проекта с ИИ-агентами.

И второй случай: переписывание с нуля. Весной я уже пробовал переписать ядро ДнД-бота целиком - не взлетело. Осенью делал переезд по частям, со сверкой записанных ходов после каждого шага, и даже он вылез за свою оценку на неделю. Если кто-то обещает переписать проект с агентом "за выходные" - умножай не на два, а спрашивай, где у него разбор)

Короче: оценивай не агента, а себя как проверяющего. Агент быстрый. Ты - нет. И это нормально, просто закладывай это в срок.