Когда искусственный интеллект стал способен писать код так же хорошо, как опытный программист, возникла естественная надежда на революцию в разработке программного обеспечения. Однако за два года интенсивного использования ИИ-инструментов вроде GitHub Copilot, Claude и GPT в реальных проектах стало ясно: новые технологии принесли не только возможности, но и новые проблемы. В конце 2025 года мы располагаем достаточным количеством реальных данных, чтобы говорить не о теории, а о конкретных цифрах того, насколько ошибочен код, написанный искусственным интеллектом, и как это сравнивается с работой человека.
Статистика ошибок: Неутешительные цифры из реальных проектов
Наиболее объемное исследование 2025 года, основанное на анализе 470 реальных pull-request из открытых исходников, показало поистине тревожные результаты. Средний pull-request с ИИ-генерируемым кодом содержит примерно 10.83 ошибок различной степени тяжести, в то время как человеческий код в среднем содержит 6.45 ошибок. Это означает, что ИИ-сгенерированный код содержит в 1.7 раза больше проблем.
Но самое интересное начинается, когда мы смотрим на серьезность этих ошибок. Критические и крупные дефекты в ИИ-коде встречаются в 1.4-1.7 раза чаще, чем в человеческом коде. Логические ошибки увеличиваются на целых 75 процентов, проблемы с безопасностью возрастают в 1.5-2 раза, а проблемы производительности появляются почти в 8 раз чаще! Эта последняя цифра заставляет задуматься о том, что большая часть ИИ-кода попросту неоптимизирована.
Один только анализ проблем безопасности приносит беспокойство. Неправильное обращение с паролями (improper password handling) встречается в 1.88 раза чаще в ИИ-коде. Уязвимости типа XSS (cross-site scripting) появляются в 2.74 раза чаще. Insecure object references встречаются в 1.91 раза чаще. Insecure deserialization – в 1.82 раза чаще. Это не просто ошибки при компиляции; это системные проблемы в том, как ИИ-модели понимают и генерируют безопасный код.
Особенности ошибок в ИИ-коде: Профиль дефектов
Исследование, проведенное учеными из Университета Неаполя, раскрыло интересный парадокс: ИИ-генерируемый код кажется проще и удобнее для понимания, чем человеческий. Однако эта простота является источником проблем.
ИИ-генерируемый код обладает следующими характеристиками:
Простота и повторяемость – ИИ-модели, особенно те, которые обучены на больших объемах примеров из интернета, имеют тенденцию воспроизводить паттерны, которые они видели раньше. Это означает, что код получается более линейным, менее творческим и часто содержит повторяющиеся конструкции. Когда вы просите ИИ написать функцию сортировки, он напишет стандартный алгоритм, а не оптимизированный для вашего конкретного случая вариант.
Неиспользуемые конструкции и hardcoded значения – ИИ часто включает переменные и функции, которые никогда не используются. Более того, он любит вставлять hardcoded значения для отладки (типа print("DEBUG: x =", x) или if True: return 0), которые потом забываются в финальном коде.
Ошибки присваивания переменных – это очень распространенная ошибка, когда ИИ правильно инициализирует переменную в одном месте, но потом пытается переприсвоить её неправильно в другом.
Command injection и hardcoded secrets – когда ИИ генерирует код, связанный с системными командами или работой с API, он часто забывает о необходимости валидации входных данных и любит вставлять ключи API, пароли и другие secrets прямо в код.
Ошибки в контроле потока – неправильная обработка исключений, отсутствие необходимых проверок условий, неправильное использование циклов.
Интересное наблюдение: человеческий код часто содержит больше проблем со сложностью и поддерживаемостью, потому что люди пишут более амбициозный, сложно устроенный код. ИИ пишет проще, но эта простота часто достигается за счет полнотой и правильности.
Документирование кода: ИИ наконец находит применение
Вот область, где ИИ блистает. Если в генерации самого кода ИИ столкнулся с серьезными проблемами, то в документировании произошла настоящая революция.
Традиционное документирование кода – это бремя, которое разработчики откладывают на потом. Код изменяется, но комментарии остаются старыми. Функции переписываются, но их документация не обновляется. Человеческие разработчики часто воспринимают документирование как рутину, которая отвлекает от «настоящей» работы.
ИИ подходит к документированию совершенно иначе. Когда ИИ-система вроде DocAgent или RepoAgent анализирует кодовую базу, она может:
- Автоматически генерировать docstring’и для функций с описанием параметров, возвращаемых значений и типов.
- Создавать README файлы и API документацию на основе кода.
- Поддерживать документацию в актуальном состоянии – при каждом изменении кода ИИ может автоматически обновить соответствующие комментарии и docstring’и.
- Добавлять контекстную информацию о том, почему код был написан именно так, какие альтернативные подходы были рассмотрены.
Исследование показало, что ИИ-генерируемая документация часто включает больше деталей, чем необходимо, но это на самом деле плюс, а не минус. Излишняя информация о коде помогает будущим разработчикам (и самому ИИ при последующих итерациях) быстрее разобраться в том, что происходит.
Однако следует отметить: качество документации зависит от качества исходного кода. Если код неправильный или неполный, документация также будет неправильной и неполной. ИИ может отлично описать то, что сделал другой ИИ, но это не означает, что описываемый код работает правильно.
Оптимизация памяти и производительность: Слепое пятно ИИ
Одна из наиболее критических проблем в ИИ-генерируемом коде – полное отсутствие оптимизации памяти и производительности. Это особенно заметно в embedded-системах и приложениях реального времени.
Когда ИИ генерирует код, он думает прежде всего о корректности алгоритма. Может ли эта программа решить поставленную задачу? Если да, то ИИ считает работу выполненной. Вопросы типа «сколько памяти это будет использовать?» или «насколько быстро это будет выполняться?» остаются вне поля зрения.
Характерные проблемы с памятью в ИИ-коде:
Неоптимальные структуры данных – ИИ часто использует динамические структуры (вроде std::vector в C++ или списков в Python) вместо статических буферов. Это приводит к непредсказуемым временам выделения памяти, фрагментации heap и дополнительным накладным расходам.
Excessive global variables – ИИ иногда заполняет код глобальными переменными там, где они совсем не нужны, увеличивая потребление памяти и усложняя анализ кода.
Inefficient memory access patterns – когда ИИ генерирует цикл для работы с массивом, он часто делает это неэффективно с точки зрения кэша процессора. Правильный порядок доступа к памяти может улучшить производительность в 2-3 раза, но ИИ об этом не знает.
Отсутствие объединения операций – ИИ часто делает несколько проходов по данным, когда можно было бы сделать всё за один проход, значительно снижая потребление памяти и пропускную способность памяти.
Исследование, проведенное на примере embedded систем (микроконтроллеры, IoT устройства), показало, что ИИ-генерируемый код часто использует в 2-3 раза больше памяти и работает в несколько раз медленнее, чем ручная оптимизация.
Проблемы с производительностью:
Избыточные операции ввода-вывода – ИИ часто генерирует код, который обращается к диску или сети намного чаще, чем необходимо. Вместо того чтобы кэшировать результаты, ИИ делает тот же запрос несколько раз.
Неоптимизированные циклы – цикл может быть распакован неправильно, или условия внутри цикла расставлены неоптимально.
Отсутствие параллелизма – ИИ редко использует многопоточность, async/await, goroutines или другие механизмы параллелизма даже тогда, когда они были бы полезны.
Неправильное использование встроенных функций – вместо использования оптимизированных встроенных функций (которые написаны на ассемблере и скомпилированы для конкретной архитектуры), ИИ часто пишет свою реализацию на высокоуровневом языке.
Что интересно: проблемы производительности в ИИ-коде часто не видны при тестировании на малых объемах данных. Если вы тестируете функцию сортировки на массиве из 100 элементов, неоптимальный алгоритм с неправильным использованием памяти может работать нормально. Но когда этот код попадает в production и работает с миллионами данных, проблемы становятся очевидными.
Сравнение с человеческим кодом: Где ИИ побеждает
Справедливости ради, существуют области, где ИИ-генерируемый код лучше:
Орфография и форматирование – опечатки в комментариях встречаются в 1.76 раза реже в ИИ-коде, потому что ИИ обучен на текстах с правильной орфографией. Человеческие программисты часто пишут комментарии спешно и допускают ошибки.
Проверяемость кода – ИИ часто пишет код, который легче тестировать, потому что он менее сложный и более структурированный. Проблемы с тестируемостью встречаются в 1.32 раза реже.
Согласованность стиля – если вы дадите ИИ инструкции о стиле кодирования, он будет придерживаться их гораздо более последовательно, чем человеческий программист.
Скорость генерации – это очевидно, но ИИ может написать базовую реализацию функции за секунды, в то время как человеку потребуются минуты или часы.
Интересные наблюдения о новых моделях: GPT-5 и более сложное рассуждение
Конец 2025 года принес новое поколение моделей, способных к расширенному рассуждению. GPT-5 с режимом «высокого рассуждения» показал интересные результаты, которые противоречивы.
С одной стороны, такие модели значительно лучше справляются с логическими ошибками. Доля критических ошибок (BLOCKER bugs) снижается примерно с 8% до 3%. Модель может лучше «понять» проблему и написать более правильное решение.
С другой стороны, эти модели генерируют код, который в 2-3 раза объемнее и значительно сложнее. Если обычный GPT-4 генерирует 300 строк кода, то GPT-5 с высоким рассуждением может сгенерировать 700 строк для той же задачи. Cyclomatic complexity (мера того, насколько запутанны условия в коде) увеличивается примерно на 40%.
Ещё более интересно: хотя простые логические ошибки исчезают, появляются новые, более сложные ошибки, особенно связанные с многопоточностью и обработкой ошибок. Ошибки в работе с потоками (concurrency bugs) в коде GPT-5 высокого рассуждения встречаются в два раза чаще.
Это открывает важное понимание: сложность кода не всегда коррелирует с его правильностью. Зачастую код, написанный с попыткой быть «правильным» и «полным», содержит больше скрытых ошибок, чем код, написанный проще.
Практические примеры типичных ошибок
Давайте посмотрим на конкретные примеры того, как ИИ ошибается:
Пример 1: Injection-уязвимость
python# ИИ-генерированный код
def get_user_data(user_id):
query = f"SELECT * FROM users WHERE id = {user_id}"
return database.execute(query)
Это классическая SQL injection уязвимость. ИИ генерирует правильный синтаксис, функция синтаксически корректна и будет работать с нормальными входными данными. Но если user_id будет чем-то типа 1 OR 1=1, то база данных будет взломана.
Человеческий программист, знакомый с основами безопасности, сразу напишет это с использованием параметризованных запросов:
python# Правильный код
def get_user_data(user_id):
query = "SELECT * FROM users WHERE id = ?"
return database.execute(query, [user_id])
Пример 2: Утечка памяти в цикле
python# ИИ-генерируемый код
def process_large_file(filename):
results = []
with open(filename) as f:
for line in f:
data = process_line(line)
results.append(data)
temp_data = expensive_calculation(data) # Не удаляется
return results
Здесь в цикле создается временная переменная temp_data, которая содержит большой объект в памяти. Даже после того, как цикл перешел к следующей итерации, объект остается в памяти (в некоторых языках это может привести к утечкам).
Правильный подход был бы:
python# Правильный код с явной очисткой
def process_large_file(filename):
results = []
with open(filename) as f:
for line in f:
data = process_line(line)
results.append(data)
return results
Или, если расчет все же необходим, использовать генераторы для ленивых вычислений.
Пример 3: Hardcoded credentials
python# ИИ-генерируемый код
def connect_to_database():
connection = database.connect(
host="localhost",
username="admin",
password="Password123"
)
return connection
ИИ генерирует функцию подключения с hardcoded паролем. Это произойдет, потому что в обучающих данных много примеров с hardcoded значениями (для тестирования и документации). ИИ не различает контексты правильно.
Правильный код должен использовать переменные окружения или систему управления secrets:
python# Правильный код
import os
def connect_to_database():
connection = database.connect(
host=os.getenv("DB_HOST"),
username=os.getenv("DB_USER"),
password=os.getenv("DB_PASSWORD")
)
return connection
Пример 4: Off-by-one ошибка
python# ИИ-генерируемый код
def get_first_n_items(items, n):
return items[0:n+1] # Off-by-one: вернёт n+1 элемент
Это очень типичная ошибка, которую делает ИИ при работе с индексами. Слайсирование в Python работает так: items[0:n] вернет элементы с индекса 0 по индекс n-1 (всего n элементов). Но ИИ часто добавляет лишний +1.
Документирование как инструмент борьбы с ошибками ИИ
Интересный вывод из исследований: когда разработчики добавляют подробные комментарии и docstring’и перед тем, как попросить ИИ писать код, качество генерируемого кода значительно улучшается.
Это логично: ИИ лучше работает с контекстом. Если вы скажете ИИ:
Напишите функцию для сортировки массива целых чисел.
Функция должна использовать алгоритм quicksort.
Параметры: array (список целых чисел)
Возвращаемое значение: отсортированный массив
Важно: используйте in-place сортировку для экономии памяти.
То результат будет лучше, чем если вы просто скажете:
Напишите функцию для сортировки массива.
Подробное документирование требований действует как усилитель качества для ИИ-генерируемого кода.
Статистика по языкам программирования
Интересный факт: ИИ-модели лучше генерируют код на некоторых языках, чем на других.
Из исследования на 500 000+ сэмплов кода в Python и Java:
- Python: ИИ генерирует код с меньшим количеством дефектов, чем на Java (примерно -4 000 дефектных сэмплов в выборке)
- Java: ИИ генерирует намного больше ошибок (+22 000 дефектных сэмплов в выборке)
Это происходит потому, что:
- В обучающих данных больше примеров Python кода
- Python более «forgiving» язык (динамическая типизация, меньше требований к инфраструктуре)
- Java требует более тщательного соблюдения структуры и типов, в чем ИИ часто ошибается
Энергетическая стоимость и углеродный след
В 2025 году появился новый аспект проблемы: экологический. Исследование показало, что использование ИИ для генерации кода приводит к углеродному следу на 32.72% выше, чем ручная разработка.
Это связано с:
- Энергией, потребляемой при обучении и использовании моделей
- Необходимостью запускать модели на сервере (в облаке)
- Часто неоптимизированным генерируемым кодом, который потребляет больше энергии при выполнении
Более сложные модели (вроде GPT-5 с высоким рассуждением) имеют еще более высокий углеродный след, потому что они дольше «думают» (требуют больше вычислений).
Практические рекомендации: Как минимизировать ошибки в ИИ-коде
На основе исследований 2025 года, вот что рекомендуют сделать практикующие разработчики и эксперты:
1. Strict Code Review для ИИ-сгенерированного кода
Если ваш код был написан ИИ, убедитесь, что review был проведен особенно тщательно. Обратите внимание на:
- Безопасность (нет ли hardcoded secrets, injection уязвимостей?)
- Обработка ошибок (все ли edge cases покрыты?)
- Производительность (нет ли очевидных неоптимальностей?)
- Многопоточность (если код работает с потоками)
2. Используйте контекстные подсказки (Prompts)
Не просто пишите «напиши функцию». Вместо этого:
- Опишите требования подробно
- Укажите ограничения (памяти, времени выполнения)
- Приведите примеры входных данных и ожидаемых выходов
- Упомяните критические области (безопасность, производительность)
3. Установите инструменты статического анализа
Используйте SAST (Static Application Security Testing) инструменты, которые автоматически проверят код на уязвимости. Примеры: SonarQube, Checkmarx, Semgrep.
4. Требуйте 100% покрытие тестами для ИИ-кода
Не менее важно: требуйте написания тестов ещё до того, как генерировать код. Test-Driven Development (TDD) работает хорошо с ИИ – если дать ИИ написанные тесты, он часто генерирует более правильный код.
5. Используйте инструменты для оптимизации
Существуют инструменты, которые анализируют сгенерированный ИИ код и предлагают оптимизации:
- Для embedded систем: beLow, Perforce QAC
- Для Python/Java: Sonarqube, JetBrains Inspections
- Для C/C++: Clang Static Analyzer, Intel VTune
6. Заставляйте ИИ документировать его выбор
Когда ИИ генерирует код, попросите его также объяснить, почему он выбрал этот подход, какие альтернативы рассматривал, каковы потенциальные проблемы.
7. Используйте RAG (Retrieval-Augmented Generation) для контекста
Если вы даете ИИ контекст из вашей кодовой базы (примеры похожего кода, архитектурные документы), качество генерируемого кода улучшается на 40-50%.
Инструменты и сервисы для контроля качества ИИ-кода в 2025 году
CodeRabbit
Специализированная платформа для code review, которая анализирует pull-requests с помощью ИИ и автоматически выявляет проблемы в ИИ-сгенерированном коде.
GitHub Code Scanning
Встроенная система в GitHub, которая использует CodeQL для анализа кода на уязвимости.
Cursor IDE
IDE, которая глубоко интегрирует ИИ (Claude/GPT) и при этом поддерживает локальный анализ кода для выявления проблем.
Tabnine
Расширение для IDE, которое не только генерирует код, но и пытается объяснить потенциальные проблемы.
DeepSeek Coder
Специализированная модель для кодирования, которая часто генерирует более оптимальный код, чем универсальные модели.
Чек-лист для разработчиков, использующих ИИ
Если вы используете ИИ для генерации кода, используйте этот чек-лист перед commit’ом:
- Код прошел статический анализ (линтер, типизация)
- Код прошел SAST (проверка на уязвимости)
- Код полностью протестирован (минимум 90% покрытие)
- Нет hardcoded secrets или чувствительных данных
- Обработка ошибок правильная (нет пустых catch блоков)
- Нет очевидных проблем с производительностью (нет 8x+ проблем)
- Потребление памяти разумно (профилирование запущено)
- Код документирован (docstring’и, комментарии)
- SQL запросы параметризованы (если применимо)
- Нет использования deprecated API или функций
- Многопоточный код (если есть) правильно обрабатывает синхронизацию
- Код пересмотрен хотя бы одним опытным разработчиком
- Код прошел автоматические тесты в CI/CD
Будущие перспективы: Что ждет ИИ-генерацию кода
Исследователи активно работают над улучшением качества ИИ-кода. Вот некоторые многообещающие направления:
Self-Healing Code Generation
Системы, которые автоматически генерируют код, затем тестируют его, находят ошибки и автоматически их исправляют. В 2025 году такие системы достигали 94.7% корректности (против 87.3% у базовых моделей).
Hardware-Aware Code Generation
ИИ, которые знают, для какого оборудования генерируется код (CPU, GPU, MCU), и оптимизируют код соответственно.
Program Synthesis с формальной верификацией
Подход, где ИИ генерирует код, а затем формальные методы (SAT-солверы, theorem provers) проверяют корректность.
Few-Shot Learning с примерами
Задавая ИИ примеры правильного кода из вашей кодовой базы, вы можете добиться намного лучших результатов, чем с zero-shot генерацией.
Заключение: Реальность ИИ-генерируемого кода в 2025
Искусственный интеллект революционизировал разработку, но не так, как многие надеялись. Это не замена программисту, а скорее мощный инструмент, который требует опытного пользователя.
Ключевые выводы:
- ИИ генерирует в 1.7 раза больше ошибок, чем люди, в среднем
- Эти ошибки часто более серьезные – больше проблем с безопасностью и производительностью
- ИИ не обучен оптимизации – его код часто использует 2-3x больше памяти и работает медленнее
- Документирование – одна из сильных сторон ИИ – он может автоматически создавать и обновлять docs
- Контекст и детальные инструкции улучшают результаты на 40-50%
- Требуется полный пересмотр процесса разработки – code review, тестирование, статический анализ должны быть строже
Наиболее успешные команды в 2025 году используют «гибридный подход»: люди определяют архитектуру, критические части и требования безопасности, а ИИ генерирует boilerplate, тесты и документацию. Потом опытные разработчики тщательно проверяют и оптимизируют.
Это не то будущее, которое многие воображали, но это реальность, которая уже здесь.
Добавить комментарий