Почему Claude Code плохо оценивает сроки задач и как считать точнее

Короткий ответ: Claude Code оценивает не часы агента, а задачу с неизвестными

Claude Code может назвать срок, похожий на оценку обычной разработки, потому что получает неполное описание задачи и не знает фактическое состояние репозитория, качество тестов, поведение API и будущий объём правок. LLM распознаёт тип работы по тексту запроса и строит правдоподобный прогноз по знакомым паттернам. Это вероятное объяснение, а не подтверждённый экспериментальный факт о механике оценки сроков именно в Claude Code.

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

В доступных материалах нет статистики, которая доказывает точность или степень ошибки оценок Claude Code. Поэтому нельзя обещать, что хороший промпт даст гарантированный срок. Методика ниже нужна для калибровки прогноза под конкретный проект и рабочий процесс.

• Определите, какая метрика нужна: активное время агента, время человека или календарный дедлайн.
• Разделите исследование, изменение кода, тестирование, ревью и исправления.
• Для каждого этапа укажите результат, зависимости, диапазон и уровень уверенности.
• Ведите журнал планового и фактического времени по похожим задачам.
• Пересматривайте прогноз после появления новой информации.

Почему модель завышает срок: где заканчивается факт и начинается гипотеза

В описании разработки часто смешаны анализ, написание кода, ожидание доступа, ручная настройка, тесты, ревью и несколько циклов исправлений. Когда запрос содержит одну фразу вроде «добавь авторизацию», агенту приходится достраивать значительную часть плана. Чем больше пробелов он заполняет предположениями, тем слабее оценка сроков.

Модель видит тип задачи, а не полный план выполнения

Фраза «добавить авторизацию» не говорит, какой провайдер нужен, есть ли пользовательская модель, требуется ли миграция, как устроены сессии, где хранятся секреты и какие сценарии уже покрыты тестами. Для Claude Code это разные задачи с разной стоимостью проверки и разным числом точек отказа.

Перед оценкой нужно сделать скрытую работу видимой:

• прочитать структуру репозитория и правила проекта;
• найти точки входа, конфигурацию и затрагиваемые модули;
• проверить схему данных и необходимость миграции;
• описать обработку ошибок и пограничные сценарии;
• определить команды тестирования и ручной приёмки;
• выяснить, нужна ли документация, настройка окружения или изменение CI.

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

Человеческий срок, время агента и календарный дедлайн - разные величины

Слово «срок» стоит заменить на несколько независимых метрик. Иначе десятиминутное изменение кода превращается в спор о том, почему задача заняла полдня.

Метрика	Что входит	Зачем считать отдельно
Активное время AI-агента	Анализ файлов, вызовы инструментов, генерация и правка кода, запуск команд	Показывает расход времени сессии агента
Активное время разработчика	Постановка задачи, ответы на вопросы, ревью diff, ручные проверки, исправление требований	Показывает нагрузку на команду
Внешнее ожидание	CI, доступы, ответ владельца API, подготовка тестовых данных, очередь на деплой	Часто определяет календарную дату
Календарный срок	Время между стартом и готовым принятым результатом	Нужно для планирования релиза

В иллюстративном сценарии агент тратит 35 минут на действия, разработчик 20 минут на ревью, а CI работает 25 минут. При последовательном процессе календарная длительность составит минимум 80 минут, хотя код был написан заметно раньше. Агентская разработка сокращает часть активной работы, но не отменяет проверку результата и внешние блокировки.

Баланс этих метрик зависит и от инструмента. Сравнивать coding agents полезно по времени до принятого результата, количеству итераций и потребности в ручном контроле, а не по скорости первой генерации кода. Подходы к такому сравнению разобраны в статье Claude Code и Codex: как выбирать coding agent под тип задачи.

Скрытые зависимости превращают одно число в слабый прогноз

Даже хорошо сформулированная задача расширяется при первой проверке интеграции. Пример: форма на сайте должна создать или обновить контакт в CRM, добавить источник кампании, уведомить менеджера и запустить follow-up сценарий. Сам вызов API может быть коротким этапом, но система ещё должна выбрать правильный Contact, Company, Deal или Account.

Для такой связки заранее уточняют правила record matching, обязательные поля, момент синхронизации, права на запись, обработку повторного события и поведение при частичном сбое. Нативные интеграции часто покрывают базовый обмен данными, а сложные сценарии требуют API, webhooks, кастомных полей и правил автоматизации. Пока эти предпосылки не проверены, срок содержит существенную неопределённость.

Декомпозиция задач для AI-агента: как перейти от одной оценки к плану

Декомпозиция задач для AI-агента превращает общий запрос в последовательность небольших работ с наблюдаемым результатом. Агенту проще оценить «найти текущий обработчик callback и описать поток данных», чем «добавить интеграцию и подготовить к релизу».

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

Сначала определить результат и критерии готовности

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

• Endpoint POST /api/session возвращает ожидаемый статус для валидных и невалидных учётных данных.
• Миграция выполняется на тестовой базе и имеет обратимый план отката, если он требуется правилами проекта.
• Новый webhook не создаёт дубликат записи при повторной доставке события.
• Команда тестов проходит в указанном окружении без ручной правки конфигурации.

Критерий готовности снимает часть неопределённости ещё до начала работы. Формулировка «сделать авторизацию лучше» не имеет проверяемого финиша. Формулировка «добавить rate limit на пять неудачных попыток и покрыть сценарий тестом» уже позволяет выделить модули, тесты и риски.

Разделить исследование, написание кода, проверку и исправления

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

Этап	Результат	Активное время агента	Время человека	Типичный блокер
Исследование	Карта затрагиваемых модулей и список вопросов	15-35 минут	0-10 минут	Неясная архитектура
Проектирование изменения	План файлов, контрактов и проверок	10-25 минут	5-15 минут	Неясные требования
Написание кода	Diff с основным изменением	25-60 минут	0-10 минут	Скрытая связность модулей
Тестирование	Результаты автоматических и ручных проверок	15-45 минут	10-20 минут	Нестабильная среда
Ревью и исправления	Принятый diff или список замечаний	10-40 минут	10-30 минут	Новые замечания к логике

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

Считать зависимости до начала написания кода

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

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

Проверять оценку на уровне отдельных шагов

У хорошего этапа есть один результат и способ проверить завершение. Если шаг нельзя оценить без двух или трёх дополнительных решений, его стоит разделить. Например, «подключить платёжный сервис» лучше превратить в исследование API, настройку учётных данных, создание клиента, обработку webhook, тестирование повторной доставки и ручную проверку тестовой оплаты.

Итоговый прогноз складывают из диапазонов этапов. Нижняя граница описывает путь без выявления новых проблем. Верхняя включает известные риски и отдельное ожидание внешних систем. Формат «45-90 минут активной работы агента, 20-40 минут участия разработчика, внешний срок зависит от CI и доступа к API» полезнее, чем число «два часа» без пояснений.

Собственная статистика: как откалибровать прогнозы под ваш проект

Универсальная поправка для всех задач быстро перестаёт работать. Знакомый модуль, новая интеграция, миграция данных и задача с расплывчатыми требованиями имеют разные источники риска. Нужны исторические данные по похожим работам в конкретном репозитории.

Какие поля фиксировать после каждой задачи

Журнал не должен превращаться в отдельный проект. Достаточно одной строки на завершённую задачу со следующими полями:

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

Полезно отдельно хранить неизвестные, которые обнаружились уже во время работы: устаревший SDK, отсутствие доступа, неописанное правило бизнес-логики, непредсказуемое поведение API. Через несколько задач такой список показывает, какие вопросы нужно задавать агенту в начале.

Как считать коэффициент корректировки

Для сопоставимого класса задач можно сравнить фактическое активное время с первоначальным планом:

коэффициент = фактическое активное время / исходная оценка активного времени

Представим четыре небольших изменения в знакомом модуле. Коэффициенты получились 1,1, 0,9, 1,4 и 1,2. Медиана равна 1,15. Если новая похожая задача первоначально оценена в 40 минут активной работы агента, центральный ориентир после поправки составит 46 минут. Диапазон всё равно нужен: один коэффициент не отражает будущий объём ревью, доступность окружения и скрытые зависимости.

Медиана полезнее среднего при небольшой выборке: одна задача с затянувшимся доступом или сломанным CI меньше искажает результат. Маленькая либо неоднородная выборка не даёт оснований для уверенных прогнозов.

Почему одна общая поправка быстро становится бесполезной

Коэффициент 1,15 для небольших изменений в знакомом сервисе нельзя переносить на миграцию данных или первую интеграцию с внешним API. В миграции риск создают объём данных и обратимость. В интеграции - доступы, сопоставление сущностей, webhooks и timing. В новой функциональности с неясными требованиями основная неопределённость часто находится в согласовании поведения.

Сегментируйте статистику по проекту, классу задачи, затронутой подсистеме и уровню участия человека. Такой подход помогает сравнивать и разные агентные модели по измеримому результату, а не по единичному удачному запуску. Риски длинных агентных задач и критерии их проверки разобраны в материале о надёжности агентных моделей и практическом риске.

Изменчивый контекст и system prompt: что важно передавать агенту

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

Стабильные правила держать отдельно от текущего состояния

В стабильной части контекста держат правила проекта: стиль кода, структуру ответа, обязательные проверки, запреты и порядок работы с секретами. В каждом конкретном запросе передают текущий Git status, результаты последних тестов, изменённые файлы, найденные ошибки, доступные команды и блокеры.

Для Claude Code описан подход со стабильным system prompt и изменчивым контекстом внутри блоков user message. Это согласуется с принципом prefix-based prompt caching: порядок частей запроса строится как tools, system, messages, а изменение состояния в системном префиксе приводит к cache miss и повторной обработке накопленного контекста. Такой эффект относится к эффективности обработки. Прямых данных, что попадание в кэш само по себе повышает точность оценки сроков, нет.

Какой контекст нужен для оценки конкретной задачи

Передайте Claude Code сведения, которые позволяют заменить догадку проверяемым фактом:

• цель задачи и критерии готовности;
• состояние репозитория и уже выполненные шаги;
• затрагиваемые модули, файлы и контракты;
• доступные команды, тесты и ограничения окружения;
• внешние сервисы, учётные данные и известные ошибки;
• требования к ревью, документации и ручной приёмке;
• что явно не входит в задачу.

Попросите агента первым пунктом вывести сведения, которых ему не хватает. Если Claude Code сразу выдаёт подробный срок без вопросов при недостаточном контексте, такую оценку стоит маркировать как предварительную.

Интеграции требуют отдельной проверки предположений

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

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

Рабочий шаблон запроса для оценки Claude Code

Шаблон ниже заставляет Claude Code сначала собрать недостающий контекст, затем построить декомпозицию и выдать диапазон. Его стоит использовать до начала изменения кода и повторно после исследовательского этапа.

Какие инструкции включить в запрос

Оцени задачу после изучения переданного контекста. До оценки не меняй код.

Цель: [краткий ожидаемый результат]
Критерии готовности: [тесты, поведение, ручная проверка]
Границы задачи: [затрагиваемые модули и исключения]
Текущее состояние: [Git status, результаты тестов, ошибки, уже сделанные шаги]
Ограничения: [среда, доступы, внешние сервисы, правила проекта]

Сначала:
1. Перечисли допущения, которые используешь.
2. Назови неизвестные факторы и вопросы, без которых прогноз неточен.
3. Отдели подтверждённые факты от предположений.

Затем разбей работу на этапы. Для каждого этапа укажи:
- действие;
- наблюдаемый результат;
- диапазон активного времени агента;
- диапазон активного времени разработчика;
- внешнее ожидание;
- зависимости и блокеры;
- уровень уверенности;
- критерий завершения.

Отдельно оцени исследование, тестирование, ревью и исправление замечаний.
В конце дай общий диапазон, критические риски и условия пересмотра оценки.
Не заменяй диапазон одним числом. Если контекста недостаточно, сначала выдай вопросы и план исследования.

Пример структуры ответа агента

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

Этап	Действие	Результат	Время агента	Время человека	Зависимость	Уверенность
Исследование	Проверить обработчик и существующие тесты	Список файлов и точек изменения	15-30 минут	0-10 минут	Доступность репозитория	Средняя
Контракт	Уточнить формат запроса и ответа	Согласованный интерфейс	10-20 минут	5-15 минут	Ответ владельца API	Низкая
Изменение кода	Добавить обработку сценария	Diff и локальный запуск	20-50 минут	0-10 минут	Вывод исследования	Средняя
Проверка	Запустить тесты и ручной сценарий	Лог результатов	15-40 минут	10-20 минут	Тестовая среда	Средняя

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

Как обновлять оценку после каждого контрольного шага

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

После генерации diff остаётся обязательная проверка логики, конфигурации, тестов и runtime-сценариев. Практический порядок ревью AI-кода описан в статье почему код AI-агента нужно проверять. Время на эту работу нужно включать в прогноз отдельно.

Что не исправит даже хороший промпт

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

Интеграционная сложность проявляется только при проверке связки

Задача может выглядеть короткой на уровне одного клиента API и оказаться большой на уровне системы. Ошибка в схеме данных, правилах record matching, timing обновлений, webhook, правах доступа или обработке повторного события часто обнаруживается при первом рабочем прогоне. Такие проверки должны быть отдельными этапами с собственным диапазоном и критерием готовности.

Правки по ходу работы нельзя надёжно предсказать заранее

Базовое изменение кода и циклы исправлений стоит учитывать раздельно. В прогнозе явно указывают, включены ли автоматические тесты, ручная приёмка, ревью, исправление замечаний и повторная проверка. Число будущих итераций нельзя объявлять известным фактом до их появления.

Как формулировать финальный прогноз

Финальный прогноз должен содержать диапазон, основу расчёта, уровень уверенности, критические допущения и триггеры пересмотра. Для планирования используйте наиболее вероятный сценарий вместе с резервом на перечисленные неизвестные. Не подменяйте такой резерв универсальным процентом.

Прогноз: 60-110 минут активной работы AI-агента, 30-60 минут участия разработчика, до 40 минут внешнего ожидания. Уверенность средняя. Пересмотр нужен после проверки тестовой среды, подтверждения API-контракта и первого запуска интеграционного сценария.

Claude Code полезен для быстрого плана и первичной декомпозиции. Точный срок появляется из проверяемых этапов, актуального контекста и накопленной статистики по похожим задачам.

Подписаться на канал