Работа с ИИ-агентами: поручить дёшево, проверить дорого

Задачу агенту можно поставить в одну строку и за несколько секунд, а вот проверить, что он сделал, за несколько секунд уже не получится.

В сентябре 2025 года на GitHub появлялось около 4 миллионов пул-реквестов от ИИ-агентов в месяц, а к марту 2026 их число превысило 17 миллионов: рост вчетверо за полгода по данным The Information. Писать код стало дёшево, а проверять результат человеку осталось так же дорого, как и раньше. Именно этот разрыв сдвинул узкое место разработки с производства кода на его приёмку.

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

Постановка задачи: информация уже неравная

В момент, когда человек формулирует запрос агенту, асимметрия только зарождается. Агент выдаёт правдоподобный текст или код, но откуда он взял факты и почему собрал их именно так, заказчику неизвестно. Показательный пример касается не кода, а текстов: исследователи из National Taiwan University обнаружили, что языковые модели склеивают реальные сведения о разных людях с одинаковыми именами в биографию несуществующего человека. После поправки на неоднозначность подобных сущностей оценки фактичности четырёх открытых моделей упали более чем на 10% разбор Bothub. Тот же разбор перечисляет похожие виды брака: в одной ссылке пересказ вместо первоисточника, в другой - описание соседнего рынка вместо нужного, а где-то два правдивых по отдельности факта склеены причинной связью, которой в источниках не было. Агент отвечать за эти пропуски сам не обязан.

Здесь же рождается иллюзия продуктивности: пока модель работает над задачей, человек уже берёт вторую и третью. Через час на счету может оказаться дневная норма работы, только вся она “лежит” непроверенной, пока кто-то не сядет и не разберёт каждую строчку.

Приёмка: где расходы на контроль удваиваются

С появлением агентов объём ревью не сокращается, а растёт. Человек проверяет код агента, а затем изменение всё равно проходит обычное человеческое ревью коллеги: слой контроля не заменяется, а достраивается сверху. Одновременно агенты увеличивают общее число изменений, и ресурс на проверку исчерпывается быстрее, чем успевает окупиться выигрыш от их использования. На практике чаще случается другое: контрибьютор (тот, кто предлагает изменения) бегло смотрит код агента и отправляет его на ревью, а замечания ревьюера просто пересылает обратно машине на доработку. Ревьюер теряет дешёвый способ оценить, сколько усилий автор действительно вложил в задачу, и в результате появляются “мусорные пул-реквесты”, которые постепенно убивают открытые проекты.

Проверка устроена по-разному в зависимости от типа задачи, и это меняет её стоимость. Код проверяется тестами. Математика проверяется формально: модель AlphaProof решила 4 из 6 задач международной олимпиады по математике 2024 года и набрала 28 баллов, что соответствует уровню серебряной медали. Данные проверяются воспроизводимостью расчётов, но такая проверка не защищает от изначально плохих исходных цифр. Тексты проверяются сверкой с первоисточниками. Стратегии не проверяются заранее вообще, их можно оценить только по факту. Там, где проверка автоматизируется полностью, эффект заметен: DeepMind ускорила вычислительное ядро модели Gemini на 23% с помощью AlphaEvolve, сократив общее время обучения на 1%, именно за счёт того, что варианты решений проверялись программой, а не человеком. Подход “сначала источник, потом ответ” предлагает находить фрагменты первоисточников до того, как строить итоговый текст, а не после. Национальный институт стандартов и технологий США (NIST) и европейский закон об ИИ увязывают объём проверки с уровнем риска: для систем в кредитовании, найме и медицине требования жёстче, потому что цена ошибки там выше.

Ответственность: кто отвечает за результат

Нынешний порядок ревью сложился ещё до всякого ИИ. Процесс “сначала ревью, потом коммит” оформился в 1990-х в проекте Apache Server, закрепился в Google в начале 2000-х и распространился благодаря инструментам вроде пул-реквестов на GitHub. Человек вносит изменение, отправляет его на ревью, ревьюер комментирует до получения одобрения, изменение попадает в основную ветку. Такой порядок плохо ловит баги, зато передаёт знание о дизайне и нормах проекта, работает при низком уровне доверия между участниками и хорошо масштабируется в командах больше десяти-двенадцати человек, а также в открытых проектах.

Есть и другой исторический пример. В Microsoft 1990-х обязательного ревью перед коммитом не существовало, команды синхронизировались через QA, и именно так появился Win32 API. Логика похожа на решение, которое подходит малым командам с высоким взаимным доверием сегодня: человек сам ставит задачу агенту, сам проверяет результат и сам его выкладывает в продакшен, не размывая ответственность между несколькими людьми. Так работает компания exe.dev из девяти человек, опирающаяся на интеграционные и end-to-end тесты и на агентные пайплайны анализа рисков. В крупных компаниях с низким уровнем доверия между сотрудниками такая схема нежизнеспособна: обычное ревью там как раз и нужно, чтобы размазать ответственность за возможные инциденты между несколькими людьми, а не концентрировать её на одном. Надёжного процесса, который позволил бы масштабировать агентную разработку в крупных организациях, пока не найдено.

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

Cursor и порог автономии агентов

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

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

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

Индустрия уже строит бизнес на проверке

Спрос на автоматизацию контроля успел породить отдельный рынок. 12 августа два стартапа, занимающихся проверкой кода, привлекли крупные раунды: CodeRabbit получил 143 миллиона долларов при оценке в 1,5 миллиарда, Blacksmith - 45 миллионов при оценке 550 миллионов. CodeRabbit устроен как конвейер из семи-восьми моделей: сбор контекста из линтеров, графа связей кода, тикетов Jira и логов, сжатие всего этого в краткий бриф, расследование передовой моделью прямо в терминале песочницы и финальная модель-судья, отсекающая необоснованные находки. На пике сервис обрабатывает 10 ревью в секунду, у него 17 тысяч клиентов, включая Nvidia, BMW и Adyen, более 2 миллионов ревью в неделю и выручка, выросшая впятеро за год. Новый модуль Triage распределяет пул-реквесты по ценности и риску, направляя часть людям, а часть в автоматическую обработку.

Похожий инструмент есть и у самой Anthropic: 9 марта компания запустила функцию код-ревью для Claude Code, где пять параллельных агентов проверяют изменения. Доля пул-реквестов с замечаниями выросла с 16% до 54% при доле ошибок менее 1%. Но модель, которая проверяет код, принадлежит тому же семейству, что и модель, которая его написала, а значит, конфликт интересов из модели “принципал и агент” здесь не исчезает, а просто переносится на уровень выше. Показательны и цифры самой компании: более 80% кода Anthropic сейчас пишет модель, а опрос сервиса Sonar фиксирует, что 61% разработчиков регулярно получают ИИ-код, который выглядит правильным, но которому нельзя доверять без проверки, и 38% считают ревью такого кода труднее, чем ревью человеческого.

Blacksmith решает смежную задачу - ускорение непрерывной интеграции. Вместо GitHub Actions от Microsoft тесты прогоняются на игровых процессорах с быстрыми одиночными ядрами, что вдвое быстрее и дешевле. Число задач у Blacksmith растёт на 5-10% в неделю с начала 2026 года, а число клиентов увеличилось с 800 до 6000 за год. Отдельный модуль Codesmith умеет сам чинить упавшие проверки.

При этом качество автоматической проверки пока не выше среднего. Независимый аудит проекта Lychee по 28 пул-реквестам, обработанным CodeRabbit, показал, что полезными оказались лишь 35% комментариев, 21% были придирками, а 15% оказались бесполезными; бенчмарки разных инструментов друг другу противоречат. Тем не менее аналитики 360iResearch оценивают весь рынок сервисов ревью уже в 3 миллиарда долларов.

Три опоры контроля: гейты, права, метрики

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

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

Вторая опора - какие права у агента есть, а какие нет, причём доступ к продакшену стоит здесь особняком. В exe.dev человек сам ставит задачу, сам проверяет результат и сам выкладывает его в прод: последний шаг, тот, что напрямую затрагивает работающую систему, агенту не передаётся вообще. У Cursor похожий принцип реализован архитектурно, в проекте Grokbot: строгий CI запрещает опасные паттерны вроде необузданного использования useEffect и посторонних комментариев в коде, а также проверяет граф зависимостей, чтобы рендерер-процесс не мог импортировать модули главного процесса Electron. Ограничения заданы заранее, на уровне архитектуры, а не решаются на глазок под конкретного агента, и именно поэтому присылать изменения в проект может даже продакт-менеджер без инженерного бэкграунда: один из них самостоятельно исправил баг и прошёл все проверки CI, потому что рамки допустимого не зависели от того, кто или что вносит правку.

Третья опора - метрика, по которой судят об успехе. Рост числа обработанных пул-реквестов или скорость их слияния ничего не говорят о качестве результата: это метрика “стало ли быстрее”, а не “стало ли лучше”. У Anthropic доля пул-реквестов с реальными замечаниями выросла с 16% до 54% при доле ошибок меньше 1% - здесь измеряется не то, сколько кода прошло через конвейер, а то, сколько из найденного действительно оказалось проблемой. Аудит Lychee показывает обратную сторону той же логики: из комментариев CodeRabbit полезными оказались лишь 35%, 21% - придирки, а 15% - откровенно бесполезны. Инструмент может обрабатывать по 10 ревью в секунду и всё равно приносить мало пользы, если никто отдельно не меряет долю находок, которые действительно стоило поднимать.

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

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