🧠 code review становится ещё важнее в эпоху AI-кодинга Недавно посмотрел лекцию из Stanford про современного разработчика и роль AI в разработке и code review. Там есть интересный парадокс. Что вообще делает code review Code review — одна из самых эффективных практик в разработке. Исследования показывают: • code review находит 55–60% ошибок • разные виды тестирования — 25–45% • в одном исследовании количество ошибок снизилось с 4.5 до 0.82 на 100 строк кода после внедрения ревью • в AT&T код-ревью дало +14% продуктивности и −90% дефектов Но важно не только количество ошибок. Хороший code review ловит: 1️⃣ Логические ошибки 2️⃣ Проблемы читаемости и поддерживаемости 3️⃣ Проблемы производительности 4️⃣ Уязвимости безопасности 5️⃣ Нарушения best practices Где AI уже лучше человека AI-ревьюеры (Graphite, Greptile, CodeRabbit, Claude Code и др.) хорошо находят: • баги • edge-cases • проблемы производительности • security-риски • плохой стиль кода • неаккуратные паттерны По сути, AI стал супер-линтером + статическим анализатором + junior reviewer. Но есть вещи, где человек всё ещё нужен AI плохо понимает: • архитектурные решения • бизнес-логику • контекст продукта • «знания» команды • продуктовые компромиссы Команда Graphite проанализировала 10 000 комментариев из код-ревью (Open Source и собственные проекты) и составила матрицу того, насколько эффективно LLM справляются с поиском ошибок. Оказалось, что просто «найти баг» — это только половина дела. Важно еще, чтобы разработчик был готов принять этот совет от бота Вот как выглядит эта классификация: ✅ Что LLM ловят хорошо и что мы ХОТИМ от них получать: - Логические баги: критические ошибки, которые ведут к падениям (например, возврат неинициализированного класса из БД или деление на отрицательное число при расчете border-radius) - Случайно забытый код: файлы или строки, которые попали в PR по ошибке - Проблемы безопасности и производительности: очевидные дыры и тяжелые участки кода - Несоответствие документации: когда код делает одно, а комментарий к нему говорит другое ⚠️ Что LLM МОГУТ поймать, но разработчиков это БЕСИТ: Это категория «чистоты кода» (code cleanliness). Нейросети отлично видят отсутствие тестов или слишком длинные функции. Но когда бот пишет: «добавь сюда комментарий» или «вынеси это в отдельную функцию», это часто воспринимается как занудство и вызывает раздражение. От человека такой совет принять легче, чем от «бездушной машины» ❌ Что LLM НЕ МОГУТ поймать (пока что): «Tribal Knowledge» (племенные знания): Это опыт, который живет только в головах сеньоров и нигде не задокументирован. Например: «Мы раньше делали так, но перестали из-за специфического бага в легаси-системе». ИИ не умеет читать мысли, поэтому такие нюансы ему недоступны Самое интересное изменение Раньше code review делали потому, что люди плохо пишут код. Теперь code review нужен потому, что AI пишет слишком много кода. И ответственность всё равно остаётся у разработчика. Если AI сгенерировал код — это всё равно ваш код. Вы отвечаете за то, что попало в production. Фактически разработчик всё больше превращается в архитектора и редактора AI-кода. Исследование показало, что только 50% комментариев от людей-разработчиков приводят к реальным изменениям в коде. Правильно настроенные LLM (как Diamond от Graphite) уже достигли отметки в 52%, то есть их советы становятся даже более применимыми на практике, чем человеческие Андрей Анисимов про ИИ https://max.ru/join/q1WsVDU61qyeWmNiexaPbgHkQhziOuMydLzOofI4Nec