Как оценить coding-агента на собственной задаче

Начните с ошибки, которую хотите перестать видеть

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

Ограничьте объём первого задания так, чтобы человек мог разобраться в затронутом поведении. Полная модернизация репозитория требует множества независимых решений и затрудняет сравнение. Небольшое исправление тоже может менять несколько файлов, но его приёмку можно объяснить коротко. Укажите, какое поведение необходимо сохранить и какие дополнительные изменения требуют отдельного обсуждения. В GrantTap оставьте Task связанной с этой целью: последующие Execution должны продолжать понятный эксперимент. Сначала запишите дефект, потом предполагаемое решение. Иначе вы незаметно начнёте оценивать способность повторить предложенную вами правку, а не разобраться в исходной неисправности.

Определите приёмку до просмотра попытки

Заранее составьте небольшой набор критериев. Включите функциональный сценарий, важную регрессию и условие ревью. Для очереди функциональная проверка может прослеживать одну операцию через переподключение. Регрессия должна сохранять черновик, когда локальное хранилище отвергает отправку. Условие ревью требует объяснить источник каждой квитанции. Это предлагаемые критерии, а не тесты, которые GrantTap незаметно создаёт за пользователя. Решите, как наблюдать каждый результат: содержательным автоматическим тестом, управляемым действием в интерфейсе, чтением файла или сочетанием этих способов. Зелёное имя проверки без понятного сценария не даёт достаточного основания для приёмки.

Оставьте честную категорию неопределённости. Если проверка на устройстве не выполнялась, результат может быть частично подтверждённым. Его не нужно насильно записывать в полный успех или полный провал. Различайте невозможность запустить обязательную проверку и выполненный тест с ошибкой. Решите также, считаются ли недопустимыми лишние изменения, отключённые assertions и ослабление границы доступа. Видимый пример можно «исправить», удалив неудобное поведение целиком. Заранее записанные условия помогают не принять такой обход только из-за убедительной демонстрации. При этом критерии можно корректировать, если исследование показало ошибочность первоначального ожидания; причина изменения должна остаться видимой.

Зафиксируйте условия, влияющие на ответ

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

Сохраните версию клиента, выбранную модель или алиас, поддержанный effort, состояние входа, доступные инструменты и существенные особенности среды. Секреты и идентификаторы аккаунта для этого не нужны. Нужны сведения, позволяющие заметить, что следующая попытка выполнялась иначе. Часть такого инвентаря дают Devices и выбранный разговор GrantTap. Работающая версия MCP отличается от новой версии, которая только установлена на диске. Если провайдер обновился во время оценки, отметьте это. Результат до обновления нельзя выдавать за измерение полностью такого же маршрута после него. Аналогично, прогретый кэш и уже скачанные пакеты являются условиями, а не свойствами модели.

Отделяйте готовность окружения от качества решения

Прежде чем оценивать код, проверьте, мог ли агент начать нужную работу. Отсутствующий CLI, истёкший вход, недоступная папка и неподдержанный инструмент являются проблемами готовности. Они важны для практического выбора, но не доказывают плохое рассуждение модели о программе. Маленький обратимый запрос поможет убедиться, что выбранный компьютер получает работу, а провайдер выдаёт активность в нужном разговоре. При ошибке найдите её источник вместо многократного Send now. Состояние исходной операции сообщает больше, чем несколько новых копий одинакового текста. Каждая такая копия дополнительно усложняет объяснение наблюдаемой истории.

Раздельный учёт готовности подсказывает правильное улучшение. Если агент не увидел репозиторий, более подробное описание алгоритма вряд ли поможет. Если репозиторий доступен, но неверно понята требуемая гарантия, нужны другие вводные, контекст или подход. Полная оценка может одновременно сообщить: маршрут было трудно запустить, а полученное решение выполнило конкретные критерии. Это полезнее одного ярлыка победителя. В GrantTap различайте Saved on relay, Received by computer, Agent activity received и связанный ответ. Сохранение зашифрованного пакета не подтверждает, что модель уже работает над исправлением. Не включайте ожидание неавторизованного CLI в вымышленную скорость размышления модели.

Сделайте помощь человека видимой

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

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

Соберите компактную запись наблюдаемых событий

Сохраните достаточно свидетельств для объяснения результата, не копируя всю частную переписку в отчёт. Укажите Task, соответствующее Execution, исходную ревизию, важные решения, изменённые файлы, выполненные проверки и оставшиеся вопросы. Доступная история и Files выбранного запроса помогают найти эти события, но источники имеют разное покрытие. Отсутствие дочернего разговора может означать, что провайдер его не сообщил. Установленный skill не подтверждает применение. Различайте наблюдаемый вызов, сообщённый успех, записанную правку и результат, который независимо проверил человек. Эти факты дополняют друг друга, но не заменяют.

Так же явно описывайте время. Сохранение на relay, принятие компьютером, первая активность провайдера и проверенная правка являются разными моментами. Если человек десять минут отвечал на вопрос, весь интервал нельзя назвать задержкой модели. Если сборка ждала загрузку зависимости, укажите стоимость окружения. Полное время до пригодного результата всё равно важно: оно отражает реальный процесс. Нужно лишь сохранить его объяснение. Не придумывайте точность, которой нет у источника: приблизительная временная отметка и неполная история не становятся секундомером. Короткая достоверная последовательность событий полезнее подробной таблицы, заполненной догадками ради красивого сравнения.

Проверяйте правку как программное изменение

Читайте diff относительно критериев приёмки. Найдите механизм, который обеспечивает нужное поведение, затем посмотрите соседние пути, способные его обойти. Исправление очереди может защищать обычную кнопку отправки, оставляя Retry источником новой операции. Исправление файла может менять видимый компонент, пропуская альтернативную точку входа. Вопрос состоит в том, закрыта ли конкретная ошибка, а не встречаются ли в коде знакомые слова из задания. В Files проверьте, к какому запросу относятся изменения. Историческую правку нельзя засчитать новым результатом только потому, что она находится в том же разговоре.

Запускайте проверки, существенные для изменения. Используйте существующие тесты, если они действительно упражняют нужное поведение, и добавляйте целевую регрессию, когда дефект этого требует. Избегайте проверок, которые просто повторяют текущий вывод реализации без проверки её назначения. Изменённые тесты требуют такого же внимания, как production-код. Если агент поменял ожидания, выясните, почему прежние были неверны. Успешный suite совместим с плохой правкой, если сценарий не охвачен или assertions ослаблены. И наоборот: старый посторонний сбой нужно сообщить отдельно, не приписывая его автоматически новой работе. Ревью должно связывать каждый вывод с конкретным наблюдением.

Осторожно интерпретируйте повторные попытки

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

Указывайте размер выборки. Если два из трёх выбранных сценариев прошли все критерии, а третий не начался из-за отсутствующей авторизации, так и напишите. Не превращайте небольшой удобный набор в универсальный процент надёжности. Сохраняйте неудачные случаи: исключение неудобных результатов уменьшает практическую ценность метода. Полезно различать классы задач. Клиент может хорошо справляться с изолированным рефакторингом и испытывать трудности с особенностью доставки на конкретном устройстве. Глобальный рейтинг здесь не нужен. Такой результат помогает выбирать следующую работу, готовить контекст и понимать, когда человек должен подключиться раньше.

Сравнивайте расходы и ресурсы по подходящим источникам

Токены провайдера, оценка контекста, прошедшее время, CPU процесса, память и денежный счёт описывают разные вещи. Короткий ответ может скрывать существенную инструментальную работу, а длинное объяснение стоить мало относительно полной сборки. Для денежных выводов используйте реальные данные оплаты провайдера. Наблюдения Usage помогают понять процесс, но оценка контекста не является счётом. Если измерение распределено между несколькими активностями, сохраните пометку attributed. Неизвестную историческую нагрузку нельзя заполнять соседним измерением только ради непрерывного графика. Не суммируйте родительский агрегат и включённые в него дочерние строки повторно.

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

Проведите один намеренно простой пилот

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

Пилот проверяет также качество вашей записи. Попробуйте передать её коллеге, который не следил за разговором. Понятна ли исходная ошибка? Видны ли существенные решения, изменённые файлы и реально выполненные проверки? Если нет, дополните запись, пока подробности свежи. Это помогает будущему сравнению провайдеров, но полезно и в обычной разработке. Главная долговременная ценность небольшой оценки — понятный способ объяснить и проверить работу. Следующий перенос Task получит конкретную основу, а не очередное заверение о том, что всё уже сделано. Человек сможет продолжить проверку без повторного полного исследования.

Пример записи, которую можно оспорить

Представьте задачу сохранения черновика при ошибке загрузки. Исходная запись называет ревизию, изолированный учебный аккаунт, версии клиентов и ожидаемый текст. Критерии требуют, чтобы управляемый отказ хранилища оставлял текст доступным для редактирования, не создавал подтверждённую доставку и позволял последующую осознанную отправку. Проверяющий также смотрит обычный успешный путь, чтобы исправление не сохраняло каждый черновик навсегда. Это пример необходимой конкретики, а не утверждение о выполненной здесь проверке приложения или чужого аккаунта. Значения и способ воспроизведения должны соответствовать вашей среде.

После попытки запись может назвать файлы, проверку отказа и результат обычной отправки. Если агент добавил только предупреждение, но текст всё равно очищается, функциональный критерий не выполнен. Если реализация выглядит убедительно, однако окружение не позволяет вызвать отказ, нужное условие остаётся непроверенным. Второй reviewer может не согласиться с критериями, исследовать механизм или запросить недостающий сценарий без чтения всей переписки. Такой уровень точности делает небольшую оценку полезной вне одного чата. Он также не позволяет выдать аккуратный отчёт за доказательство работы, которую фактически никто не наблюдал.

Превратите итог в ограниченное решение

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

В материале Anthropic об эффективных агентах подчёркивается значение обратной связи от среды для оценки прогресса. Подробный практикум здесь является нашей предложенной методикой локальной работы, а не benchmark Anthropic и не обещанием универсального оценщика внутри GrantTap. Элементы продукта описаны в главах об источниках активности, Task и Execution, доставке и готовности провайдеров. Сохраняйте эксперимент небольшим, доказательства читаемыми, а заключение достаточно конкретным, чтобы оно помогало следующему заданию. Если вывод нельзя применить к определённому маршруту и сценарию, уточните формулировку до публикации сравнительных результатов.

Проверка условий после смены компьютера

Перенос на другой Mac создаёт новый набор условий, даже если Task сохраняет прежнюю цель. Проверьте путь рабочей папки, ревизию, состояние локальных изменений и доступность зависимости, с которой воспроизводится ошибка. Если источник сохранил незакоммиченную работу, назначение может начать с последнего commit. Тогда сравниваются разные входы. Отдельно запишите, был ли создан checkpoint и подтвердил ли компьютер его подготовку. Выбор репозитория из списка является намерением, а не доказательством одинакового состояния файлов.

Для обычной папки без Git опишите переданные материалы и способ проверки их соответствия. Не заставляйте форму выбрать случайный чужой репозиторий ради исчезновения предупреждения. После готовности назначения откройте его Execution, прочитайте доступный контекст и выполните небольшую проверку исходного дефекта. Если дефект уже не воспроизводится из-за иной среды, попытка может быть полезна для диагностики, но она не заменяет сравнимый эксперимент. Сохранение Task не делает два компьютера автоматически эквивалентными.

Как распознать слишком удобный успех

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

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

Сохраните решение для следующего запуска

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

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

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

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