У меня пока есть довольно простое правило. Если AI изменил код — я читаю diff. Весь. Не summary. Не список изменённых файлов. Не отчёт «добавлено 12 тестов, исправлено 3 класса, все проверки проходят». А именно diff. Строка за строкой.
Если изменено двадцать строк — просто. Если двести — немного дольше. Если несколько тысяч — уже начинается совсем другой разговор.
И именно поэтому последнее слово в этом правиле для меня сейчас самое интересное. Пока.
Это долго казалось совершенно очевидным
Если код написал другой разработчик, он идёт на review. Если код написал AI — почему должно быть иначе? Более того, сначала мне хотелось проверять AI даже тщательнее. Потому что человек хотя бы способен сказать: я не уверен в этом месте. AI иногда выдаёт совершенно неправильное решение с такой же уверенностью, как правильное.
Поэтому схема казалась естественной:
AI пишет
↓
я читаю весь diff
↓
принимаю или возвращаюИ долгое время я вообще не видел причин что-то здесь менять.
Потом diff начал расти
Пока AI пишет небольшой helper, вопроса нет. Пятьдесят строк. Посмотрел. Понял. Принял. Но coding agents постепенно начали получать более крупные задачи. Не «добавь метод». А «реализуй feature».
Теперь изменения могут затронуть domain logic, application service, controller, templates, migration, tests, fixtures, documentation. И внезапно появляется diff на тысячу строк. Или две. Или три. Причём значительная часть может оказаться тестами, generated-кодом или механическими изменениями.
Я всё ещё читаю. Но начинаю задаваться вопросом: это действительно лучший способ проверить такую работу?
С ручным кодом проблема ощущалась иначе
Когда я сам писал feature несколько часов, я практически знал историю каждой строки. Я помнил, почему изменил этот метод, откуда взялось это условие, зачем появился этот класс, какую проблему решает новый interface. Поэтому финальный просмотр diff был скорее проверкой результата.
С AI всё наоборот. Я могу дать задачу. А через некоторое время получить:
17 files changed
+2384
-417И теперь diff для меня — не просто проверка. Это способ восстановить историю решения. Я пытаюсь понять: что вообще здесь произошло? И это уже заметно дороже.
В какой-то момент я поймал себя на странной вещи
AI написал довольно большую feature. Перед реализацией был research. Потом plan. Я посмотрел план. После реализации агент запустил тесты. Прошёл static analysis. Посмотрел собственный diff. После этого другой agent сделал независимый review. Часть замечаний была исправлена. Потом я открыл приложение и прошёл основной пользовательский сценарий. Всё работало.
И только после этого сел читать примерно две тысячи строк diff. Где-то посередине возник очень простой вопрос: а что именно я сейчас пытаюсь доказать?
«Я прочитал весь код» звучит очень надёжно
Это хорошее ощущение контроля. Я видел каждую строку. Значит, я понимаю изменение. Но действительно ли это так?
Можно механически просмотреть огромный diff и не заметить одну важную ошибку. Особенно если большая часть кода выглядит нормально. На двухтысячной строке внимание уже совсем не такое, как на двадцатой.
При этом можно не читать каждый символ, но очень хорошо проверить архитектурную границу, ключевые бизнес-правила, тестовые сценарии, изменение схемы данных, public contracts, пользовательское поведение. Что из этого даёт больше уверенности? Я пока не уверен.
До AI у нас уже была похожая проблема
Мы ведь давно не проверяем software только чтением кода. Есть tests, static analysis, linting, type checks, CI, integration tests, browser tests, monitoring. Почему? Потому что человек плохо масштабируется как единственный механизм проверки.
Никто не предлагает заменить тесты словами: senior внимательно прочитает код, этого достаточно. Наоборот. Мы строим несколько независимых слоёв. И постепенно я начинаю думать, что AI-generated code подталкивает в ту же сторону.
Сейчас мой процесс проверки выглядит примерно так
Для достаточно крупной задачи:
task
↓
research
↓
plan
↓
implementation
↓
agent self-review
↓
tests
↓
static analysis
↓
independent agent review
↓
browser / integration verification
↓
my diff reviewПоследний пункт пока остаётся. Я читаю всё. Но если посмотреть на эту цепочку, становится видно, что human review уже не единственный барьер. И это важное изменение.
Раньше я должен был найти ошибку сам
Теперь ошибка потенциально проходит через несколько сеток. Например, AI случайно использовал неправильный тип. Static analysis может поймать. Сломал существующее поведение. Regression test может поймать. Забыл edge case. Другой agent может заметить. Feature технически работает, но UI ведёт себя странно. Browser verification покажет. Выбрана плохая архитектура. Я замечу на review.
То есть человеку уже не обязательно одинаково сильно проверять каждую категорию ошибок. Можно сосредоточиться на том, где автоматические проверки слабее.
И здесь возникает неприятный вопрос
Если система проверки стала достаточно сильной, нужно ли мне всё ещё читать каждый import, каждый mapping, каждый тестовый fixture, каждую очевидную ветку, каждый mechanical change?
Не знаю. Пока читаю. Но уже не уверен, что именно это будет правильной моделью через год.
Особенно странно выглядит generated и механический код
Представим migration, где agent переименовал поле и обновил большое количество fixtures. Или массово заменил вызов старого API на новый. Diff огромный. Но смысл изменения простой.
Нужно ли мне прочитать все 800 одинаковых замен? Или разумнее проверить правило преобразования, убедиться, что нет исключений, и посмотреть, прошли ли все проверки?
Мы давно доверяем некоторым механическим операциям инструментам. IDE rename refactoring может изменить сто файлов. Я ведь обычно не читаю каждую строку с одинаковым уровнем подозрения. Почему AI должен навсегда оставаться особым случаем? Хорошего ответа у меня пока нет.
Наверное, проблема в доверии
Когда IDE переименовала метод, я примерно понимаю алгоритм. Когда formatter изменил код — тоже. Когда migration tool сгенерировал шаблон — тоже. AI работает иначе.
Он может в одном diff сделать механическую замену, принять архитектурное решение, добавить бизнес-правило, «улучшить» соседний код. И всё это выглядит как один набор изменений.
Поэтому полностью расслабиться сложно. Я ещё не всегда понимаю, какую часть diff можно считать механической, а какую нужно рассматривать как самостоятельное инженерное решение.
Возможно, review должен стать риск-ориентированным
Эта мысль мне сейчас кажется интереснее всего. Не «все 3000 строк одинаково важны». А:
что изменилось в business logic?
что изменилось в security boundaries?
что изменилось в public API?
что изменилось в data model?
какие новые assumptions появились?
что является механическим кодом?И дальше глубина review зависит от риска. Например, новый Value Object я могу посмотреть очень внимательно. А сто однотипных fixtures — выборочно. Изменение access control — максимально внимательно. Generated snapshot — почти не читать вручную.
Это уже не line-by-line review. Это review по слоям риска.
Но я пока не очень доверяю себе в этой градации
Потому что маленькая строка иногда важнее большого класса. Например:
if ($user->isAdmin()) {в security-critical месте. Одна строка. А последствия огромные. Или изменение >= на > в расчёте лимита. Можно идеально понять архитектуру feature и пропустить одну такую мелочь.
Именно поэтому идея «я посмотрю только ключевые места» пока немного пугает. Ключевое место может выглядеть совершенно неключевым.
Тут снова помогает независимость проверок
Если я собираюсь читать меньше, остальные слои должны становиться сильнее. Не «AI написал → я бегло посмотрел → merge». А скорее:
AI написал
↓
tests
↓
static analysis
↓
independent review
↓
targeted verification
↓
human reviewТо есть сокращение человеческого line-by-line review возможно только вместе с ростом качества всей системы проверки. Иначе это просто снижение контроля. Это та же логика, что и в отказе оставлять review только автору.
Отдельно меня интересует review тестов
Потому что после предыдущих экспериментов я уже не хочу успокаиваться только количеством зелёных тестов. Если AI написал три тысячи строк, из которых тысяча — тесты, читать всю тысячу тоже тяжело. Но не прочитать их вообще — ещё хуже.
Возможно, здесь главный вопрос должен быть: какие утверждения о системе появились? Не каждую строку setup. А именно новые expectations. Например: admin CAN cancel processed order. Вот это я хочу увидеть. Потому что это уже не техническая деталь. Это утверждение о поведении продукта.
Про то, почему зелёный suite сам по себе меня уже меньше успокаивает, я писал отдельно.
Возможно, diff вообще перестанет быть основным интерфейсом review
Это пока просто мысль. Но сегодняшнее code review очень сильно ориентировано на строки: вот было → вот стало. Когда изменений немного, это прекрасно работает. Когда agent способен за одну задачу изменить тысячи строк, возможно, понадобится другой уровень представления.
Architecture changes
- добавлен новый application service
Behavior changes
- retry разрешён только для failed + active
Public API
- без изменений
Database
- новая nullable колонка
Tests
- 6 новых сценариев
Risks
- изменение retry semanticsА уже из этого можно проваливаться в конкретный diff. То есть сначала semantic review. Потом code review. Мне кажется, tooling постепенно придёт примерно сюда.
Я хочу знать не только «что изменилось»
Но и: почему? Если AI добавил пять классов, мне не так важно просто прочитать их названия. Мне важно понять: какое решение заставило добавить пять классов?
Если решение правильное, проверка конкретной реализации становится проще. Если решение неправильное, бессмысленно обсуждать formatting внутри пятого класса. Поэтому plan до implementation для меня всё сильнее связывается с review после него. Я могу сравнить, что планировали и что реально получилось. И уже потом смотреть код.
Возможно, хорошая provenance станет частью доверия
Мне хотелось бы понимать:
эта строка
↓
появилась из требования X
этот тест
↓
проверяет acceptance criterion Y
этот класс
↓
нужен из-за архитектурного ограничения ZСейчас большую часть этого приходится восстанавливать вручную. Но если agentic workflow начнёт сохранять такую связь, review может стать намного более содержательным. Не просто вопрос «почему здесь этот if?», а привязка: этот if реализует правило AC-3. Тогда мне проще проверить смысл.
Но есть ещё одна проблема: ответственность
Представим: AI написал 3000 строк. Два агента проверили. Все тесты зелёные. Я посмотрел summary и несколько критических участков. Merge. Через неделю production bug. И что я скажу? Но ведь два агента проверили.
Ответственность всё равно останется у команды. И это, пожалуй, главный психологический барьер. Пока ответственность человеческая, хочется иметь человеческое ощущение контроля. А «я прочитал весь diff» очень хорошо это ощущение создаёт. Даже если объективно не всегда является самым сильным способом проверки.
Возможно, я путаю контроль с наблюдением
Это неприятная мысль. Прочитать тысячу строк — это действие. Оно ощущается как контроль. Но настоящий контроль, возможно, заключается в другом: хорошие acceptance criteria, ограничения автономности, независимый review, качественные tests, воспроизводимая verification, безопасный rollout, observability, возможность rollback.
То есть не в том, что человек увидел каждую строку. А в том, что система не позволяет одной ошибке незаметно пройти весь путь до пользователя. Если так, то моя привычка читать всё однажды может оказаться скорее переходным этапом.
Но сегодня я её сохраняю
Не потому, что уверен в её вечной правильности. Скорее потому, что пока не построил процесс, которому доверяю достаточно, чтобы отказаться. И потому что ещё учусь понимать характер ошибок AI.
Какие вещи он делает надёжно. Где склонен додумывать. Где переусложняет. Где тесты особенно легко подтверждают неправильное предположение. Где второй agent действительно помогает. Пока эти паттерны ещё формируются, полный diff остаётся для меня полезным способом калибровать доверие.
Иногда я уже читаю код не одинаково
Это тоже заметно. Раньше каждая строка кода получала одинаковое внимание. Теперь скорее:
business logic
→ очень внимательно
security
→ очень внимательно
data changes
→ очень внимательно
public contracts
→ очень внимательно
tests expectations
→ внимательно
mechanical changes
→ быстрее
generated code
→ проверка источника генерацииТо есть даже при полном чтении review уже начинает становиться риск-ориентированным. Возможно, следующий шаг просто продолжит эту тенденцию.
Я не хочу измерять качество review количеством прочитанных строк
Допустим, один разработчик прочитал 3000 строк за сорок минут. Другой внимательно разобрал архитектуру, проверил пять ключевых сценариев и нашёл ошибку в бизнес-правиле. Кто сделал более качественный review? Очевидного ответа нет.
Поэтому странно превращать «я прочитал каждую строку» в самостоятельный показатель качества. Важнее: какие риски я реально проверил?
Но и полностью доверять pipeline я пока не готов
Потому что pipeline тоже построен людьми и AI. Тест может быть неправильным. Reviewer может пропустить проблему. Static analysis не понимает бизнес. Browser test может проверить только happy path. Несколько слабых доказательств не обязательно складываются в одно сильное.
Поэтому человеческий взгляд пока остаётся важным. Вопрос только в его форме. Это хорошо рифмуется с тем, что я пока не готов полностью делегировать.
Возможно, человек будет читать меньше кода и больше решений
Мне кажется, именно к этому всё постепенно движется. Не «покажи мне все 3000 строк». А: покажи архитектурные изменения. Покажи новые бизнес-правила. Покажи изменение контрактов. Покажи опасные места. Покажи assumptions. Покажи, какие проверки подтвердили каждое изменение.
И если что-то выглядит подозрительно — тогда проваливаемся в код. Это всё ещё review. Просто немного другого уровня.
Но сегодня я всё ещё открываю diff
И скроллю. И читаю. Иногда тысячу строк. Иногда больше. Потому что пока мне важно видеть, что именно агент оставляет после себя в проекте.
Это помогает не только ловить ошибки. Это ещё и способ понять самого агента. Какие решения он принимает. Где любит создавать abstractions. Как пишет тесты. Какие shortcuts выбирает. Какие части проекта понимает хуже.
Можно сказать, что сейчас line-by-line review — ещё и этап моего обучения работе с AI.
Поэтому заголовок заканчивается словом «пока»
Я не знаю, буду ли через год читать весь AI-generated diff. Возможно, да. Возможно, tooling сделает это настолько удобным, что вопрос исчезнет. А возможно, буду смотреть только критические участки, а остальное доверять системе проверок. Может быть, code review вообще будет выглядеть совсем иначе.
Но на август 2026 года моя граница пока здесь:
AI может
↓
исследовать
↓
планировать
↓
написать тысячи строк
↓
написать тесты
↓
проверить себя
↓
отдать код другому агенту на review
↓
пройти static analysis
↓
пройти browser verification
а потом
↓
я всё равно открываю diffИ читаю его. Весь. Пока.
Потому что главный вопрос для меня уже появился. Но ответ на него ещё нет: если у меня есть несколько независимых способов доказать, что изменение правильное, должен ли человек всё равно лично прочитать каждую строку, чтобы иметь право ему доверять?
Не знаю. И мне кажется, что именно этот вопрос в ближайшее время станет намного важнее вопроса о том, насколько хорошо AI вообще умеет писать код.
