Шестьдесят восемь замечаний к ревью привели к тому, что функция выросла с 28 до 42 строк, с 62 исправлениями, каждое из которых решало реальную проблему. Проблема заключалась не в точности рецензента, а в отсутствии в проекте процедуры принятия решений по комментариям. В проекте AgentCoop, системе ИИ-агентов, использовался Codex от OpenAI для автоматизированного ревью кода, с жестким правилом обрабатывать все комментарии. Это часто приводило к исправлению комментариев без учета более широких последствий.Возникли четыре основные проблемы: разрастание объема из-за мелких, точных исправлений; срочное рассмотрение тегов "безопасность" или "доступность" независимо от фактического воздействия; плохие компромиссы, когда добавлялась постоянная сложность кода для редких или несуществующих проблем; и исправление там, где указывал комментарий, а не первопричина. "Критическая" проблема, связанная с тем, что обновление нарушило конфигурационный файл, была первоначально эскалирована, но позже решена одним абзацем в документации. Фактическое воздействие на пользователя было минимальным и сводилось к нескольким минутам корректировки конфигурации, а не к общесистемному сбою.Затем команда разработала процедуру оценки замечаний к ревью, выходящую за рамки интуитивных ощущений. Во-первых, три быстрых вопроса определяют, является ли исправление дешевым (менее десяти строк), может ли проблема действительно произойти и происходит ли она молча (требуя как минимум логирования). Дешевые исправления реализуются немедленно, недостижимые пути кода отбрасываются, а молчаливые сбои приоритизируются или делаются явными. Важным условием для "дешевого" является рассмотрение самого дешевого эффективного исправления, а не обязательно предложения рецензента.Для комментариев, прошедших первый этап, проводится количественная оценка в часах. Она включает оценку стоимости ошибки за инцидент, ее годовой частоты, допустимого неудобства для пользователя (через множитель), времени сборки исправления и его постоянных годовых затрат на обслуживание. Эти значения используются для расчета годовой экономии и срока окупаемости исправления. Если чистая годовая экономия равна нулю или отрицательна, исправление считается нецелесообразным.В начальном примере проблема разбора конфигурации имела отрицательную чистую экономию при анализе, что доказывает, что ее не следовало исправлять. Оценка частоты инцидентов требует построения числа из конкретных, подтвержденных частей, а не угадывания. Состояния гонки аналогично оцениваются путем рассмотрения триггерных действий и уязвимых окон, приоритизируя сценарии, где события намеренно согласованы, а не чистое совпадение.