«Прошёл CI» ничего не доказывает: разрыв доверия в ревью ИИ-кода
Зелёный прогон CI доказывает ровно одну вещь: уже существующие тесты всё ещё проходят. Он ничего не говорит о том, покрывали ли эти тесты именно это изменение, сделало ли изменение то, что реально просил тикет, и совпадает ли уверенное описание агентом собственной работы с тем, что он на самом деле сделал. Считать «CI прошёл» доказательством корректности было натяжкой ещё когда PR открывал человек. Сейчас натяжка больше, потому что агент может сгенерировать, описать и смёржить такой PR быстрее, чем кто-либо успеет осмысленно его прочитать.
Почему зелёный пайплайн никогда не был тем же самым, что корректное изменение
CI ловит регрессии в поведении, которое уже закодировано в тестовом наборе. У него нет мнения о требованиях, которые набор не покрывает, а это большинство требований для любого изменения сложнее прямого багфикса. Миграция может чисто пройти в CI и всё равно повредить данные под продовой нагрузкой, которую CI никогда не симулировал. Рефакторинг может пройти все существующие тесты и незаметно сломать поведение, на которое никто не написал тест, потому что никто не ожидал, что оно изменится.
Ничего нового в этом нет. Новое это объём: опрос Sonar 2026 State of Code показал, что ИИ сейчас формирует 42% закоммиченного кода, с траекторией к 65% к 2027 году, а 72% разработчиков пользуются ИИ-инструментами ежедневно. Тот же опрос показал, что 96% разработчиков не доверяют ИИ-коду полностью, но проверяют его перед коммитом всегда только 48%. Именно этот разрыв между заявленным недоверием и реальной практикой и есть настоящий риск, а не сам ИИ-сгенерированный код.
Какое узкое место это реально создаёт
У этого разрыва доверия есть цена, и она измерима: тот же опрос показал, что разработчики тратят почти четверть рабочей недели, 24%, просто проверяя, исправляя и валидируя вывод ИИ, а 38% говорят, что ИИ-код требует больше усилий на ревью, чем код коллеги. Отчёт DORA за 2026 год разбирает сторону этого же узкого места, связанную с пайплайном: больше сгенерированного кода без пропорционально большей пропускной способности ревью даёт не больше выпущенных фич, а очередь.
Стоит быть точным в различии: «налог на верификацию» у DORA про то, что пропускная способность ревью не поспевает за объёмом генерации. Это слой ниже. Даже ревьюер с бесконечным временем и полным вниманием всё равно не может проверить заявление «готово» по одной только зелёной галочке, потому что галочка никогда не создавалась для того, чтобы удостоверять именно то, что заявляет человек или агент.
Какие доказательства реально закрыли бы этот разрыв
«Прошёл CI» это слабая замена трём отдельным вещам, каждая из которых сама по себе была бы более сильным доказательством.
Покрытие конкретного изменения, а не средняя цифра по всему набору. PR, который затрагивает код с нулевым покрытием тестами, и PR, который затрагивает исчерпывающе протестированный участок, покажут одну и ту же зелёную галочку. Именно diff-level покрытие, а не покрытие по всему репозиторию, реально их различает.
Привязанный критерий приёмки, а не самоописание. Описание PR от агента говорит о том, что агент считает, что он сделал. Критерии приёмки тикета говорят о том, что реально требовалось. Это два разных документа, и то, что CI прошёл, никак не подтверждает, что они говорят об одном и том же.
Сигнал уверенности от самого агента, а не только статус. Кодовые агенты всё чаще способны отмечать собственную неуверенность: шаг, в правильности которого они не были до конца уверены, допущение, которое они сделали, потому что тикет был сформулирован неоднозначно. Этот сигнал теряется в тот момент, когда «готово» схлопывается в единый статус без места для его переноса. Тикет, который может держать состояние «готово, но я не был уверен насчёт X», полезнее того, который умеет держать только «готово».
Где это реально работает уже сейчас, а где ещё нет
Чтобы быть точным насчёт того, где инструменты реально находятся сегодня, а не там, где обещает презентация: TAM привязывает активность по PR, ревью и CI к соответствующему тикету автоматически в момент, когда это происходит, через вебхук, так что ревьюеру не приходится восстанавливать реальное состояние PR по пяти вкладкам браузера. Запрос ревью или запись конкретного доказательства по тикету, результата теста, вывода сканера, заметки ревьюера, фиксируется как отметка времени прямо на самом issue.
Это видимость и аудит-лог. Это не жёсткий гейт сегодня: ничто сейчас не блокирует перевод тикета в Done, если проверка не пройдена, и слой принуждения именно к этому прямо сейчас в разработке, а не уже поставлен. Честная формулировка уже, чем «TAM проверяет работу вашего ИИ»: прямо сейчас инструмент делает так, что доказательства невозможно потерять из виду, а это и есть большая часть того, что реально нужно ревьюеру, у которого уже 24% недели уходит на то, чтобы вручную выуживать именно этот контекст.
Более общий тезис верен независимо от того, каким трекером кто пользуется. PR, который прошёл CI, и PR, который реально корректен, выглядят с доски одинаково. Закрыть этот разрыв можно только доказательством, привязанным к заявлению, а не более быстрым способом это заявление сделать.