Один из самых популярных вопросов в ИТ сегодня — это «А как отличить код, который написала нейросеть, от кода, написанного человеком?» Попробуем ответить на этот вопрос, результат вас может удивить.
А заодно мы позвали сеньор-разработчика прокомментировать сгенерированный код и рассказать, что с ним может быть не так. Получилось довольно занятно.
Как гарантированно точно отличить ИИ-код
Никак ¯\_(ツ)_/¯
Полезный блок со скидкой
Если вам интересно разбираться со смартфонами, компьютерами и прочими гаджетами и вы хотите научиться создавать софт под них с нуля или тестировать то, что сделали другие, — держите промокод Практикума на любой платный курс: KOD (можно просто на него нажать). Он даст скидку при покупке и позволит сэкономить на обучении.
Бесплатные курсы в Практикуме тоже есть — по всем специальностям и направлениям, начать можно в любой момент, карту привязывать не нужно, если что.
А почему так?
Надёжного способа действительно не существует. Если промпт составлен грамотно (и на основе предыдущем десятке-другом неудачных промптов), а нейросеть понимает контекст задачи, даже опытный разработчик не сможет с полной уверенностью сказать, кто писал код.
Попытки создать детектор ИИ-кода часто показывают низкую эффективность. А всё потому, что современные системы искусственного интеллекта научились повторять человеческий стиль программирования, использовать правильные паттерны и даже имитировать характерные для конкретного разработчика особенности. Когда человек даёт нейросети чёткое техническое задание с указанием стиля и требований, результат становится практически неотличимым от ручной работы.
Правило тут такое: чем полнее промпт, чем больше нейросеть владеет контекстом, тем сложнее отличить сгенерированный код от написанного вручную. При определённой сноровке и большом затраченном времени на старте можно научиться заставить ИИ выдавать человеческий код. Такие дела.
Единственная ситуация, когда можно более-менее уверенно определять авторство, — если вы сами писали этот код или долго работали с коллегой и знаете его почерк. Но и здесь возможны ошибки: нейросеть можно попросить имитировать определённый стиль написания кода вплоть до ошибок.
Например, вы подмечали за собой, что иногда путаете названия методов или забываете писать в ВерблюжьемСтиле названия переменных. В этом случае нам нужно сказать нейросети, чтобы она специально допустила какие-то ошибки или неточности, которые не влияют на работоспособность. Такой код сразу выглядит человечнее — не может же нейросеть ошибаться специально?
Ну если её попросить — может. И про это надо помнить.
Зачем вообще отличать ИИ-код
Самая практическая цель всего этого — понять, действительно ли программист разбирается в том, что написано в коде, или просто скопировал результат работы ChatGPT без понимания. И первая задача здесь — выявить это на собеседованиях.
При найме всем важно оценивать и понимать реальные знания человека. Если кандидат не может объяснить, как работает код, который он якобы написал, это серьёзный повод усомниться в том, что он сможет это сам повторить. Код, созданный искусственным интеллектом, может быть технически правильным, но, если человек не понимает его логику, он не сможет поддерживать его, исправлять ошибки или дорабатывать. А значит, компании придётся тратить много времени на доработку кода за ним, накапливать технический долг и успокаивать коллег, которых бесит такая работа.
Вторая цель — понять, насколько человек пишет код сам во время работы. И это не из-за того, что он лентяй и не может написать всё там. Смотрите, если программист заморочился с промптом настолько, что ИИ выдаёт код, который неотличим от его собственного, то он определённо шарит в теме. А вот если он выдаёт код, который формально работает верно, но вообще не бьётся с принятым подходом программирования в компании — это уже проблема.
Есть ещё пара причин научиться различать такой код:
- при код-ревью нужно понимать, насколько разработчик вообще справился с задачей;
- при реквестах в Гит — оценивать, насколько этот код приведёт к проблемам в будущем,
- а ещё это полезно для оценки реального прогресса в обучении программированию.
Ну и бонус-трек — чтобы находить потенциально проблемные участки, которые нейросети пишут особенно плохо. А таких в реальном продакшене прям немало, нейросети вообще плохо умеют в работу со средними проектами даже на пару-тройку сотен тысяч строк кода.
Что плохого в том, если весь код будет писать нейросеть
Качество кода, который генерирует искусственный интеллект, сильно зависит от качества промпта и обучающих данных. Уже есть классические проблемы, с которыми сталкиваются разработчики, которые используют нейроинструменты для работы:
Код часто получается избыточным. Нейросеть старается покрыть все возможные случаи, даже самые редкие, что приводит к нагромождению ненужных проверок и усложняет чтение. Человек же обычно пишет или более минималистичный код, или такой, что без погружения в задачу с первого раза и не поймёшь, что именно он делает (поэтому, кстати, мы всегда агитируем за комментирование всего в коде и сами так делаем).
Использование устаревших решений. О, это отдельный дивный мир нейросетей, потому что они все обучались на знаниях, которые были раньше, и старых решений в них (которые не используются сейчас) большинство. В результате она будет писать код, используя подходы, которые были актуальны пять лет назад, но сейчас считаются антипаттернами. Ниже мы это увидим в примерах.
И самое опасное — код может не соответствовать реальной задаче. Нейросеть не понимает рабочий контекст, не знает ТЗ и не в курсе, о чём говорил тимлид на утреннем созвоне. В итоге — вообще без понятия про нюансы и параметры, которые важны в конкретном проекте. Человек же обычно лучше понимает, зачем он пишет каждую строчку и как она будет использоваться. Не всегда, но точно старается (мы надеемся).
Примеры явно плохого кода, написанные ИИ
Давайте посмотрим на конкретные примеры, где разница между подходом нейросети и человека становится очевидной.
JavaScript
Классика жанра — обработка массива в JavaScript. Вот как это пишет нейросеть:
function processArray(inputArray) {
let resultArray = [];
for (let i = 0; i < inputArray.length; i++) {
let currentElement = inputArray[i];
if (currentElement !== null && currentElement !== undefined) {
let processedElement = currentElement 2;
resultArray.push(processedElement);
}
}
return resultArray;
}Комментарий сеньора:
Тут происходит какая-то жесть, причём по всем фронтам.
С архитектурной точки зрения:
- Нарушение принципа KISS — функция делает сразу три вещи: фильтрацию, трансформацию и мутацию состояния. В продакшене это явно пахнет антипаттерном.
- Игнорирование иммутабельности — мутация `resultArray` через `push` может привести к сайд-эффектам, особенно если исходный массив используется где-то ещё. Я бы точно не пропустил такое в прод.
- Очень примитивная обработка ошибок — проверка на `null` и `undefined` выглядит как костыль. В нормальном API либо контракты, либо Maybe/Option. Если берёшься писать обработку ошибок (что не всегда нужно, кстати) — пиши её нормально, а не выборочно.
С перформансной точки зрения цикл for без кеширования inputArray.length — классический пример микрооптимизации, но в 2025-м это уже моветон.
Ещё именование переменных в стиле resultArray — это код-смелл, потому что паттерн именования должен отражать домен, а не структуру.
Если совсем уж придираться, то видим отсутствие JSDoc/TypeScript — в 2025-м никто не пишет на голом JS без типов в нормальных проектах. В учебных и личных можно, никто не возражает.
Как бы написал простой советский программист, которому просто нужно просмотреть массив, выкинуть из него всякий шлак, а оставшиеся числа умножить на два:
const processArray = (arr) => arr.filter(Boolean).map(x => x 2);Python
Теперь сделаем то же самое с python-кодом: попросим ИИ написать проверку числа на простоту (простое оно или нет).
Что нам написала нейросеть:
def is_prime_number(number):
if number < 2:
return False
for i in range(2, number):
if number % i == 0:
return False
return TrueКомментарий сеньора
Тут тоже всё печально, сложно выделить что-то одно. Если бы мне такое принёс джун, я бы понял (наверное), но если мидл — я бы сильно задумался, а нужен ли мне такой странный программист.
С архитектурной точки зрения тут плохо абсолютно всё:
- Нарушение принципа YAGNI — функция реализует наивный алгоритм, который никогда не должен использоваться в продакшене. Это как использовать пузырьковую сортировку для реальных данных — в профессии за такое сразу бьют по рукам.
- Игнорирование математических оптимизаций — проверка всех чисел до n вместо √n демонстрирует фундаментальное непонимание теории чисел. А знание хотя бы такой математики — база для программиста.
- Именование явно в новичковом стиле —
is_prime_numberизбыточно, в Python принятоis_prime. Поддерживать потом такие функции, написанные лингвистами, довольно муторно.
С перформансной точки зрения тоже бардак. Для числа 109 потребуется миллиард итераций, а всё потому, что идёт полное игнорирование чётных чисел — 50% проверок абсолютно бесполезны после двойки (а тройка сокращает количество проверок ещё на 33%, но нейросеть про это думать не всегда любит.
А на перфоманс-проектах я бы не пропустил это из-за отсутствия мемоизации, потому что функция будет заново вычислять простые числа при повторных вызовах.
Как это напишет человек, будь у него такая задача и базовые представления о нормальном программировании:
def is_prime(x):
for i in range(2, (x//2)+1):
if x % i == 0:
return False
return TrueА если есть хотя бы пара минут — напишет так (сильно оптимизировав время выполнения и нагрузку на ресурсы):
def is_prime(n: int) -> bool:
if n == 1:
return False
if n in (2, 3):
return True
if n % 2 == 0 or n % 3 == 0:
return False
return all(n % i != 0 and n % (i + 2) != 0
for i in range(5, int(n**0.5) + 1, 6))Явные признаки ИИ-кода
Хотя стопроцентной гарантии нет, некоторые признаки позволяют с большой долей уверенности предполагать, что код писала нейросеть. Именно предполагать — точно знает ответ только тот, кто принёс этот код на ревью.
Итак, поехали.
Чрезмерные комментарии
Нейросеть часто добавляет комментарии к очевидным вещам — даже там, где её не просили это делать:
# Увеличиваем значение счётчика на 1
counter += 1Человек обычно так не пишет, если только это не учебный пример.
Использование устаревших конструкций
Часто в python-коде, написанном ИИ, можно встретить устаревшие методы форматирования строк или совместимость с Python 2.x, хотя проект использует современные версии. И это иногда действительно сложно заметить, если программисту нужно быстро закрыть таску, а время есть только на копипасту откуда-то.
Слишком общие имена переменных
Нейронки часто использует шаблонные имена вроде temp, data, value, result, где человек выбрал бы более описательные варианты. А иногда её шатает в обратную сторону, и она начинает называть переменные очень подробно, типа GetResultFromThisDef.
Избыточная обработка ошибок
Искусственный интеллект может добавлять ненужные проверки и блоки try-catch там, где ошибка практически невозможна. Или начинает проверять то, что уже отфильтровано на входе, — но без полного представления о проекте она этого, естественно, не знает. И это выдаёт такой код с головой.
Шаблонная структура как по учебнику
Код выглядит так, будто собран из стандартных блоков, без творческого подхода к решению задачи. Ещё вариант — код очень академический, написанный в стиле того, как преподают в институтах и учебниках. Но тут может быть нюанс: вполне возможно, что перед вами человек, который только окончил вышку и пришёл работать со всем своим багажом знаний и представлениями о том, как правильно.
❗️ Важно понимать: даже наличие нескольких этих признаков не доказывает, что код написан нейросетью. Опытный разработчик может сознательно использовать подобные подходы. И наоборот: качественный промпт может заставить ИИ написать код, лишённый этих недостатков.
Вам слово
Приходите к нам в соцсети поделиться своим мнением о статье и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте — шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!
