SimpleOne showed why Claude and AI reviewers can’t distinguish AI-generated code from human-written code

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

Почему это сложно В статье команда собрала несколько пар функций:

валидацию email, запрос к API, загрузку конфигурации и расчёт скидки. В каждой паре один вариант написал человек, другой — модель. На бумаге задача выглядит простой: у AI-кода обычно больше типизации, комментариев и псевдо-аккуратности.

На практике всё хуже. Часть примеров действительно выдаёт себя чрезмерной правильностью, но уже на третьей-четвёртой паре становится ясно: по одному лишь стилю отличить автора можно далеко не всегда. Самый сильный пример — функция расчёта скидки, где различие между вариантами почти исчезает.

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

Это уже не вопрос синтаксиса или best practices, а вопрос бизнес-логики и контекста проекта, которого у автоматического ревьюера обычно нет.

Что выдает синтетику

SimpleOne выделяет несколько признаков, по которым AI-код иногда всё ещё можно вычислить. Речь не о грубых ошибках, а скорее о подозрительно «идеальном» стиле: код кажется аккуратным, но ведёт себя так, будто пытается впечатлить ревьюера, а не решить конкретную задачу из продакшена. Именно такие сигналы чаще всего всплывали в примерах с email, API и конфигом.

• Слишком подробные docstring'и с перечислением Args, Returns и каждого исключения даже для крошечной функции.
• Лишние edge cases и проверки, которых никто не просил и которые не следуют из постановки задачи.
• Выдуманные сущности вокруг кода: кастомные исключения, логгеры или обязательные поля, которых нет в проекте. * «Безопасные» fallback'и вроде data.get('user', {}), которые не падают сразу, зато маскируют реальную проблему. Отсюда и главный риск: AI часто пишет не откровенно плохой код, а код, который выглядит убедительно. Он типизирован, отформатирован, снабжён комментариями и учитывает массу сценариев. Но часть этих сценариев взята из воздуха, а часть защитных конструкций только усложняет отладку. Такой код легко принять за качественный, если смотреть на форму и не проверять, как он встроен в конкретную систему.

Где ревью ломается Проблема, которую описывает SimpleOne, не сводится к качеству одной модели.

Если Claude генерирует код, а затем другой AI-инструмент проверяет его по тем же паттернам, команда получает замкнутый контур синтетической уверенности. Всё выглядит зелёным: есть типы, есть обработка ошибок, есть комментарии. Но ревью может не заметить, что UserFetchError в проекте не существует, secret_key внезапно появился без требований, а «тихий» возврат пустого словаря потом утащит несколько часов на поиск бага.

«ИИ-ревьюер нашёл 2 из 5».

Команда проверила это на реальных багах из продакшена. Автоматический ревьюер поймал только два простых случая: неиспользуемую переменную и отсутствие проверки на null. Мимо прошли вещи, для которых нужен проектный контекст: логическая ошибка в расчёте, race condition при параллельных запросах и неверный порядок миграций. Вывод практичный: AI хорошо работает как первый фильтр, но не заменяет человека на критичных участках, где важно понимать доменную логику и последствия изменений.

Что это значит

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