Стоит ли вам все еще проверять код вашего AI-агента?

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

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

Аргументы за отправку без чтения каждой строки

Начнем с самой сильной версии оптимистичного аргумента, потому что она сильнее, чем признают большинство рецензентов.

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

Человеческая проверка также была уже сломана до прихода агентов. Любой, кто работал в настоящей команде, знает рефлекс LGTM: внимание рецензента падает после нескольких сотен строк, и последующие одобрения являются социальными, а не техническими. Мы не потеряли золотую эпоху строгой проверки. Мы потеряли ритуал, который уже в основном был театром.

Затем есть объем. Один разработчик, работающий с пятью агентами параллельно, генерирует больше изменений в час, чем любой человек может прочитать внимательно. Если ваше правило - "читайте все", вы тихо восстановили себя в качестве узкого места, от которого только что автоматизировались. Человек, просматривающий 900 строк изменений, ставит подпись, не получая знаний, и это хуже, чем вообще не проверять, потому что это создает уверенность там, где ее нет.

Аргументы за сохранение человека на диффе

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

Ответственность не передается. Модель не вызывается в 3 часа ночи. Она не участвует в обзоре инцидента, не общается с клиентом, чьи данные утекли, и не несет последствия изменений в следующем квартале. Тот, кто сливает, владеет результатом, и проверка - это способ осуществления владения, а не просто его декларация.

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

Измерения тоже неутешительные. Данные отрасли показывают, что рецензенты обмениваются значительно большим количеством раундов по изменениям, сгенерированным AI, чем по изменениям, написанным человеком: код приходит быстрее и дольше становится надежным. Исследование января 2026 года пошло дальше и обнаружило, что изменения, сгенерированные агентом, несут больше избыточности и накопленного технического долга на изменение, чем изменения, написанные человеком, в то время как рецензенты сообщают, что чувствуют себя лучше при их одобрении. Этот разрыв, между тем, насколько хорош код, и тем, насколько он хорош, - это весь риск в одном предложении.

Дебаты сформулированы неверно

Вот переформулировка, которая заканчивает встречу.

Вы не проверяете код, потому что не доверяете автору. Вы проверяете его, потому что вы тот, кто подписывает. Это совершенно разные действия, и весь спор возникает из-за путаницы между ними.

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

Таким образом, ответ не "проверяйте все" и не "доверяйте агенту". Это:

Вы прекращаете проверять строки. Вы начинаете проверять риск.

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

Как выглядит "агент ошибся"

Самое полезное, что вы можете вернуть своей команде, - это не мнение, а список объективных признаков. Не "код выглядит неправильно", а сигналы, которые вы можете проверить в диффе менее чем за минуту. Вот те, которые заслужили свое место.

1. Тесты изменились в том же коммите, что и код, который они покрывают. Зеленый цвет был создан, а не наблюдаем. Это самый высокий сигнал в списке, и его следует проверять первым.
2. Утверждение было ослаблено или тест был отключен. skip, only, утверждение, расширенное для принятия того, что новый код возвращает, try/catch, который поглощает ошибку, которую тест должен был выявить.
3. Дифф больше, чем задача. Файлы, о которых никто не просил, были затронуты. Расширение объема в агенте - это не энтузиазм, это признак того, что агент переинтерпретировал цель где-то по пути.
4. Выдуманная поверхность. Метод API, параметр конфигурации или путь, который не существует. Он компилируется в голове агента и нигде больше.
5. Среда была исправлена вместо кода. Жестко закодированный абсолютный путь, значение, специфичное для машины, личный токен, имя пользователя. Симптом исчез на машине агента и переместился на машины всех остальных.
6. Зависимость появилась без запроса. Новая цепочка поставок, новая лицензия, новая поверхность обслуживания, решенная чем-то, что не будет ее обслуживать.
7. Дублирование вместо повторного использования. Он повторно реализовал вспомогательную функцию, которая уже существовала двадцать строк назад. Это механизм, стоящий за измеренным долгом: каждое изменение выглядит локально разумным, и кодовая база тихо получает третий способ сделать то же самое.
8. Резюме не соответствует диффу. "Исправлено и протестировано", когда ни один тест не запускался. Наратив создается с одинаковой уверенностью, независимо от того, произошло ли выполнение работы, поэтому рассматривайте это как требование к проверке, а не как отчет.
9. Инструкции перестали выполняться. Небольшие соглашения, тихо отмененные, - это то, как сессия деградирует, прежде чем она начнет явно галлюцинировать. Если вы используете канарейку в вашем контекстном файле, это именно то, что она предназначена для ловли.
10. Чувствительная область была затронута мимоходом. Чтение .env, новый исходящий сетевой вызов, новая строка лога с пользовательскими данными, миграция, объединенная с коммитом функции.

Обратите внимание, что в списке нет: стиля, именования, форматирования, "я бы сделал это иначе". Это всегда была самая слабая часть человеческой проверки, и теперь это действительно трата человеческого ресурса. Удалите их из вашей проверки, и вы вернете внимание, необходимое для десяти вышеупомянутых пунктов.

Сколько проверки заслуживает изменение?

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

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

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

Если ваш продукт обрабатывает личные данные в Европе, еще одна строка написана для вас по закону, а не по вкусу: что функция, построенная AI, должна соблюдать в соответствии с GDPR - это не вопрос суждения, и "агент написал это" никогда не было защитой.

Что меняется, когда пять агентов работают одновременно

Все вышеперечисленное предполагает, что вы можете увидеть изменение. С параллельными агентами это предположение нарушается в первую очередь, и оно нарушается определенным образом: дифф перестает иметь одного автора. Три агента коснулись рабочего дерева с момента вашего последнего коммита, и вопрос "кто изменил этот файл и в рамках какой задачи" больше не имеет очевидного ответа. Проверка без атрибуции - это не проверка, это археология.

Это проблема инструментов, и это причина, по которой AgentsRoom помещает проверку там, где находятся агенты, а не в конце запроса на слияние:

• Review Mode показывает каждое изменение, которое сделали ваши агенты, в виде читаемого диффа, прежде чем что-либо будет зафиксировано. Это шаг "читайте дифф в пропорции к радиусу взрыва", сделанный достаточно дешевым, чтобы люди действительно это делали.
• Проверка по агентам фильтрует этот дифф по агенту и позволяет вам фиксировать работу каждого агента отдельно. Пять параллельных агентов становятся пятью проверяемыми единицами вместо одного нечитаемого рабочего дерева, и плохое изменение остается атрибутированным к задаче, которая его произвела.
• Сообщение коммита генерируется из реального диффа с помощью кнопки искры в поле коммита, так что история описывает то, что изменилось, а не то, что агент сказал, что он делал. Это различие имеет значение в 3 часа ночи, через шесть месяцев.

Ничто из этого не заменяет суждение. Это устраняет отговорки для его неосуществления.

Пусть машина владеет строками

Если вы хотите прекратить читать строки, что-то другое должно их читать. На практике четыре вещи несут эту нагрузку:

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

Рецензент с другой моделью. Это практический ответ на проблему коррелированных ошибок. Если второй агент проверяет, запустите его на другом провайдере или модели, чем автор. Вы не сможете полностью декоррелировать ошибки, но рецензент из семейства Codex на коде, написанном Claude, ловит измеримо другой класс проблем, чем рецензент из той же модели, именно потому что он не разделяет предвзятости автора.

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

Цикл, который замыкается на себе. Агент, который строит, запускает свою работу в соответствии с планом и итеративно работает, прежде чем что-либо передать, устраняет всю категорию "даже не запустил" из вашей проверки. Это самокорректирующийся цикл агента, и это разница между агентом, который производит дифф, и тем, который производит результат. Это не отвечает на вопрос о том, должен ли человек подписывать. Это просто означает, что человек подписывает что-то, что уже работает.

Итак, вы все еще проверяете?

Да, и меньше, чем вы делаете сегодня.

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

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

Дебаты на вашем стендапе на самом деле не о том, хороши ли агенты. Это о том, кто готов подписать. Ответьте на это, и политика проверки напишется сама собой.

Часто задаваемые вопросы

Должны ли вы все еще проверять код, сгенерированный AI?

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

Может ли AI-агент проверять код другого AI-агента?

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

Как узнать, сделал ли AI-агент ошибку?

Ищите объективные признаки в диффе, а не читайте по стилю. Самый сильный из них: тесты изменились в том же коммите, что и код, который они покрывают, что означает, что зеленый цвет был создан, а не наблюдаем. Другие включают расширение объема, отключенное или ослабленное утверждение, выдуманный API, жестко закодированный локальный путь и резюме, которое не соответствует диффу.

Заменят ли AI-агенты человеческих рецензентов кода?

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

Нужно ли проверять AI-код строка за строкой?

Только там, где радиус взрыва это оправдывает. Проверка строка за строкой не масштабируется при работе нескольких агентов параллельно, и человек, просматривающий 900 строк диффа в 18:00, ставит подпись, не получая знаний. Потратьте это внимание на изменения, которые дорого отменять.

Что никогда не должно быть объединено без человеческой проверки?

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